Mqtt5 client (JAVA) not receiving messages when not connected even using cleanStart false

HiveMQ Client Library
1

Hi. I need some help. I am using the Java Class client in order to build a subscriber client that must receive QOS 1 and QOS 2 messages send from a publisher.
The client connects with an async connection, with .cleanStart(false).
The connAck states .isSessionPresent() as true.
Subscription is made with .qos(MqttQos.EXACTLY_ONCE).

But either after ABORTING the client, or CLOSING the connection, whatever message is published with QOS 1 or 2 is lost and not received when connecting the subscriber client again.

I have been messing around with bigger or smaller sessionExpireInterval and keepAlive parameters with no progress.

I will appreciate any help on this subject.
Thanks in advance!

Best regards,
Freddy (from Uruguay)

type or paste code here
2

Hi Freddy from Uruguay!

A couple questions:

  1. Which MQTT broker, edition and version are you using?
  2. Could you confirm: Are you using the HiveMQ Java MQTT client 1.3.0?
  3. How are you CLOSING the connection? With a DISCONNECT?
  4. If the client is aborted/killed, do you reconnect with the same client ID?

For reference, there is also a list of session persistence best practices available here that might be useful.

Let me know - it could be a couple of things but likely something small.

Best,
Peter Giacomo Lombardo

3

Hi Peter!!!
Thanks for the prontp response, sorry for the delayed answer. I wasn’t available last week.

1.- Broker is mosquitto version: 2.0.11-1ubuntu1
2.- Client is 1.3.0
3.- I did with disconnect, and also just aborting the program
4.- Yes, always the same id

Thanks!

4

Excellent - welcome back. From the Java MQTT client side, I’m sure this functionality works as it’s a core feature - and we support this extensively when using the HiveMQ broker. So it may likely be an Mosquitto related issue - or at least it’s worth validating.

In the Mosquitto config, double check the max_queued_bytes and max_queued_messages settings.

It sounds like you’re doing everything correctly in the client code, so unfortunately the only option is to use the process of elimination.

With your Mosquitto setup, attempt to replace the Java client by using mosquitto_sub or mqtt-cli and see if the same issue exists. This should tell us a lot - where the problem likely exists - in client code or in broker.

Let me know if I explained this well enough and if you discover something.

Best,
Peter

5

Peter,
I did what you suggested and used the command line cli. With proper parameters, everything works fine.
So it’s a matter of propper programming.

Thanks for the help!

6

Ok great - Then if that’s the case, also make sure that you call subscribe before reconnecting. If not, the queued messages may be sent down before you have a handler setup to handle the incoming messages.

You could verify this by watching the MQTT traffic in tcpdump or Wireshark.

This solution was also covered in this issue and this issue.

That is another common cause of lost messages but… If neither of these solve the issue for you, share your client code and I’ll try to reproduce the problem here locally.

Best,
Peter

7

Peter, how should I subscribe before reconnect? Is that possible?
If I don´t have an active connection, how can I send the subscribe command?

Thanks!

8

Hello, @fkmass

When utilizing the Java client, you are able to submit a subscribe before a connect request. Peter has actually covered an implementation of this in the thread here.

This will prevent a case in which messages are being delivered to fulfill QoS 1/2 before the client has appropriately subscribed.

Let us know your thoughts, or if there are any further questions!

Best,
Aaron from HiveMQ Team