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.dale1...@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! >
