*TimeOutHandlers

[Dave Siracusa]

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.