*TimeOutHandlers

Trustin Lee trustin at gleamynode.net
Wed Feb 11 00:01:30 EST 2009


I was able to reproduce the problem Dave and Christian reported and
have just checked in the fix.

I'm still not sure ChannelReadTimeoutException should be fired only
once while a channel is connected.  I think it's just fine to raise
the exception periodically, and it's sometimes useful.

Anyway, another handler related with reader/writer idleness will be added.

— Trustin Lee, http://gleamynode.net/



On Tue, Feb 10, 2009 at 5:35 PM, Christian Migowski
<chrismfwrd at gmail.com> wrote:
> Maybe its irrelevant now since Trustin is reworking the timeout
> handling, but I can confirm the behaviour Dave noticed. If a channel
> is disconnected, the ReadTimeoutExceptions for this channel
> (ChannelHandlerContext ctx.getChannel() returns the same id) continue
> to fire.
> That should not be IMHO.
>
> christian!
>
>
>
> On Mon, Feb 9, 2009 at 9:08 PM, Dave Siracusa
> <dave.siracusa at yellowbook.com> wrote:
>>
>> Hi Trustin
>>
>> I setup a test where no timeout exceptions should occur.
>> After my tests have completed I start to get periodic exceptions, I can only attribute this to the new timer.newTimeout created in the run.
>> If I leave it idle after running a test I find it often continues to throw exceptions forever with no client activity.
>>
>> Dave
>>
>> ________________________________
>> From: Trustin Lee-3 (via Nabble) [mailto:ml-user+162222-252043752 at n2.nabble.com]
>> Sent: Monday, February 09, 2009 2:51 PM
>> To: Siracusa, Dave (YBUSA-KOP)
>> Subject: Re: *TimeOutHandlers
>>
>> Hi Dave,
>>
>> Do you mean that ReadTimeoutException is raised more than once when
>> nothing is read from the remote peer?  If it is raised periodically
>> with the delay you specified in the ReadTimeoutHandler's constructor,
>> then it's an expected behavior.
>>
>> However, I am leaning toward your opinion that ReadTimeoutException
>> should be raised only once and Christian's opinion that there should
>> be an alternative handler that notifies 'idleness' in a different way
>> (i.e. different event type.)  Please stay tuned for this thread - will
>> come up with a better solution soon.
>>
>> Thanks!
>>
>> - Trustin Lee, http://gleamynode.net/
>>
>>
>>
>> On Mon, Feb 9, 2009 at 11:57 PM, Dave Siracusa
>> <dave.siracusa at ...<http://n2.nabble.com/user/SendEmail.jtp?type=node&node=2299041&i=0>> wrote:
>>
>>>
>>> I pulled the latest code to test the timeout functionality.
>>> I modified the HttpServer to accept a parameter that delays response.
>>> I modified my http proxy server to use ReadTimeoutHandler.
>>>
>>> I receive spurious ChannelReadTimeoutExceptions.
>>> I commented out the timer.newTimeout's in ReadTimeoutTask.run to keep from
>>> receiving these exceptions.  BTW - I posted a comment on this already.
>>>
>>> Best,
>>> --Dave
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users
>




More information about the netty-users mailing list