flag is an AtomicBoolean, it is designed for multi-threading. On Thu, Jul 27, 2017 at 4:22 PM, Christoph John <christoph.j...@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.j...@macd.com >> <mailto:christoph.j...@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.j...@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 >
