Hi all,
First, thank you for httpclient. I've found that Sun's implementation
freezes every so often, and GNU HttpClient is not being actively
developed (and has some problems re: socket SoTimeouts).
I have a Tomcat server (4.1) on one side, and a Jakarta httpclient (2.0
alpha 2) on the other side, with connections managed by a
MultiThreadedHttpConnectionManager.
I am trying to make sure the client doesn't close connections needlessly
regardless of server persistent timeout value. Through some
experimentation, I verified that Tomcat is by default set up to close a
connection after 15 seconds. That is, a network trace shows the [FIN,
ACK] packet being sent from the server 15 seconds after the response,
and that is [ACK]ed by the client.
So, if the client sends a request and receives a response, but doesn't
close the connection, then I'm safe sending another request within 15
seconds.
However, if I send another request after 15 seconds,
HttpMethodBase.execute throws an HttpRecoverableException in
HttpMethodBase.processRequest > HttpMethodBase.readResponse >
HttpMethodBase.readStatusLine, with message
"org.apache.commons.httpclient.HttpRecoverableException: Error in
parsing the status line from the response: unable to find line starting
with \"HTTP/\"".
However, if the client were instead to send a request to a server which
simply doesn't respond, and I have called HttpConnection.setSoTimeout,
HttpMethodBase.execute also throws an HttpRecoverableException, this
time in HttpMethodBase.processRequest > HttpMethodBase.readResponse >
HttpConnection.readLine, with message "java.net.SocketTimeoutException:
Read timed out".
In either case, the request is not retried, and the connection is closed.
I would like to tell the two cases apart, and the only way I can figure,
outside of altering httpclient code, is to look at the exception message
to see if it contains HttpRecoverableException in it. I hate to do that,
because relying on the message in an exception is probably dangerous,
being subject to change.
Is it at all possible to put some code in HttpMethodBase or
HttpConnection to detect before *writing* a request that the connection
was closed from the server? This would kind of implement a suggestion in
RFC 2616, section 8.1.4, that (talking about persistence)
"Clients and servers SHOULD both
constantly watch for the other side of the transport close, and
respond to it as appropriate."
and
"Client software SHOULD reopen the
transport connection and retransmit the aborted sequence of requests
without user interaction so long as the request sequence is
idempotent (see section 9.1.2). Non-idempotent methods or sequences
MUST NOT be automatically retried, although user agents MAY offer a
human operator the choice of retrying the request(s). Confirmation by
user-agent software with semantic understanding of the application
MAY substitute for user confirmation. The automatic retry SHOULD NOT
be repeated if the second sequence of requests fails."
Would that make sense?
Thanks for your consideration,
--Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
