Re: Issue with Changes to DefaultChannelFuture (Beta 2)‎

[Trustin Lee]

Hi Bob,

On Tue, Apr 28, 2009 at 8:26 AM, Bob Buffone <bbuffone at rockstarapps.com> wrote:
> <info>Excuse me if this message was already posted but I got an email saying
> I sent it from the wrong email address.</info>

Actually, it was posted twice. ;)

> In the last beta code that was released; a change to the
> DefaultChannelFuture is causing me some issues. The code for the await
> methods (await() and awaitUninterruptibly()) where changed to include a
> check for a deadlocking issue.
>
> Code Committed - http://www.jboss.org/netty/community.html#nabble-td2681425
> This is in response I assume for the Jira issue -
> https://jira.jboss.org/jira/browse/NETTY-140.

Yes, I did.

> This changes as it is committed now means that you can't use the await**()
> methods from inside any SimpleChannelHandler(s).  What I am doing in my code
> is based on a particular incoming message.  I am building a connection to
> another server to relay this information (if the connection isn't already
> built). I was using an await**() method to well wait until the connection
> was build so I could relay the information.
>
> Was this change intended to remove this as type of scenario?  or was there
> another issue?

This is a good example where you need to use addListener() instead.

If you wait until the connection attempt is done in your handler by
calling await*() method, then there's a chance where the caller I/O
thread is blocked until the connection attempt is done.  If an I/O
thread is blocked, other connections being handled by that I/O thread
will also be blocked, showing sudden performance drop.  It might not
be a big deal if the connection attempt is done very quickly, but
there's no way to guarantee that in network application development.
Does it make a sense for you?  I'd like to listen to you closely if
this change has broken your application.

Thanks,

— Trustin Lee, http://gleamynode.net/