mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guido Medina <oxyg...@gmail.com>
Subject Re: leaking NioProcessors/NioSocketConnectors hanging in call to dispose
Date Thu, 27 Jul 2017 15:23:15 GMT
flag is an AtomicBoolean, it is designed for multi-threading.

On Thu, Jul 27, 2017 at 4:22 PM, Christoph John <christoph.john@macd.com>
wrote:

> 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 <christoph.john@macd.com
>> <mailto:christoph.john@macd.com>> 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:Christoph.John@macd.com
>
>
>
> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message