Christopher Popp wrote:
Hello,
I have an application making use of Mina 2.0.0 M5.
I have an executor filter in my filter chain, after everything but the handler.
Based on everything I read and saw in the forums, I'm expecting that it would
make use of the OrderedThreadPoolExecutor. Am I correct that the benefit of
this filter with this thread pool is to provide additional threads for handling
concurrent sessions, but that for any given session, only one thread will be
active at a time?
I thought this was how it was supposed to behave, but I'm not seeing that. It
seems like multiple threads are getting into the handler methods for a given
session concurrently. I added some diagnostics to the messageReceived method
of my handler:
Map<IoSession, Integer> counter = new HashMap<IoSession, Integer>();
public void messageReceived(IoSession session, Object message) throws
Exception {
synchronized(counter){
if(!counter.containsKey(session)){
counter.put(session, 0);
}
counter.put(session, counter.get(session)+1);
System.out.println("There are " + counter.get(session) + " threads in
this method");
}
//...Application Logic
synchronized(counter){
counter.put(session, counter.get(session)-1);
System.out.println("Thread done... there are " + counter.get(session) +
" left");
}
}
Particularly when there is a lot of activity and messages I see this print out more than one, which leads me to believe that more than one thread is calling into my handler for a given thread, for the same session.
Any thoughts?
We fixed a bad bug I introduced in 2.0.0-M5 which broke the way the
OrderedThreadPoolExecutor was working. MINA 2.0.0-M6, currently being
voted, will solve this regression.
The binaries are available at http://people.apache.org/~ngn/mina/2.0.0-M6/
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
