But if I access IoSession.getAttribute() and setAttribute() from different threads: can't it happen
that one thread does not "see" if I put an attribute into the IoSession? Regardless whether I put an
AtomicBoolean there or a Stringor other...
Oram I missing something?
Chris.
On 27/07/17 17:18, Mondain wrote:
Chris,
Take a look at the compareAndSet and getAndSet methods of AtomicBoolean; they use "compare and
swap" or CAS and you should never run into a situation where a value is mishandled due to the
nature of CAS using a single CPU operation.
Paul
On Thu, Jul 27, 2017 at 8:13 AM Christoph John <[email protected]
<mailto:[email protected]>> wrote:
On 27/07/17 10:56, Emmanuel Lécharny wrote:
> Le 27/07/2017 à 10:25, Christoph John a écrit :
>> One question that comes to my mind after looking at our code: there is
>> a Boolean attribute get/set on the IoSession in various places
>> (SessionConnector.QFJ_RESET_IO_CONNECTOR). We get/set this from
>> different locations and threads. But we neither synchronize on the
>> IoSession nor the get/set of the attribute. So IMHO it could happen
>> that the attribute is set to a different value than actually expected,
>> triggering unexpected behaviour.
>> I only searched briefly but could not find anything in the MINA code
>> that makes getting/setting the attribute thread-safe.
> Attributes within a session are not protected : it's up to you to make
> sure they are not modified concurently. Now, for a boolean, using an
> AtomicBoolean would certainly help.
OK, but to make sure that every thread works with the same value of the
attribute I need to
synchronize the get/set, correct? Even if I put an AtomicBoolean there, it
could happen that one
thread does not "see" it immediately.
But that only as a side note. I have tested it even with synchronization
and the behaviour
stays the
same. So the error must be somewhere else in the code.
I have now a test which tries to connect several FIX sessions with enabled
SSL filter. The
connection is established and then dropped because of an
SSLHandshakeException. This is done for
about a minute and leads to the mentioned problem with the connectors
hanging in dispose.
When I change the test to not use SSL I can see no "old" connectors hanging
around. Is there
something that I must specifically do when using the SSL filter? E.g. when
there is an exception
caught? First destroy all filters in the chain and then close the session?
Thanks,
Chris.
--
Christoph John
Development & Support
Direct: +49 241 557080-28
Mailto:[email protected]
http://www.macd.com <http://www.macd.com/>
----------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------
MACD GmbH
Oppenhoffallee 103
D-52066 Aachen
Tel: +49 241 557080-0 | Fax: +49 241 557080-10
Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663
Geschäftsführer: George Macdonald
----------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------
take care of the environment - print only if necessary
