Details
-
Type:
Bug
-
Status:
Resolved
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 6.1.25
-
Fix Version/s: None
-
Component/s: Client
-
Labels:None
-
Environment:Mac OS X 10.6.4 / x64 / java 1.6.0_22; vm version: 17.1-b03-307
-
Number of attachments :
Description
Dus to an error in our HTTP server, it responded with two times the same response to an HTTP request from the Jetty client. The client will log the following warning:
"Unexpected data received but no request sent"
After a number of requests, the client could not send any requests to the server anymore until it was restarted.
Analysis showed that the handling of the "unexpected data" closes the HttpConnection (line 170 of HttpConnection.java) but it does not tell the HttpDestination that it is closed. The HttpDestination still thinks this connection is in use and will open a new connection for the next request. This will continue until the maximum number of connections per destination is reached (default 32) and new requests to this destination will be queued and are never sent.
I don't understand the code well enough to deliver a patch, but I suspect we should be calling _destination.returnConnection().
Activity
| Field | Original Value | New Value |
|---|---|---|
| Assignee | Greg Wilkins [ gregw ] |
| Assignee | Greg Wilkins [ gregw ] | Michael Gorovoy [ mgorovoy ] |
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Resolution | Fixed [ 1 ] |
Looks like we are also facing a similar issue in one of our application where we are using the client to send data to the server on an SSL channel. This application is replicating some data from various client machines to the server machine in real time. The sender component (utilizing the client) works for a few days without any issues, but suddenly it stops sending data until the application is restarted. Once restarted everything works fine. Unfortunately we have not turned on the logging for the jetty client portion and can't see the log message as stated above in the description of the issue. From whatever logs we have it is pretty certain that it seems to be stuck in the "waitforDone" call. once the application is stopped we can see it move to the next line in code.
Following is some code to give an idea of what is being done:
init()
{ httpClient.setConnectorType(HttpClient.CONNECTOR_SELECT_CHANNEL); httpClient.setMaxConnectionsPerAddress(1); httpClient.setMaxRetries(0); httpClient.setSoTimeout(120 * 1000); //default 2 minutes httpClient.setTimeout(120 * 1000); //default 2 minutes }startup()
{ httpClient.start(); contentExchange = new ContentExchange(true); contentExchange.setRetryStatus(false); contentExchange.setTimeout(120*1000); }send()
{ ByteArrayInputStream bis = new ByteArrayInputStream(bytes); contentExchange.setTimeout(dynamic - 10 seconds to few minutes, depending on the size to be transmitted); contentExchange.setRequestContentSource(bis); httpClient.send(contentExchange); }we are using a synchronous exchange so after the send its a waitForDone
contentExchange.waitForDone();
and then after it returns, whether success or failure the "ContentExchange" object is re-initializaed:
{ contentExchange = new ContentExchange(true); contentExchange.setRetryStatus(false); }resetExchange()
This software is already running in almost 1500 client machine and it is really critical for this application to run in high availability mode.
Client Machine Environment: Jetty release 6.1.26 on JRE 1.6.0_22-b04 on Windows XP service pack 2 and Windows 2000 SP 4.
Server Machine Environment: Windows 2003 server (32 bit), ASP.NET application on Microsoft IIS 6.0 Web server.
This is a really urgent issue for us to resolve. Could this also be related to: Jetty-1141 (Too many sockets in TIME_WAIT causes HTTPClient.waitForDone() to never return)
Greg, should we try the fix suggested in the description or Will it do us any good to do the exchange in async mode and we can notify a cancel in case our internal timer expires if the intended timeout in client does not happen.
Any other suggestions are welcome. Please help!!