*TimeOutHandlers

Thu Feb 12 10:49:05 EST 2009

The SVN synchronization of JBoss.org doesn't seem to be working yet.
Let me paste the new classes:

  * IdleStateEvent: http://pastebin.com/m6e46ab40
  * IdleState: http://pastebin.com/m2e342d60
  * IdleStateHandler: http://pastebin.com/m360a6f87
  * DefaultIdleStateEvent: http://pastebin.com/m7bb72550

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

On Fri, Feb 13, 2009 at 12:43 AM, Trustin Lee <trustin at gleamynode.net> wrote:
> Glad that we are on the same page again. :-D
>
> I have made major changes as listed below:
>
>  * Renamed: IdlenessHandler -> IdleStateHandler
>  * Renamed: IdlenessEvent -> IdleStateEvent
>  * Added: IdleState enum which is consisted of READER_IDLE,
> WRITER_IDLE, ALL_IDLE
>  * Added: allIdleTime (bothIdleTime in MINA term)
>  * Changed: the default time unit (milliseconds -> seconds, which
> makes more sense)
>  * Added: callback methods in IdleStateHandler, ReadTimeoutHandler,
> and WriteTimeoutHandler so that you can define a custom behavior by
> extending them.  The default behavior is to fire IdleStateEvent, to
> raise ReadTimeoutException, and to raise WriteTimeoutException
> respectively.
>
> There might be other subtle changes I didn't list here by mistake, so
> please feel free to give me feed back and share your findings.  I
> think idle state detection and timeout handling is pretty much done
> now though, all thanks to both of you.  :)
>
> — Trustin Lee, http://gleamynode.net/
>
>
>
> On Wed, Feb 11, 2009 at 7:34 PM, Christian Migowski
> <chrismfwrd at gmail.com> wrote:
>> Trustin,
>>
>> sorry, somehow (wrote the mail before I had coffee) I misunderstood
>> your comments and thought you thought (oh boy) it would be useful to
>> get the timeout exceptions even if the channel is disconnected.
>>
>> We were always on the same page, I was just confused - thanks for clarification!
>>
>> I also did a quick test of the IdlenessHandler and it works like I was
>> thinking first it should (i.e. same as sessionIdle() in Mina), thanks
>> a lot! :-)
>> Since both both *TimeoutTasks report the write and the read idleness
>> (was this intentional? The *TimeoutTasks can access the last*Time
>> properties of the IdlenessHandler), I think you could remove one
>> TimeoutTask.
>>
>> What I mean is that is Handler:
>>        pipeline.addLast("idlehandler", new IdlenessHandler(timer,10000L,5000L));
>>
>> with this extension to my TestHandler:
>>    public void handleUpstream(ChannelHandlerContext ctx, ChannelEvent
>> e) throws Exception {
>>        if (e instanceof IdlenessEvent) {
>>            System.out.println(new
>> SimpleDateFormat("HH:mm:ss.SSS").format(new Date())+"idleness event:
>> "+e);
>>        }
>>        super.handleUpstream(ctx, e);
>>    }
>>
>> produces this output:
>> 1:15:15.508idleness event: NioAcceptedSocketChannel(id:
>> 64d52f74-011f-1000-bb5d-0139b1fabbcf, /127.0.0.1:9873 =>
>> /127.0.0.1:12345) - (IDLE: RW)
>> 11:15:20.508idleness event: NioAcceptedSocketChannel(id:
>> 64d52f74-011f-1000-bb5d-0139b1fabbcf, /127.0.0.1:9873 =>
>> /127.0.0.1:12345) - (IDLE: RW)
>> 11:15:20.523idleness event: NioAcceptedSocketChannel(id:
>> 64d52f74-011f-1000-bb5d-0139b1fabbcf, /127.0.0.1:9873 =>
>> /127.0.0.1:12345) - (IDLE: RW)
>> 11:15:25.539idleness event: NioAcceptedSocketChannel(id:
>> 64d52f74-011f-1000-bb5d-0139b1fabbcf, /127.0.0.1:9873 =>
>> /127.0.0.1:12345) - (IDLE: RW)
>> 11:15:30.523idleness event: NioAcceptedSocketChannel(id:
>> 64d52f74-011f-1000-bb5d-0139b1fabbcf, /127.0.0.1:9873 =>
>> /127.0.0.1:12345) - (IDLE: RW)
>>
>>
>>
>> regards,
>> christian
>>
>> On Wed, Feb 11, 2009 at 10:42 AM, Trustin Lee <trustin at gleamynode.net> wrote:
>>> On Wed, Feb 11, 2009 at 5:12 PM, Christian Migowski
>>> <chrismfwrd at gmail.com> wrote:
>>>> On Wed, Feb 11, 2009 at 6:01 AM, Trustin Lee <trustin at gleamynode.net> wrote:
>>>>> 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.
>>>>
>>>> Really? Maybe thats where an architectural overview of Netty and its
>>>> design goals would have come in handy, are Netty channels "reusable"?
>>>> I was under the impression that you'll get a "new" channel when the
>>>> client connects again to the server or if you do a new connect() with
>>>> a client.
>>>
>>> I'm not sure we are on the same page.  Let me rephrase what I meant to
>>> avoid misunderstanding:
>>>
>>> 1) ReadTimeoutException should not be raised when a Channel is disconnected.
>>> 2) ReadTimeoutException should be raised periodically while a Channel
>>> is connected.
>>>
>>>> Could you outline a little bit why a Channel should raise the
>>>> ReadTimeoutException when it predictably will raise that exception
>>>> because there is nothing to read (channel disconnected)? You _can_
>>>> detect a disconnection with channelDisconnected(...), right?
>>>
>>> Yes, we can detect a disconnection with a channelDisconnected event
>>> and ReadTimeoutException should not be raised unless a Channel is
>>> connected.
>>>
>>> BTW, I have checked in IdlenessHandler which might fulfill your needs,
>>> but it seems like it's not being synchronized to the anonymous SVN
>>> repository at this moment.  Let me paste it for your convenience:
>>>
>>>  * IdlenessHandler - http://pastebin.com/m66e1e937
>>>  * IdlenessEvent - http://pastebin.com/m4bc7d5c5
>>>  * DefaultIdlenessEvent - http://pastebin.com/m6ea6b5b
>>>
>>> Once the synchronization between the committable repository and the
>>> read-only repository is recovered, they should appear here:
>>>
>>>  * http://fisheye.jboss.org/browse/Netty/trunk/src/main/java/org/jboss/netty/handler/timeout
>>>
>>> Thanks for the feed back,
>>>
>>> — Trustin Lee, http://gleamynode.net/
>>>
>>> _______________________________________________
>>> netty-users mailing list
>>> netty-users at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/netty-users
>>>
>>
>> _______________________________________________
>> netty-users mailing list
>> netty-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/netty-users
>>
>