Yes, but the call to write() can originate from any thread and thus is not thread safe. All handlers in the write call get called unsynchronized. This also causes issues at other locations like the gzip filter.
There are two options, synchronize write calls yourself by surrounding calls to write() with a mutex lock or semaphore. Or, if you cannot synchronize all write calls (e.g. when you use the Heartbeat filter, which calls write on its own) you need to use the ExecutorFilter (I think that was the name). This can be used to force read and write calls to a specific thread. Jens On Aug 16, 2014 8:18 PM, Emmanuel Lecharny <[email protected]> wrote: > > From the top of my head (I'm in a bus atm), each session has its own chain > of filter, thus its own instance. The variable is not shared, and the > session is always handled by the same IoPricessor, so the same thread. That > should be thread safe unless you start doing weird things with an executor. > Le 16 août 2014 18:06, "Kai ZHANG" <[email protected]> a écrit : > > > Hi, > > > > I am a beginer of Mina. I read the api doc located at: > > > > /http://mina.apache.org/mina-project/apidocs/org/apache/ > > mina/core/session/IoSession.html/ > > > > It says that IoSession is thread-safe. > > > > But when I read the source of mina trunk branch. I found the > > IoSession.write() method may be not thread-safe. The java source file is : > > > > /./core/src/main/java/org/apache/mina/session/AbstractIoSession.java/ > > > > Here is the method calling chain: > > AbstractIoSession.write() > > -> AbstractIoSession.doWriteWithFuture > > -> AbstractIoSession.processMessageWriting() > > -> AbstractIoFilter.messageWriting() > > -> AbstractIoSession.callWriteNextFilter() > > > > The code which is thread-safe reside in > > AbstractIoSession.callWriteNextFilter(), > > here is the code: > > > > /** > > * process session message received event using the filter > > chain. To be called by the session {@link SelectorLoop} . > > * > > * @param message the received message > > */ > > @Override > > public void callWriteNextFilter(WriteRequest message) { > > if (IS_DEBUG) { > > LOG.debug("calling next filter for writing for message > > '{}' position : {}", message, writeChainPosition); > > } > > > > /writeChainPosition--;/ > > > > if (writeChainPosition < 0 || chain.length == 0) { > > // end of chain processing > > enqueueWriteRequest(message); > > } else { > > chain[writeChainPosition].messageWriting(this, message, > > this); > > } > > > > /writeChainPosition++;/ > > } > > > > Here the variable "writeChainPosition" is not thread-safe, If more than > > one thread call IoSession.write() concurrently, the "writeChainPosition" > > may have race condition. > > > > The result is some of the IoFilter may be skipped or called twice, and the > > message data passed down the filter chain may be broken. > > > > Could you tell me if my understanding is correct? > > > > Is IoSession.write() method designed to be thread-safe or should I use a > > lock for every concurrent IoSession.write() operation? > > > > > > > > > >
