Possible Memory Leak? #78
Labels
priority: p0
Highest priority. Critical issue. P0 implies highest priority.
🚨
This issue needs some love.
type: bug
Error or flaw in code with unintended results or allowing sub-optimal usage patterns.
From yan...@google.com on March 27, 2012 07:47:17
Reported from https://code.google.com/p/google-api-java-client/issues/detail?id=402 Reported by aalb...@google.com, Feb 3, 2012
Version of google-api-java-client 1.6?
Java environment Java 6, Android 2.3
From Calendar API generated code in Calendar.java:
public com.google.api.services.calendar.model.FreeBusyResponse execute() throws IOException {
HttpResponse response = executeUnparsed();
}
We open an HttpResponse object but we never disconnect it.
Comment 1 by project member rmis...@google.com, Feb 3, 2012
(No comment was entered for this change.)
Status: Accepted
Comment 2 by aalb...@google.com, Feb 3, 2012
Yikes
Calling response.disconnect() throws a NPE because in HttpResponse.java:
public InputStream getContent() throws IOException {
LowLevelHttpResponse response = this.response;
if (response == null) {
return content;
}
InputStream content = this.response.getContent();
this.response = null;
We set the internal response to null.
Comment 3 by aalb...@google.com, Feb 3, 2012
calling disconnect() is not enough. There is also the content that needs to be closed.
I think that disconnect() should be renamed to close() and should look like this:
Calling both disconnect and closing the content fixed my memory leak. (after fixing the NPE of course.
Comment 4 by project member yan...@google.com, Feb 16, 2012
+1 on calling disconnect. I highly recommend reading the JavaDoc from the Android SDK on this topic: http://developer.android.com/reference/java/net/HttpURLConnection.html However, please also read the section on Performance. We definitely ideally want to reuse Sockets, so perhaps we should set the "http.keepAlive" system property to "false". So this should all be investigated carefully.
We might also want to investigate what the correct behavior should be for ApacheHttpTransport and UrlFetchHttpTransport.
As far as closing the streams properly, I think this has already been resolved. Let me know if you don't think that's the case.
Original issue: http://code.google.com/p/google-http-java-client/issues/detail?id=78
The text was updated successfully, but these errors were encountered: