Hi Alexey,
On Jan 18, 2010, at 2:42 AM, Oleksiy Stashok wrote:
> 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?
I don't know. I'm not crazy about just increasing the timeout.
How does comet get around this issue? Won't all the comet connections
get closed after 30 seconds?
/i
>
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>