1) add a method on HttpMethod to explicitly close a connection. This would be the simplest solution, but I think it would also defeat the purpose of connection reuse.
2) add a system for cleaning up/closing unused connections, perhaps after some timeout period. This is the better solution I think. Sam, if i remember correctly, you proposed something like this as an addition to the MultithreadedHttpConnectionManager. I would still like to take this idea and make it a little more generic for use with all connections. Hopefully I will find some time to work on this soon.
Thanks,
Mike
On Dec 7, 2003, at 11:07 PM, Sam Berlin wrote:
That's relying a bit too much on garbage-collection, which can happen at any time. You should never rely on garbage collection to clean up native resources, like open sockets, especially if you're concerned about such low level things as a CLOSE_WAIT state.
Thanks, Sam
On Sunday, December 7, 2003, at 10:56 PM, Jesus M. Salvo Jr. wrote:
Saw that too ...
Having said that, I am actually not reusing an HttpClient instance, and create a new one every time using an empty constructor ... and therefore a new instance of SimpleHttpConnectionManager. All of this happens inside of a method.
Now I would assume that, because my instances of HttpClient ( and therefore SimpleHttpConnectionManager ) are inside of a method, that after the method call, they would be out of scope, that the connection / socket should close (!?)
John
Sam Berlin wrote:
The reason this is happening is because the releaseConnection method of HttpMethods does not close the connection, it just returns it to the HttpConnectionManager for reuse by another HttpMethod. A 'Connection: Close' header tells HttpClient that this connection should be closed after the request is made (instead of leaving it open, for further HTTP/1.1 transfers).
Because the public API of HttpMethod has no 'close' method, and one would generally expect that, there is a misconception about what releaseConnection does. A suggestion that has been posted here before is adding an 'abort' method to HttpMethod and HttpMethodBase, the contents of which call close() on the underlying HttpConnection.
Thanks, Sam
On Sunday, December 7, 2003, at 10:31 PM, Jesus M. Salvo Jr. wrote:
From a snoop capture, Apache Coyote sent a TCP FIN 20 seconds after the last ACK from the client.
But the client did not sent a TCP FIN of its own, leaving the socket in CLOSE_WAIT.
The only difference between the Coyote's HTTP response and Orion's HTTP response is that the Orion response have "Connection: close" in the HTTP header.
So, what I did, by using HttpClient, I added:
postMethod.addRequestHeader( "Connection", "close");
After the above, I no longer have CLOSE_WAIT sockets.
Regards,
John
Jesus M. Salvo Jr. wrote:
HttpClient RC 2.0 64-bit Solaris 8 JDK 1.3.1_09
I am seeing lots of sockets in CLOSE_WAIT, despite the fact that "postMethod.releaseConnection();" is called.
This has happened so far against 2 of our ( different ) clients' webservers, mostly to Tomcat / Coyote.
The problem with CLOSE_WAIT sockets do not seem to be happening against Orion.
What happens in the long run is that I run of file descriptors
I am now able to reproduce the same problem against the client's test webservers ...
but in turnin on logging, the logging is not being logged on stdout.
In order to give meaningful results to this list about my CLOSE_WAIT problem,
I wrote a small class and script to replicate the problem, but still no logging.
Here is the sample shell script run on cygwin:
CLASSPATH=classes
CLASSPATH=$CLASSPATH\;/cvs/softgame-latest/development/lib/ commons- httpclient.jar
CLASSPATH=$CLASSPATH\;/cvs/softgame-latest/development/lib/ commons- logging.jar
REM CLASSPATH=$CLASSPATH\;/cvs/softgame-latest/development/lib/>>>> log4j.jar
java \
- Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.Sim ple Log \
-Dorg.apache.commons.logging.simplelog.showdatetime=true \
-Dorg.apache.commons.logging.simplelog.log.httpclient.wire=debug \
- Dorg.apache.commons.logging.simplelog.log.org.apache.commons.httpcl ien t=debug \
$JAVA_DEFINES -classpath $CLASSPATH HttpClientTest
Help !
Regards,
John
------------------------------------------------------------------- --
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-- Jesus M. Salvo Jr. Mobile Internet Group Pty Ltd (formerly Softgame International Pty Ltd) M: +61 409 126699 T: +61 2 94604777 F: +61 2 94603677
PGP Public key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0BA5348
-------------------------------------------------------------------- -
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-- Jesus M. Salvo Jr. Mobile Internet Group Pty Ltd (formerly Softgame International Pty Ltd) M: +61 409 126699 T: +61 2 94604777 F: +61 2 94603677
PGP Public key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0BA5348
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
