*TimeOutHandlers

[Christian Migowski]

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>