Hi Igor,
> 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.
Well, for sure if connection is being actively used - it shouldn't get
closed.
But solution doesn't look trivial to me. When ARP is used - the HTTP
request processing may be done in several steps on different threads,
while Channel itself will be parked (registered on Selector will no
SelectionKey.XXX interest), so basically processing will happen beyond
Grizzly control, and if we will disable timeout - then we will 100%
rely on custom application logic, that it will not forget to release
the Channel correctly. As a possible solution we can introduce some
kind of Async operation timeout, which will be different from regular
Channel timeout (some bigger timeout value). IMO we can have something
like that for 1.9.19.
What do you think?
WBR,
Alexey.
>
> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>