On Jan 21, 2010, at 2:44 AM, Oleksiy Stashok wrote:
>>> 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.
/i