dev@grizzly.java.net

Re: premature connection closure with ARP (was: grizzly + arp + jruby problem)

From: Igor Minar <iiminar_at_gmail.com>
Date: Sun, 17 Jan 2010 21:59:03 -0800

I was able to make some progress on this one.

I believe that this really is a grizzly bug and is completely
unrelated to jruby.

I noticed that the connection is being closed by
TCPSelectorHander#postSelect calling SelectorThreadKeyHandler#expire,
which based on the value of SelectionKey#attachment decides if the
connection associated with the SelectionKey should be expired (closed).

When the requests are being made without ARP, the attachment is
usually KeepAliveThreadAttachment, which prevents the connection to be
closed prematurely. However, when ARP is used, the attachment is a
Long value, representing the timestamp of the beginning of the
request. Once the difference between the current time and the
timestamp is bigger than 30 seconds, the connection is closed.

Now my question is if this is the intended behavior or not.

If I understand how things currently work correctly, then with ARP on,
all the requests in grizzly/glassfish must finish before the 30 second
timeout is reached, or else the socket and socket channel will be
closed. That looks like a major bug to me.

Thoughts?

cheers,
Igor





On Jan 17, 2010, at 1:31 AM, Igor Minar wrote:

> hi guys,
>
> can anyone have a look at https://glassfish.dev.java.net/issues/show_bug.cgi?id=11445
> and let me know if you have any thoughts about what could be
> causing such a weird behavior?
>
> thanks!
>
> /i