Eric,
I don't know what I can add beyond what has already been written in this
thread. I haven't following Netty development so I don't know if this is
still the case or not. At the time, a channel was bound to a thread in an
EventExecutorGroup, so you could run into a situation where a group of
channels that were all bound to the same thread would be under serviced if
one of those tasks took a lot of CPU time. If instead you delegate to a
standard ExecutorService, each task for a given channel might run on a
separate thread so a single task couldn't starve all of the channels.
Kind regards,
Sean
On Friday, February 9, 2018 at 8:40:00 PM UTC-5, Eric Fulton wrote:
>
> Hey sorry I know this is a very old thread, but can you explain why in you
> example you think it would be better to use your own ExecutorService over
> someEventExecutorGroup? What would be the difference?
>
>
>
>
> On Wednesday, October 9, 2013 at 7:27:06 AM UTC-7, Sean Bright wrote:
>>
>> Thanks Norman.
>>
>> So based on this, it seems that if I have a "typical" pipeline:
>>
>> ctx.pipeline().addLast("decoder", new MyProtocolDecoder());
>> ctx.pipeline().addLast("encoder", new MyProtocolEncoder());
>> ctx.pipeline().addLast(someEventExecutorGroup, "handler", new
>> MyProtocolHandler());
>>
>> Using an EventExecutorGroup doesn't actually buy me anything. I/O won't
>> be blocked, but handler execution will.
>>
>> I understand the point of doing all of this - if you know your methods
>> will always be called on the same thread it reduces the synchronization
>> complexities in the handlers - but in this model when you are dealing with
>> hundreds of connections, any handler method that causes a delay in
>> processing will block (num_connections / num_event_executor_threads) - 1
>> other handlers.
>>
>> So it would appear that in order to get the behavior that I want (any one
>> connection should not affect another), I would eliminate the
>> EventExecutorGroup and would need to submit tasks to an ExecutorService
>> that I manage myself, correct?
>>
>> I guess I just don't see how an EventExecutorGroup is beneficial.
>>
>> In any case, I love Netty. Keep up the good work!
>>
>>
>> On Tuesday, October 8, 2013 11:40:30 AM UTC-4, Sean Bright wrote:
>>>
>>> Greetings,
>>>
>>> I just want to validate my understanding of Netty 4's thread model
>>> compared to Netty 3's (specifically as it applies to NIO).
>>>
>>> With Netty 3, you would specify a boss thread pool and a worker thread
>>> pool (all/most of the examples use Executors.newCachedThreadPool() with the
>>> default args). ChannelHandler events would be called on the I/O threads
>>> from the worker group. Any delay in the handler methods would cause a
>>> delay in processing I/O for other connections. In order to compensate for
>>> this, you could add an ExecutionHandler to the pipeline which would cause
>>> the handler methods to be fired on an executor thread and therefore
>>> wouldn't affect I/O.
>>>
>>> In Netty 4, you specify a boss group and worker group, and as channels
>>> connect they are registered to specific threads. So channel 1 will always
>>> have it's handler events fired on thread A, channel 2 will always have it's
>>> handler events fired on thread B. Again, any delayed processing that
>>> occurs in the handler method will hurt I/O for other channels registered to
>>> that worker thread. To compensate, you specify an EventExecutorGroup so
>>> that I/O is not affected with long running tasks.
>>>
>>> Assuming everything above is correct...
>>>
>>> Assume that I create a DefaultEventExecutorGroup, passing 4 as the
>>> number of threads, and assign that to my handler in the pipeline. Now, 8
>>> channels connect:
>>>
>>> Channel A: EventExecutor 1
>>> Channel B: EventExecutor 2
>>> Channel C: EventExecutor 3
>>> Channel D: EventExecutor 4
>>> Channel E: EventExecutor 1
>>> Channel F: EventExecutor 2
>>> Channel G: EventExecutor 3
>>> Channel H: EventExecutor 4
>>>
>>> Each channel is registered to EventExecutor thread. If Channel A in the
>>> above example performs a long running task (say, in channelRead0), then
>>> won't Channel E be blocked during this time? Is that correct or am I not
>>> understanding something? If I am correct, why would I ever want to use an
>>> EventExecutor? I feel like I would be better off using a shared Executor
>>> directly from my handler methods (and handling thread synchronization
>>> myself). At least in that case I wouldn't be blocking other clients.
>>>
>>> Thank you,
>>> Sean
>>>
>>>
--
You received this message because you are subscribed to the Google Groups
"Netty discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/netty/9e16ca7a-7452-4f7b-bd04-b0dd04458b36%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
