Closed sirockin closed 2 years ago
What you describe should work (there is a test to confirm this). Please share your code.
Hi @MattBrittan. I can see that test checks for publishing of buffered messages when connecting to a new broker but perhaps there is some unexpected difference when connecting reconnecting to the same broker.
My own code is embedded in some of our integration tests but I'll try to reproduce the example in a similar format to your own.
Unfortunately the structure of the library made testing this difficult and the approach currently used was the best I could come up with.
unexpected difference when connecting reconnecting to the same broker.
Anything is possible and I may be misunderstanding your issue; a test would be ideal (as we can add it to the library) but being able to duplicate the issue with Docker (example) would also be fine.
Here is a new test which demonstrates the issue. It:
I agree writing reliable tests for MQTT can be difficult and starting/stopping docker containers isn't optimal. Another approach I have used is using an embedded broker like github.com/mochi-co/mqtt/server
, which has the added advantage of letting you intercept published messages without creating a separate subscriber.
Thank you once again for your quick and helpful responses.
Hi @MattBrittan were you able to reproduce my issue OK with the test I provided? Please let me know if you need any further information.
Cheers!
Dave
Hi @sirockin - I'm travelling for the next couple of weeks so may be slow to respond (and not often in a position to run test code).
CleanSession
defaults to true
and when in that state the session (including anything stored on the client) is cleared when the connection is established (as required by the MQTT spec). Fix this and your test passes i.e.:
pops := NewClientOptions().AddBroker(tempLocalBroker).SetClientID("crp-pub").SetCleanSession(false).
SetStore(memStore).SetConnectRetry(true).SetConnectRetryInterval(time.Second / 2)
Thanks for clarifying, I'll try that. Safe travels!
When I set
AutoReconnect
totrue
, the client will attempt to reconnect to the broker after its connection is lost, then once successful, resend any messages I published of QoS > 1.Setting
ConnectRetry
totrue
will (as expected) ensure that after a first attempt to connect has failed, the client continues to attempt connecting until successful but in this case, does not seem to send any messages I have already published.Is this by design or have I could I be doing something wrong?
Thanks in advance!