Hi John,

Yes, the problem is that releaseConnection() does not explicitly close the connection, unless there is a Connection: close header. This is because HttpClient makes an attempt to reuse connections where possible. In 2.0 you have a couple of options:

- Reuse instances of HttpClient or the associated HttpConnectionManager, this may have threading implications.
- Add a "Connection: close" and/or "Proxy-Connection: close" header to all methods. This should work in most cases, assuming that the server echoes the header in the response.
- Implement a custom HttpConnectionManager.
- If using the SimpleHttpConnectionManager, call connectionManager.getConnection().close() after executing each method.


None of these solutions are ideal, but they are the only real options for 2.0. A solution for post-2.0 has been discussed and will be implemented when time permits. Please feel free to post suggestions or patches.

Thanks,

Mike

On Dec 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.Simp le 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.httpcli en 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]



Reply via email to