Hi Tim, > I am using HttpClient 3 to send serialised objects to a servlet and back > again. I use the getResponseAsStream() on the post method to deserialise > responses. All works fine, until I sent back larger objects. Then the > close() on the inputStream or the releaseConnection() blocks for several > seconds, even thought I have already read the Object in.
When the stream is closed or the connection returned, HttpClient will try to consume the rest of the data in the stream, in order to re-use the connection. Possible reasons for the delay are: 1. The stream contains (lots of) unread data, for example some extra information generated by serialisation that did not have to be read back for the deserialization. 2. The stream contains nothing anymore, but the HttpClient can't detect this because of some problem on the server side. For example, the last, empty chunk indicating the end of the response body did not get sent to the client because the server didn't call flush() on the stream. Please enable the wire log to locate the origin of the problem: http://jakarta.apache.org/commons/httpclient/logging.html If you have control of both the client and the server, check the server side first to make sure all data that is supposed to be sent is actually flushed, and maybe the output stream closed. If that doesn't help or if you don't have access to the server, send a "connection: close" header with the request or use HttpMethod.abort() instead of stream.close(). This should prevent HttpClient from consuming the rest of the input stream. hope that helps, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
