*TimeOutHandlers

[Christian Migowski]

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
>