Ok, so this is from the 2.0 changes doc...
In 1.x, ExecutorFilter maintained the order of events whatever
Executor you specified....
That's weird, what's the point of even having a thread model if
everything is serialized?
Is there a way to no maintain order in 1.x? I'd hate to move to 2.0
at this point, as we're trying to resolve this issue in the next few
days.
Ilya
On Sat, Sep 27, 2008 at 12:26 AM, Ilya Sterin <[EMAIL PROTECTED]> wrote:
> Maarten, seems like all is executing in the same thread. I printed
> out thread ids. The executor is configured to 20 threads and I pushed
> a very high load, which generated thousands of messageReceived events,
> all with same thread id. I'm using IoHandlerChain, but that should
> matter. I know the chain executes in a serial fashion, but it seems
> like the
>
> config.getFilterChain().addLast("executor", new
> ExecutorFilter(Executors.newFixedThreadPool(20)));
>
> is being ignored?
>
> Any ideas?
>
> Ilya
>
> On Thu, Sep 25, 2008 at 1:01 PM, Maarten Bosteels
> <[EMAIL PROTECTED]> wrote:
>> On Wed, Sep 24, 2008 at 4:41 AM, Ilya Sterin <[EMAIL PROTECTED]> wrote:
>>> I'm using mina 1.1.6 to connect to a TCP server. Everything is
>>> working, encoder/decoder and the IoHandler. I'm having an issue
>>> understanding the thread model. I'm having some thoughts as to
>>> whether threads are actually being spun off when IoHandler is invoked.
>>> The actions we're performing are rather lite, so I used a profiler to
>>> capture a few snapshots. Each one revealed only one IoHandler thread
>>> being executed at a particular time.
>>>
>>> My configuration is as follows, I extracted only the relevant lines...
>>>
>>>
>>> ExecutorService executor = Executors.newFixedThreadPool(threadDefault);
>>> config.getFilterChain().addLast("to-operation", new
>>> ProtocolCodecFilter(codecFactory));
>>> config.getFilterChain().addLast("executor", new ExecutorFilter(executor));
>>>
>>> try {
>>> acceptor.bind(instance.getAddress(), new ChainedIoHandler(handler),
>>> config);
>>> }
>>> catch (IOException e) {
>>> e.printStackTrace();
>>> }
>>>
>>>
>>> The executor is added to the filter chain last, as per documentation
>>> on the mina site, but I was also having a hard time understanding the
>>> small snippet of documentation that explained the thread model usage,
>>> so I'm not positive that by pushing the executor service into the
>>> filter chain would make it execute each IoHandler in its own thread.
>>
>>
>> I am using MINA 2.0 for quite some time so maybe my memories about
>> MINA 1.x are not completely accurate.
>>
>> There's only one IoHandler, so I am not sure what you mean with
>> "execute each IoHandler in its own thread." ?
>> You probably mean each invocation of IoHandler.messageReceived ?
>>
>> Keep in mind that MINA tries to avoid the threads-per-connection
>> paradigm. Instead all network events are put in a queue and processed
>> by an executor. When the load is low, it's possible that all events
>> are processed by the same thread, even when the executor has more
>> threads available.
>>
>> If you want to ensure that the executor uses multiple threads: print
>> out the name of the current thread inside your messageReceived
>> implementation AND generate a high load on your application.
>>
>> regards,
>> Maarten
>>
>>
>>>
>>> Thanks.
>>>
>>
>
