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:22:15 GMT
Yeap, that's a very common technique:

if (flag.compareAndSet(false, true)) {
  try {
    doSomeThing();
  } finally {
    // I won the CAS, it is my responsibility to set it back to false.
    flag.set(false);
  }
}

On Thu, Jul 27, 2017 at 4:18 PM, Mondain <mondain@gmail.com> 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>
> 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 <+49%20241%2055708028>
> > 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 <+49%20241%2055708010>
> >          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