Hi Igor,
>>>> The problem with workaround I see - connection will *never*
>>>> timeout, which may create a lot of idle connections registered on
>>>> a Selector. I think here we should implement the similar solution
>>>> as Comet, in other words create specific ARPAttachment, which
>>>> will not let framework to close connection after 30 seconds (by
>>>> default), but use another ARP timeout, which would be used until
>>>> HTTP request is being processed, once processing is done - we
>>>> switch back to 30 seconds idle timeout.
>>>
>>> But what should the timeout be? And how will you coordinate
>>> between commet timeout, the default ARPAttachment timeout, and a
>>> timeout of another filter if they all try to attach their
>>> attachment to the key?
>> The Comet framework should attach CometAttachment, only in case,
>> when it detects, that the Request is targeted to a Comet resource.
>> So in this case, IMO, it's ok, that Comet uses own attachment type.
>> I guess the timeout problem you see appears, when Comet attaches
>> nothing, in such a cases we have to implement general ARPAttachment
>> to prevent connection from been closed.
>
> yeah, but what should the timeout be? I don't think that any
> hardcoded number will work well because it might be too high or too
> low. The only proper way to handle this is to have Adapters talk to
> the ARPAttachments and renew them somehow in order to keep the
> connection open, but that is turning into a somewhat complex change.
IMO we should follow the approach we currently have. For non ARP case
we have transaction timeout value, which doesn't let single request
occupy a working thread forever, for sure by default this timeout is
longer than 30s (5m AFAIR). The same situation for Comet, we have
special idle timeout value, which doesn't let single Comet request to
last forever.
30s timeout interval for ARP is a bug, because this timeout interval
should be applied only for idle connections. With ARP we have an
issue, that we don't mark somehow connection, which is being
processed, and Grizzly thinks, that connection is idle, when it's not.
But anyway, I think we should have some timeout value even for long
lasting connections.
Thanks.
WBR,
Alexey.
>
> /i
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>