Closed: (NETTY-85) Global Channel registry

Trustin Lee tlee at redhat.com
Tue Dec 2 00:24:29 EST 2008


Hi Frederic,

I thought about modifying the current implementation to give higher
priority to parent channels, but it seems like it doesn't solve the
problem because of a race condition because close request is an
asynchronous operation, there's still a chance for a child channel
is created until the close operation is done.

More clever (?) modification would be to enforce the close operation for
parent channels to be a blocking operation, assuming that it doesn't
take long time.  It usually doesn't take long time to close a server
socket channel.  WDYT?

Anyway, having a separate group just fixes the problem as you pointed
out. :)

On Tue, Dec 02, 2008 at 02:49:25AM +0900, Frederic Bregier wrote:
> 
> Hi Trustin,
> 
> You get it right. In fact, you suggested me some weeks ago
> that in order to shutdown correctly, one might want to
> first shutdown the parent channel, then the child channels,
> then the services (executors).
> Of course, this is specific for the server part (since client part
> has only simple channels).
> 
> So that's why I ask the question.
> 
> Maybe you can make an example for other users with the order you suggested
> before.
> For instance, on can create one group for all "parent" channels (if the
> application has
> more than one), then a group for all "child" channels (or maybe several if
> one wants
> to split these in several groups, but keep simple in the example I guess).
> Then the shutdown logic (with the two new features both on executors and
> groups)
> in the right order...
> 
> HTH,
> Frederic
> 
> 
> -----
> Hardware/Software Architect
 
-- 
Trustin Lee, Principal Software Engineer, JBoss, a division of Red Hat
--
what we call human nature in actuality is human habit
--
http://gleamynode.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/netty-dev/attachments/20081202/f2b2957f/attachment.bin 


More information about the netty-dev mailing list