*TimeOutHandlers

[Christian Migowski]

I just can't stop ;) (to my defense: i am belaboring this issue
because it offers me a good "hook" to learn and understand more about
Netty which i intend to use for some rather important projects)

On Fri, Feb 13, 2009 at 6:55 AM, Trustin Lee <tlee at redhat.com> wrote:
> As an alternative, I added constructors which doesn't require
> ticksPerWheel, and therefore a user can choose the precision of the
> timer pretty easily.  (e.g. new HashedWheelTimer(1, SECONDS))  The
> default ticksPerWheel is 512, which should work fine in general.  BTW
> I think most people should be fine with using the default constructor,
> which has the sensible default.
>
>> The creation of the timer could be even integrated in the constructor
>> of the timeout handlers.
>
> This can be somewhat confusing.  For example, a user can create
> thousands of HashedWheelTimer threads if he or she doesn't understand
> what is created inside the timeout / idle state handlers.  So, I'd
> like to keep it as it is.  Instead, I'm going to implement a shared
> resource explosion detector, which gives a user warning when expensive
> resources are created too much (e.g. 1000 HashedWheelTimers or 1000
> ChannelFactories)

The integrated Timer could be made static (as another alternative,
i.e. timer = staticTimer; if used so) in the timeout handlers to avoid
the scenario you described. This would simplify the timeout handler
api (the timer is just needed for the timeout handlers so could be
created internal)

>> 4) personal wish
>> any chance that the IdleStateEvent gets promoted to a "proper"
>> UpstreamEvent (i.e. there will be a channelIdle() method in
>> ChannelUpstreamHandler)?
>
> I think I can create IdleStateAwareChannelHandler in the
> org.jboss.netty.handler.timeout package, which extends
> SimpleChannelHandler instead.  I think this is the beauty of Netty's
> flexible event model and this should work for you. ;)

Also for the sake of of a simple and convenient api i still think it
should be in SimpleChannelHandler instead of having an additional
class (IdleStateAwareChannelHandler). Sure, if a user doesn't have a
timeout handler in its pipeline the channelIdle method will never be
called, but this is the same for all the DownstreamEvents (resp. their
methods) that do not apply their current "whatever_this_netty_term_is"
(you know, e.g. channelBound and channelUnbound will never be called
if it is a ClientBootStrap pipeline).
And detecting idleness isn't such an uncommon use pattern which could
be "advertised" in one of Nettys most important API classes. (The
ReadTimeoutHandler is only there to be capable of handling it in an
SimpleChannelHandler instance, no?)


But after all it's your framework and I want to state explicitly that
the API is quite good already as it is (it just could be even better
;)).


regards,
christian!