Hi,
thanks for the hint. I tried it and it didn't work.
There is:
private static final ThreadLocal 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 = S
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
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
