Hi Oleg, Thank you for your reply.
You do not have to close the input stream returned by #getResponseBodyAsStream, as it is not guaranteed to close the underlying socket (in fact #releaseConnection() will be called behind the scene) but generally it is a good practice to do so.
Ok. But where and when will be the underlaying socket closed? I can't find this in the code :( Wait wait wait... This socket shouldn't be closed at all in order to satisfy (if needed) the "Keep-Alive" mode. So the socket is managed (in our case) by the MultiThreadedHttpConnectionManager I guess. Am I right?
I _suspect_ the server simply fails to send the closing chunk. If the message body appears to be in a consistent state you can just ignore the exception. You might want to investigate a little further, though. Enable the wire log and see if the closing chunk is indeed missing.
As we only observe this on mobile devices, I think this should be related to the GPRS connection, Windows Mobile or J9. But as this only happens sporadically, I guess we can just throw the exception to our client upper layers which will then display an error or retry.
Regards, Cyril Jaquier --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
