On Sat, Sep 27, 2008 at 6: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?
How many sessions did you create in your load-test ?
> From the looks of it, the orderedthreadpool is basically parallelizing
> the processing, so it probably not much different then having a thread
> pool with one thread. The only overhead might be the fact that tasks
> can be submitted simultaneously and the get/put thread pool cycle is
> parallel, though the processing is not.
OrderedThreadPool is about serializing the events PER SESSION.
This means that the order of the messageReceived events _per session_
is guaranteed to be preserved.
But events from multiple sessions are not serialized.
M.
>
> 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.
>>>
>>
>
