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

[Trustin Lee]

Even if it didn't cause a problem so far, the performance of your
application will be impacted once the server you are connecting to
behaves badly and causes long timeout.  So, I still think you need to
migrate to ChannelFutureListeners.

If you did already, I'd like to know how difficult the migration was,
just in case the cost is too expensive.

Thanks,

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


On Sat, May 2, 2009 at 4:24 AM, Bob Buffone <bbuffone at rockstarapps.com> wrote:
> 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
>
>
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users
>
>