I was referring to the map in the IoSession not to the flag itself. :)
Am 27. Juli 2017 17:23:15 MESZ schrieb Guido Medina <oxyg...@gmail.com>: >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 >>
