*TimeOutHandlers

[Christian Migowski]

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