ChannelUpstreamHandler.handleUpstream bug - InterestOps changed

[Trustin Lee]

I agree that the current threading model of Netty is far from perfection.
My current focus in Netty 4 is to revamp the event loop so that a user gets
a consistent and comprehensive thread model.  Meanwhile, please keep in mind
some events can be fired from a different thread.
On Sep 16, 2011 3:37 AM, "grhwood at gmail.com" <grhwood at gmail.com> wrote:
> Hi,
>
> messageReceived and channelInterestChanged are for different events, so
you cannot expect them to be called in same thread.
>
>
> On 9/15/2011 8:13 PM, Kr0e wrote:
>> Hi,
>>
>> I think I found a bug:
>>
>> The Doc of the ChannelUpstreamHandler says:
>>
>> * {@link #handleUpstream(ChannelHandlerContext, ChannelEvent)
>> handleUpstream}
>> * will be invoked sequentially by the same thread (i.e. an I/O thread)
and
>> * therefore a handler does not need to worry about being invoked with a
new
>> * upstream event before the previous upstream event is finished.
>>
>> But I've found that this does not apply:
>>
>> @Override
>> public void channelInterestChanged(ChannelHandlerContext ctx,
>> ChannelStateEvent e) throws Exception {
>>
>> System.out.println("INTER : " + Thread.currentThread());
>>
>> // Super
>> super.channelInterestChanged(ctx, e);
>> }
>> @Override
>> public void messageReceived(ChannelHandlerContext ctx, MessageEvent e)
>> throws Exception {
>>
>> System.out.println("RECV : " + Thread.currentThread());
>> }
>>
>> RECV : Thread[New I/O server worker #1-1,5,main]
>> INTER : Thread[New I/O client worker #1-1,5,main]
>> INTER : Thread[main,5,main]
>> RECV : Thread[New I/O server worker #1-1,5,main]
>> INTER : Thread[New I/O client worker #1-1,5,main]
>> INTER : Thread[main,5,main]
>> RECV : Thread[New I/O server worker #1-1,5,main]
>> INTER : Thread[New I/O client worker #1-1,5,main]
>> INTER : Thread[main,5,main]
>> RECV : Thread[New I/O server worker #1-1,5,main]
>> INTER : Thread[New I/O client worker #1-1,5,main]
>>
>>
>> As you can see the super method handleUpstream is not always called by
the
>> same thread. This causes a race condition in our software.
>>
>> In our software the client sends as fast as possible data to the server.
If
>> the client channel is not writable the client waits until it is writable
and
>> continues. The server receives the data. The server handles the data in
an
>> extra thread pool. If the server receives data too fast it calls
>> channel.setReadable(false);. But when the server is able to process more
>> data and calls channel.setReadable(true); the method
>> channelInterestChanged(...) is called concurrently which causes a race
>> condition.
>>
>> Is this intended ?
>>
>> Regards,
>>
>> Chris
>>
>> --
>> View this message in context:
http://netty-forums-and-mailing-lists.685743.n2.nabble.com/ChannelUpstreamHandler-handleUpstream-bug-InterestOps-changed-tp6796758p6796758.html
>> Sent from the Netty User Group mailing list archive at Nabble.com.
>> _______________________________________________
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/netty-users/attachments/20110916/40508274/attachment.html