Hi Matthew,
Thank you for useful information.
Maybe it seems that this problem is same to your problem.
And I agree with your analysis.
Thanks.
--
Bongjae Chang
----- Original Message -----
From: Matthew Swift
To: dev_at_grizzly.dev.java.net
Sent: Tuesday, June 16, 2009 2:18 AM
Subject: Re: About TIME_WAIT remain
I recently encountered a similar problem (perhaps the same?) in OpenDS.
I was finding that both client and server TCP sockets would be left in TIME_WAIT after a client disconnect. Usually, only the peer which initiates the disconnect should be left in the TIME_WAIT, with the non-initiating peer left in CLOSED (IIRC).
In fact, what was happening was that the client would send an LDAP unbind request to the server and then disconnect. On receipt of the unbind request, the server would also disconnect. This results in both client and server effectively simultaneously initiating a close and, as per RFC 793, ending up in the TIME_WAIT state - see figure 14 / section 3.5 in the RFC:
http://tools.ietf.org/html/rfc793#section-3.5.
I don't know if this is the problem that you are seeing - I too didn't find using setReuseAddress helped (this JDK documentation seems to indicate that the option is only valid for datagram socket implementations).
My workaround (or hack!) was to implement my own application-level time wait: on receipt of a client unbind request I put the server side connection into a "close pending" queue. After a small period of time, e.g. 20ms, this pending queue is flushed and all connections in it are closed. This gives the client a chance to initiate the close and for the server to receive it.
Of course this model only works for cases where it is appropriate for the client to initiate the close (for example in LDAP this is indicated by the client sending an unbind request, HTTP AFAIK does not have anything like this).
Matt
Jeanfrancois Arcand wrote:
Salut,
Bongjae Chang wrote:
Hi,
When I tested my attached sample, I found that TIME_WAIT connection
remained for a while on both Windows and Linux.
Test program is very simiple.
1. create a controller with a server TCPSelectorHandler.
2. create a new client socket and connect the server.
3. close the client socket and stop the controller.
I don't know why TIME_WAIT state remains though I close both the server
and client cleanly.
I think you can also reproduce this in some Grizzly's unit test cases
which use a TCPIOClient like BaseSelectionKeyHandlerTest.
This TIME_WAIT state may be meaningless because Grizzly sets
setReuseAddress to be true.
But I am curious to know why TIME_WAIT state doesn't disappears fast.
I think this is OS related, e.g the underlying socket will be completely
destroyed based on some OS configuration. I've Googled the TIME_WAIT and
found:
http://www.developerweb.net/forum/showthread.php?t=2941
So I do think we can do something on our side. What do you think?
A+
-- Jeanfrancois
Please advice me.
Thanks.
--
Bongjae Chang
------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
--
Matthew Swift Sun Microsystems Inc.
OpenDS Core Developer Directory Services
http://blogs.sun.com/mattswift/ https://www.opends.org/