activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dale Green <green.dale1...@gmail.com>
Subject Re: Cannot make multiple embedded MQTT brokers use different SSLContext
Date Wed, 15 Feb 2017 10:51:29 GMT
Hi,
thanks for the hint. I tried it and it didn't work.

There is:

private static final ThreadLocal<SslContext> current

in SslContext. (BTW, during my previous tests, I was setting this to null
after starting each broker to avoid this "caching".)

However, in MQTTNIOSSLTransportFactory, there is

context = SslContext.getCurrentSslContext().getSSLContext();

and context is an object field. Hence, the second broker's context is
assigned here even when the brokers are in different threads.

My current workaround it to start the second broker in a new process.


On Tue, Feb 14, 2017 at 2:14 PM, Christopher Shannon <
christopher.l.shannon@gmail.com> wrote:

> Can you try creating each broker in a different thread in your tests?  The
> issue I think is that in the SslContext class the ThreadLocal variable is
> static so it is going to be shared and interfere when you try to configure
> 2 brokers in the same JVM and the same thread is creating transports.  This
> may not work either and there might need to be some additional work here
> done to fix this.
>
> On Fri, Feb 10, 2017 at 10:07 AM, Dale Green <green.dale1924@gmail.com>
> wrote:
>
> > Hi all,
> > I don't know if this is a bug or there is a specific reason to be
> > implemented in that way. So:
> >
> > Goal:
> >
> > Start 2 embedded MQTT brokers for integration tests purposes. Both
> brokers
> > have different SSLContexts with different keystores with different
> > certificates.
> >
> > Expected Result:
> >
> > Both brokers use different certificates.
> >
> > Actual Result:
> >
> > Both brokers use the same certificate, because both use the SSLContext of
> > the second broker (the most recently set up and started broker).
> >
> > Version: 5.14.3
> >
> > The actual problem (not sure if this is the only one):
> >
> > The anonymous class created in
> > MQTTNIOSSLTransportFactory::createTcpTransportServer(...) uses
> > MQTTNIOSSLTransportFactory::context, which is incorrect IMO. The right
> > context is NIOSSLTransportServer::context, but it is never used, because
> > it
> > is private.
> >
> > Any workarounds for this?
> >
> > Thanks!
> >
>

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