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

[Bob Buffone]

This didn't cause an issue with the a production application so it was more
of an email to fetch information. I will look into using the listeners.

Bob (Buffone)

On Tue, Apr 28, 2009 at 7:53 PM, Trustin Lee <tlee at redhat.com> wrote:

> 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/
>
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/netty-users/attachments/20090501/6b65ee04/attachment.html