Open amitjoy opened 1 year ago
https://github.com/hivemq/hivemq-mqtt-client/blob/d709dc3aeea8a6837ecc21413988de154a66be1c/src/main/java/com/hivemq/client/internal/mqtt/handler/connect/MqttConnAckSingle.java#L93 This is where it should have been passed onto the callbacks.
Thanks for reaching out. In order to be able to do a deeper analysis, can you please share any kind of reproducer code with us?
At a first glance, it looks like the async programming might not be correct. You might not synchronize threads within your application. For example, this connect method has a blocking signature (e.g. no return future) but not blocking for the connect operation of the client.
So most likely this is where the issue happens. And there might be two options:
The connect
method is synchronous and it is expected. it simply executes the async client which doesn't block at all. This works as expected too. The async operation of the client registers callbacks internally and pass the information downstream. Calling join
might fix the issue but it would block which I wouldn't want.
I would like to share with you the background of it. I wanted to introduce a new callback to understand about a situation when the OSGi messaging adapter (the source code link you already have) encounters issues to connect to the broker due to issues like invalid password, broker unreachable, protocol error etc. That's why, I wanted to introduce a new API for other consumers to implement. For this, I wanted to handle the exceptional information which is passed to the CompletableFuture
callback and it never gets triggered even though the broker was unreachable.
That's why, I open this issue. FYI I found a better way to implement the aforementioned functionality by implementing MqttClientDisconnectedListener
and this gets triggered always with the proper information of why the client cannot connect to the broker or if something went wrong in between. This works like a charm though.
But, I still cannot get the exceptionally()
invoked when the exception occurs. Even though I don't need it now as it works perfectly because of the MqttClientDisconnectedListener
, I will still try to write a reproducer code soon to verify it.
Currently, the
Mqtt5AsyncClient
doesn't propagate the exceptions that might have been caused while connecting to the broker, for example, due to unreachable broker, wrong password etc.The RX Client callback
doOnError
or theCompletableFuture
callbackexceptionally(..)
is never executed in such scenarios.