It may be a flaw in the redesign. The trunk is an entire redesign of Mina.
On Aug 16, 2014 4:04 PM, "Kai ZHANG" <[email protected]> wrote:

> If the write() should be synchronized by myself, why the API documentation
> says this class is thread safe?
>
> I added my application details and the explanations in another email.
> Please tell me what is the correct usage of IoSession.write(). Whether the
> new implementation is a bug or new design.
>
> Thanks.
>
> On 08/17/2014 02:45 AM, Jens Reimann wrote:
>
>> 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?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>

Reply via email to