This line will create one client through which we will send the request to 3pp. After that we are not closing this client, once got the response from 3pp. when there is more traffic, for each request client will be created, which has caused memory leakage issue and all threats were consumed which caused emergency in our Project.
If the client is opening the code, in sonarqube can we scan it if it is closed properly so that we can avoid such memory leak issues?
Can you suggest which rule/plugin can be used for this?
Hi Ann,
NO, dev member forgot to implement AutoCloseables.close(this.httpClient) for these client creation cases. Which should be detected during code scanning for created clients.
I believe the rule that looks for unclosed resources keys off them being Closeable. Is there any other attribute of the client that you believe could/should have been a marker for the rule?
We are already using that rule in our quality profile, but still the issue was not detected in sonarqube analysis. Can you suggest why it happened and what can be done as alternative solution to detect such issues?
Per the description, that rule looks for un-closed instances of Closeables or AutoCloseables. Your developer forgot to implement the interface, so the resource simply wasn’t eligible to be detectedby the rule. That’s why I asked if there was any other characteristic that you believe the rule could have keyed off of. Closeable-ness, auto or not, is already covered. What else should be covered?
Or perhaps there should be a different rule? Something like “Classes that [do X] should implement Closeable”? Of course, you’ll need to define the “do X” part here.
