client with clean:false does not resubscribe

[nsriram]

We notice that the client is not resubscribing when {clean: false} option. The code in resubscribe block of index.js as well does this.
Would it be possible to resubscribe when the client has clean:false options set for receiving QOS:1 messages ?
Thanks

[mcollina]

The broker should automatically subscribe you.

[nsriram]

Thanks Matteo. We are using mqttjs with rhel-amq (wrapped on apache amq).
When the amq is restarted, we see the subscriber hanging.

Any inputs on this will be appreciated.

Steps.

1. Start Rhel AMQ
2. Start producer
3. Start Consumer
4. Watch for messages being printed
5. Stop AMQ
6. Start AMQ
7. Subscriber prints ('i have subscribed'), but the messages are not being received.
   Note : At this point if the subscriber is killed and restarted, it gets all the messages.

Subscriber
##########

const mqtt = require('mqtt');

let brokerUrl = 'mqtt://localhost:1883';
const client = mqtt.connect(brokerUrl, {
  clean: false,
  clientId: 'solo-consumer',
});


client.on('connect', function () {
  console.log('i am going to subscribing');
  client.subscribe('HelloTopic', { qos: 1 }, () => {
    console.log('i have subscribed')
  });
});

client.on('message', (topic, message) => {
  console.log(message.toString() + '\n');
});

Producer
########

const mqtt = require('mqtt');

let brokerUrl = 'mqtt://localhost:1883';
const client = mqtt.connect(brokerUrl, {
  clean: false,
  clientId: 'solo-producer',
});

let msgCount = 0;

client.on('connect', function () {
  setInterval(function () {
    const payload = 'Message : ' + (msgCount++);
    client.publish('HelloTopic', payload, () => {
      console.log(payload);
    });
  }, 3000);
});

Thanks,

[mcollina]

When the amq is restarted, we see the subscriber hanging.

Is the client emitting an 'offline', 'connect' or 'reconnect' events?

Have you checked if the same code work with Mosquitto? I fear it might be a problem with Rhel AMQ configuration, and you should check with them.

[nsriram]

Hi Matteo,
Thanks for the response.

The same problem occurs on Mosquitto as well. Have tested it.

Is the client emitting an 'offline', 'connect' or 'reconnect' events?

• We are using a node client with mqttjs. No special events are emitted. Can you point to any reference ?

Steps to recreate

1. Start Mosquitto (or) Rhel AMQ 7 broker (mqtt protocol).
2. Create a producer mqttjs client with {clean : false} in options & post messages with {qos : 1}.
3. Create a consumer mqttjs client with {clean : false} in options & subscribe messages with {qos : 1}.
4. Once subscriber starts receiving messages, shutdown the broker and start again (restart)
5. The client connection hangs -

NOTE : The connect & subscribe block do execute, but the 'on message' does not receive any. The client is expected to be restarted.

(More Finding) : A forced 'unsubscribe' inside the 'connect' callback and 'subscribe' after it, works as expected on broker restarts.

• But in large applications, we cannot do this as there will many topics to unsubscribe and subscribe again.

Thanks

[mcollina]

Is persistent storage configured in both brokers?

[nsriram]

Yes. Persistence is enabled on both.
(I even tested the mosquitto broker with 'max_queued_messages 0' config, by shutting down and restarting the consumer (having the broker all the time running), to ensure all the messages published during the down time are delivered).

[mcollina]

Can you please share the Mosquitto configuration that you are using?

[eharrow]

For the record I am experiencing the same issue. We use AMQ as well (5.14.5) and had not noticed the issue in test and dev as we use docker compose and made our mqtt client services dependent on AMQ which when it was restarted they were as well (I think).

In our case we have perhaps 500+ topics and subscribe on the consuming side using wildcards so resub is not onerous. I have added the work around described above and indeed it solves the problem but to be honest I am not convinced that the issue is that deterministic as reproducing the issue was not always guaranteed.

[ChristiaanWillemsen]

I think we have the same problem, but broker is EMQ. For some reason, it looks like the client stops working after a reconnect in some cases. We also use the {clean: false} configuration. we're using 2.7.1 at the moment.

[yanxiaochong]

I have the same problem, broker is EMQ. mqttjs(4.2.1) client with{clean: false} {qos:2} . How can I solve it？thanks.

[yanxiaochong]

I have the same problem, broker is EMQ. mqttjs(4.2.1) client with{clean: false} {qos:2} . How can I solve it？thanks.

protocolVersion: 5 solve it. thks