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();

com.google.api.services.calendar.model.FreeBusyResponse result = response.parseAs(
    com.google.api.services.calendar.model.FreeBusyResponse.class);
result.setResponseHeaders(response.getHeaders());
return result;

}

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:

private void close() {
    try {
      final InputStream content = response.getContent();
      if (content != null) {
          content.close();
      }
      response.disconnect();
    } catch (IOException e) {
      // ignore
    }
}

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