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