Re: 5 seconds after response before a FIN is sent

From: Pete Hendry <>
Date: Tue, 05 Apr 2005 10:55:56 +1200


I believe you are seeing the effects of persistent connection behaviour
(HTTP/1.1) built into the JDK. The default persistent connection timeout
(from memory) is 5 seconds. This means that when you finish with the
connection it is returned to a connection pool where it awaits reuse
(when you close it, it is not really closed). If it is not resused
within 5 seconds then it is removed from the pool and closed. It is at
this point you see the FIN being sent. I'm not sure what Tomcat does for
persistent connection timeouts, but it may also be 5 or (as with Jetty)
10 seconds so the client is likely to time out first and send the FIN.

I believe you can stop this happening by setting the "Connection: close"
parameter on the connection. It's a while since I dealt with this so
this could be wrong. You will lose the "benefits" of persistent
connections but you will also stop connections hanging around on the
server potentially holding onto threads (this can become a problem in
Jetty). Of course, if other clients connect to the server then they will
most likely exhibit this behaviour too.


Matt Swensson wrote:

>I am not sure if this is specific to jax-rpc, but I am using a jax-rpc
>implementation, generating from a WSDL.
>What I am seeing while sniffing the network is that my client
>application sends a request, gets back a response, and then 5 seconds
>later, it sends a FIN to let the service know it is done. I am not
>sure why this is happening and was wondering if maybe there is some
>setting (unknown to me) to have the FIN sent at the end of request
>instead of waiting 5 seconds after a response is received to notify the
>More info
>This app is running inside tomcat.
>The message factory impl being used is
>Yahoo! Messenger
>Show us what our next emoticon should look like. Join the fun.
>To unsubscribe, e-mail:
>For additional commands, e-mail: