About SimpleChannelHandler.channelDisconnected

brunodecarvalho kindernade at gmail.com
Wed Nov 3 18:44:57 EDT 2010


I'll assume you've got a properly structured application by now and that
you're not passing Channel's around your classes, so that your handler is
the only interface to the I/O layer.

If your handler (let's call it YourHandler) is not @Sharable, you will
probably have some methods like writeData(Data ...) and close(), that in
turn perform a call to Channel.write() and Channel.close() (since it's not
@Sharable, each instance of YourHandler will be associated with only one
Channel).

Given that you're asking how to distinguish between your call to close() and
a remote disconnection, I'll also assume that you want to perform different
routines for each case, maybe even trigger some recovery when you get a
remote disconnection.

Now picture the following (concurrent) scenario:
- You issue a call to YourHandler.close() (which calls Channel.close(),
generates a downstream event, which in turn will generate an upstream event
later on);
- At the exact same time a remote disconnection occurs, which generates an
upstream event;
- This is highly concurrent programming so there's no telling which event
will be processed first;
- By chance, the remote disconnection event is processed first so
YourHandler's channelDisconnected() method will be called and will act as if
it were handling a remote disconnection;
- But you had already called close()... there's a *great* chance that you no
longer care about remote disconnections - at this point, whether the channel
is closed remotely or locally, you want the graceful close() routine to take
place since, well, *you* wanted to close the channel anyway;

Using the flag automatically solves this problem. From the moment you call
close(), everything's "okay"; doesn't matter from which end the channel
closes first, it's always treated the same way.

Using the class of the event to determine the behaviour to adopt, however,
presents you with the obvious problem of a possible recovery routine
execution when you already called close() and you didn't really want this
routine to be executed.

I'd hardly call the flag a "hack".


Cheers,
  Bruno
-- 
View this message in context: http://netty-forums-and-mailing-lists.685743.n2.nabble.com/About-SimpleChannelHandler-channelDisconnected-tp5702676p5703504.html
Sent from the Netty User Group mailing list archive at Nabble.com.


More information about the netty-users mailing list