*TimeOutHandlers

[Trustin Lee]

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 yellowbook.com> 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
>
>
> christian wrote:
>>
>> see comments below
>>
>> On Mon, Feb 9, 2009 at 12:51 PM, Trustin Lee <trustin at gleamynode.net>
>> wrote:
>>> Great to hear that! :D
>>>
>>> Write timeout will not be fired very often because it is fired only
>>> when a message is not written within the specified timeout.  It will
>>> never be fired in most loopback device tests.  To see it fired, you
>>> will have to set the timeout around 1 ms.
>>
>> ah, I see. Sorry, I wasn't paying close attention to what the write
>> timeout is supposed to be and assumed it the same as in Mina.
>>
>>> Please note that it's different from MINA's writerIdle status.
>>> There's no counterpart in Netty at this point.  Do you find writer
>>> idleness notification useful?  For what case, out of curiosity?
>>
>> Regarding this, I just remembered that you asked me the very same
>> question in the MINA list ;-)
>> http://markmail.org/message/xswuaionip2gqjsk
>> (short summary: keep connection alive heartbeats for clients)
>>
>> christian
>>
>>
>>> Thanks!
>>>
>>> — Trustin Lee, http://gleamynode.net/
>>>
>>> On Mon, Feb 9, 2009 at 8:39 PM, Christian Migowski <chrismfwrd at gmail.com>
>>> wrote:
>>>> I am running some tests in parallel right now and so far it seems that
>>>> the issue is gone, hooray! :-)
>>>> Sorry for suspecting Netty in the first place, I am glad that this OS
>>>> shortcoming could be resolved that easy.
>>>>
>>>> Now there is only the problem that the writetimeout never fires
>>>> although it should.
>>>>
>>>> thanks,
>>>> christian
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Feb 9, 2009 at 12:30 PM, Trustin Lee <trustin at gleamynode.net>
>>>> wrote:
>>>>> Revision number in SVN is 813 FYI.
>>>>>
>>>>> — Trustin Lee, http://gleamynode.net/
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Feb 9, 2009 at 8:00 PM, Trustin Lee <trustin at gleamynode.net>
>>>>> wrote:
>>>>>> Thanks for a useful information.  The reason I was not able to
>>>>>> reproduce the problem is probably because I was running Windows in a
>>>>>> virtual machine.  :-(
>>>>>>
>>>>>> I've just checked in a revised version of HashedWheelTimer that uses
>>>>>> System.currentTimeMillis() instead of System.nanoTime().  Could you
>>>>>> tell me if it fixes the problem?
>>>>>>
>>>>>> — Trustin Lee, http://gleamynode.net/
>>>>>>
>>>>>> On Mon, Feb 9, 2009 at 6:54 PM, Christian Migowski
>>>>>> <chrismfwrd at gmail.com> wrote:
>>>>>>> Mr. Google reports that there are rumors in the Internet that
>>>>>>> System.nanoTime is broken on multicore systems (which I have), maybe
>>>>>>> this could be an issue? You're comparing and retrieving the nanotimes
>>>>>>> between multiple threads...
>>>>>>>
>>>>>>> I personally think that the resolution of System.currentTimeMillis()
>>>>>>> should be sufficient for connection idle issues. With that you can
>>>>>>> theoretically go as low as 1ms and that is far lower then a sane idle
>>>>>>> timeout should be set for a network connection.
>>>>>>>
>>>>>>> http://stackoverflow.com/questions/510462/is-system-nanotime-completely-useless/518438
>>>>>>> http://www.principiaprogramatica.com/?p=16
>>>>>>> http://blogs.sun.com/dholmes/entry/inside_the_hotspot_vm_clocks
>>>>>>>
>>>>>>> christian
>>>>>>>
>>>>>>> On Mon, Feb 9, 2009 at 10:26 AM, Christian Migowski
>>>>>>> <chrismfwrd at gmail.com> wrote:
>>>>>>>> Hi Trustin,
>>>>>>>>
>>>>>>>> I am using Windows XP SP2 with Java SE 1.6, to be precise:
>>>>>>>> java version "1.6.0_07"
>>>>>>>> Java(TM) SE Runtime Environment (build 1.6.0_07-b06)
>>>>>>>> Java HotSpot(TM) Client VM (build 10.0-b23, mixed mode, sharing)
>>>>>>>>
>>>>>>>> Upon further investigation, I found the inaccurateness occurs only
>>>>>>>> sometimes, but it sure follows very strange ways. Sometimes the
>>>>>>>> timeouts happen as they should but then they degenerate. Sometimes
>>>>>>>> the
>>>>>>>> timeouts start inaccurate, but getting more correct after some time.
>>>>>>>> I suspect a flaw in the implementation of the HashedWheelTimer, but
>>>>>>>> haven't got familiar with the source yet to point you to a specific
>>>>>>>> issue.
>>>>>>>>
>>>>>>>> I think you should be able to reproduce the behaviour, if the timer
>>>>>>>> starts correctly, keep it running for some time (5-10 minutes?), the
>>>>>>>> inaccurateness should show up then.
>>>>>>>> I'll list two examples below, the first one starts correct but gets
>>>>>>>> incorrect after 6:42 mins. the second one starts incorrect but after
>>>>>>>> 3:54 mins (and gets incorrect again).
>>>>>>>>
>>>>>>>> Sorry for not being able yet to give more detailed hints,
>>>>>>>> regards,
>>>>>>>>
>>>>>>>> christian!
>>>>>>>>
>>>>>>>>
>>>>>>>> Here the logs:
>>>>>>>>
>> <snip, unimportant>
>>
>> _______________________________________________
>> netty-users mailing list
>> netty-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/netty-users
>>
>>
>
> --
> View this message in context: http://n2.nabble.com/*TimeOutHandlers-tp2283992p2297572.html
> Sent from the Netty User Group mailing list archive at Nabble.com.
>
>
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users
>