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/