Android & Multithreaded HTTP-Requests

During the last 3 days on my new job at Sense Networks in New York I was supposed to fix some issues in a project concerning multi threaded http requests in an Android application. At first I thought it’d be a pretty easy task even though I never really used HttpConnectionManager before. So I started reading a bit about it and created some classes, interfaces and stuff like that to have a nice and generic architecture for the project. In fact I am using the MultiThreadedHttpConnectionManager (httpclient-3.x) but Android calls it ThreadSafeClientConnManager as it’s called in the httpclient-4.x which is currently in an alpha stadium.
After the first steps of implementing and testing the test application was throwing exceptions and I just couldn’t figure out why. It seemed to be totally random, the exception as well as the time it shows up. So I started reading tons of different tutorials for Android as well as for the Java2SE httpclient. No one seemed to experience the same problem and I admit it felt a bit like doing some basic newbie stuff wrong without knowing about it. After hours of research and testing the “bug” was finally found and it still seems to be pretty stupid but when you think about it, I’d say it isn’t that stupid. From my point of view it’s something that should be handled by the virtual machine, so for Android by Dalvik:
The response of a http request contains and entity which provides access to the content in form of an inputstream and this content has to be consumed otherwise it’ll never be removed from the memory even if you close/abort the request. Funny thing about this: I read ~50 pages, tutorials and threads but just one mentioned that in a comment line…
As all my tests were just sending a request to the given uri and then checking out the StatusLine for a possible error code the the response was closed if no error code was sent and “everything was fine”. At least that’s what I thought. In fact the sockets were still open, waiting for the empty content of the response to be consumed. So after some requests the memory was full and trying to open a new connection or sending a new request ended up in different exceptions (e.g. Timeout, Unknown Host, Connection refused). After figuring this out, the fix was quite easy. Now, before closing the response, the program consumes the content – even if it is empty – and then the vm cleans it up as expected. No more exceptions and everything works fine :)

By the way, you might want to check out CabSense ;)

To get notified about new posts, just enter your email address on the right :)

One comment

  • Are you sure that MultiThreadedHttpConnectionManager is called ThreadSafeClientConnManager in 4.x?

Leave a Reply