>>> 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?
No, comet has own attachment type: CometTask.
WBR,
Alexey.
>
> /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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>