eclipse / paho.mqtt.golang

Other
2.71k stars 531 forks source link

Not receiving messages on subscribed topics after AutoReconnect (1.2.0 + master) #401

Closed andig closed 4 years ago

andig commented 4 years ago

I've just noticed my app not reconnecting:

[mqtt] INFO 2020/02/09 15:29:52 connecting evcc-59786 at nas.fritz.box:1883
[mqtt] WARN 2020/02/09 18:16:23 nas.fritz.box:1883 connection lost: read tcp 192.168.0.68:56908->192.168.0.41:1883: read: connection reset by peer
[load] ERRO 2020/02/09 18:16:29 wallbe mbmd/sdm1-1/Power outdated value (16.400143546s)
[load] ERRO 2020/02/09 18:16:34 wallbe mbmd/sdm1-1/Power outdated value (21.398153162s)
[load] ERRO 2020/02/09 18:16:34 wallbe mbmd/sdm1-2/Power outdated value (17.917025402s)
[load] ERRO 2020/02/09 18:16:39 wallbe mbmd/sdm1-1/Power outdated value (26.502932507s)
[load] ERRO 2020/02/09 18:16:39 wallbe mbmd/sdm1-2/Power outdated value (23.023298295s)
[load] ERRO 2020/02/09 18:16:44 wallbe mbmd/sdm1-1/Power outdated value (31.40471671s)
[load] ERRO 2020/02/09 18:16:44 wallbe mbmd/sdm1-2/Power outdated value (27.923574945s)
[load] ERRO 2020/02/09 18:16:49 wallbe mbmd/sdm1-1/Power outdated value (36.405994482s)
[load] ERRO 2020/02/09 18:16:49 wallbe mbmd/sdm1-2/Power outdated value (32.925512192s)
[load] ERRO 2020/02/09 18:16:54 wallbe mbmd/sdm1-1/Power outdated value (41.399232802s)
[load] ERRO 2020/02/09 18:16:54 wallbe mbmd/sdm1-2/Power outdated value (37.918074025s)

This should not happen as reconnect is enabled:

options := mqtt.NewClientOptions()
options.AddBroker(broker)
options.SetUsername(user)
options.SetPassword(password)
options.SetClientID(clientID)
options.SetCleanSession(cleanSession)
options.SetAutoReconnect(true) // <--
options.SetOnConnectHandler(mc.ConnectionHandler)
options.SetConnectionLostHandler(mc.ConnectionLostHandler)

client := mqtt.NewClient(options)
if token := client.Connect(); token.Wait() && token.Error() != nil {
    log.FATAL.Printf("error connecting: %s", token.Error())
    os.Exit(1)
}

At the same time the broker (single instance) is alive:

❯ mosquitto_sub -h nas.fritz.box -t mbmd/sdm1-2/Power -t mbmd/sdm1-1/Power -v
mbmd/sdm1-1/Power 2409.664
mbmd/sdm1-1/Power 2394.393
mbmd/sdm1-1/Power 401.683

I think I can provoke the situation- any hint where I should start digging?

andig commented 4 years ago

I have meanwhile retried with current master and added logging using SetReconnectingHandler. However, although paho claims reconnect + connected, it still doesn't receive messages. Again, mosquitto_sub confirms that broker and messages are alive:

[mqtt] WARN 2020/02/09 21:39:04 nas.fritz.box:1883 connection lost: read tcp 192.168.0.68:58243->192.168.0.41:1883: read: connection reset by peer
[mqtt] INFO 2020/02/09 21:39:04 nas.fritz.box:1883 reconnect
[mqtt] TRCE 2020/02/09 21:39:04 nas.fritz.box:1883 connected
[load] ERRO 2020/02/09 21:39:07 wallbe mbmd/sdm1-1/Power outdated value (18.068934605s)
[load] ERRO 2020/02/09 21:39:07 wallbe mbmd/sdm1-2/Power outdated value (23.087347905s)
[load] ERRO 2020/02/09 21:39:12 wallbe mbmd/sdm1-1/Power outdated value (22.970764021s)
[load] ERRO 2020/02/09 21:39:12 wallbe mbmd/sdm1-2/Power outdated value (27.989132794s)
[load] ERRO 2020/02/09 21:39:17 wallbe mbmd/sdm1-2/Power outdated value (33.062924677s)
[load] ERRO 2020/02/09 21:39:17 wallbe mbmd/sdm1-1/Power outdated value (28.044708598s)
[load] ERRO 2020/02/09 21:39:22 wallbe mbmd/sdm1-1/Power outdated value (33.016289843s)
[load] ERRO 2020/02/09 21:39:22 wallbe mbmd/sdm1-2/Power outdated value (38.034874944s)
[load] ERRO 2020/02/09 21:39:27 wallbe mbmd/sdm1-2/Power outdated value (42.987328872s)
[load] ERRO 2020/02/09 21:39:27 wallbe mbmd/sdm1-1/Power outdated value (37.969089835s)
[load] ERRO 2020/02/09 21:39:32 wallbe mbmd/sdm1-1/Power outdated value (43.143321601s)
[load] ERRO 2020/02/09 21:39:32 wallbe mbmd/sdm1-2/Power outdated value (48.161719369s)
[load] ERRO 2020/02/09 21:39:37 wallbe mbmd/sdm1-1/Power outdated value (47.9709277s)
[load] ERRO 2020/02/09 21:39:37 wallbe mbmd/sdm1-2/Power outdated value (52.989483786s)
[load] ERRO 2020/02/09 21:39:42 wallbe mbmd/sdm1-1/Power outdated value (52.964056618s)
[load] ERRO 2020/02/09 21:39:42 wallbe mbmd/sdm1-2/Power outdated value (57.982432283s)
[load] ERRO 2020/02/09 21:39:47 wallbe mbmd/sdm1-1/Power outdated value (57.974194317s)
[load] ERRO 2020/02/09 21:39:47 wallbe mbmd/sdm1-2/Power outdated value (1m2.99258528s)
[load] ERRO 2020/02/09 21:39:52 wallbe mbmd/sdm1-1/Power outdated value (1m2.979370931s)
[load] ERRO 2020/02/09 21:39:52 wallbe mbmd/sdm1-2/Power outdated value (1m7.997736967s)

outdated in terms of log means that no news message was received.

MattBrittan commented 4 years ago

Hi @andig,

I rely upon the autoreconnect functionality and it does work for me over some very unreliable links. However a number of deadlocks have been found/fixed in the past and I would not be surprised if there are other issues.

Can you please confirm that cleanSession = false or you resubscribe in SetOnConnectHandler? (otherwise it would be expected that no more messages will be sent by the broker). It would also be useful to see a chunk of the mosquitto logs around the disconnect/reconnect.

Tha other piece of information that would be useful is the debug logs from the package (you include some messages but I suspect you are printing these yourself?); enable logging using something like the following:

mqtt.ERROR = log.New(os.Stdout, "[ERROR] ", 0)
mqtt.CRITICAL= log.New(os.Stdout, "[CRIT] ", 0)
mqtt.WARN = log.New(os.Stdout, "[WARN]  ", 0)
mqtt.DEBUG = log.New(os.Stdout, "[DEBUG] ", 0)

Matt

andig commented 4 years ago

Hi @MattBrittan,

Thanks for educating me on the proper use of cleanSession and the mqtt logging options. I had it set cleanSession to true and wasn't aware on the implications for subscribed topics.

Closing as works as designed, much appreciated!

andig commented 4 years ago

I need to reopen this unfortunately. I hope I have the client config right now, reconnecting with clean session false:

options := mqtt.NewClientOptions()
options.AddBroker(broker)
options.SetUsername(user)
options.SetPassword(password)
options.SetClientID(clientID)
options.SetCleanSession(false)
options.SetAutoReconnect(true)
options.SetOnConnectHandler(mc.ConnectionHandler)
options.SetConnectionLostHandler(mc.ConnectionLostHandler)

My mosquitto server is dockerized, upon restarting the container the subscriptions are no longer received:

❯ gor main.go -c evcc.wallbe.yaml -l debug
[mqtt] INFO 2020/02/15 12:49:55 connecting evcc-38139 at nas.fritz.box:1883
[DEBUG] [client]   Connect()
[DEBUG] [store]    memorystore initialized
[DEBUG] [client]   about to write new connect msg
[DEBUG] [client]   socket connected to broker
[DEBUG] [client]   Using MQTT 3.1.1 protocol
[DEBUG] [net]      connect started
[DEBUG] [net]      received connack
[DEBUG] [client]   client is connected
[DEBUG] [pinger]   keepalive starting
[DEBUG] [client]   exit startClient
[DEBUG] [client]   enter Subscribe
[DEBUG] [net]      logic started
[DEBUG] [net]      logic waiting for msg on ibound
[DEBUG] [client]   SUBSCRIBE: dup: false qos: 1 retain: false rLength: 0 MessageID: 0 topics: [mbmd/sdm1-1/Power]
[DEBUG] [net]      incoming started
[DEBUG] [client]   exit Subscribe
[DEBUG] [net]      outgoing started
[DEBUG] [net]      outgoing waiting for an outbound message
[DEBUG] [net]      obound priority msg to write, type *packets.SubscribePacket
[DEBUG] [net]      outgoing waiting for an outbound message
[DEBUG] [net]      Received Message
[DEBUG] [net]      logic got msg on ibound
[WARN]  [store]    memorystore del: message 1 not found
[DEBUG] [net]      received suback, id: 1
[DEBUG] [net]      granted qoss [1]
[DEBUG] [net]      logic waiting for msg on ibound

-> subscribe

[DEBUG] [client]   enter Subscribe
[DEBUG] [client]   SUBSCRIBE: dup: false qos: 1 retain: false rLength: 0 MessageID: 0 topics: [mbmd/sdm1-2/Power]
[DEBUG] [client]   exit Subscribe
[DEBUG] [net]      obound priority msg to write, type *packets.SubscribePacket
[DEBUG] [net]      outgoing waiting for an outbound message
[DEBUG] [net]      Received Message
[DEBUG] [net]      logic got msg on ibound
[WARN]  [store]    memorystore del: message 1 not found
[DEBUG] [net]      received suback, id: 1
[DEBUG] [net]      granted qoss [1]
[DEBUG] [net]      logic waiting for msg on ibound
[DEBUG] [net]      Received Message
[DEBUG] [net]      logic got msg on ibound
[DEBUG] [net]      received publish, msgId: 0
[DEBUG] [net]      putting msg on onPubChan
[DEBUG] [net]      done putting msg on incomingPubChan
[DEBUG] [net]      logic waiting for msg on ibound
[DEBUG] [net]      Received Message
[DEBUG] [net]      logic got msg on ibound
[DEBUG] [net]      received publish, msgId: 0
[DEBUG] [net]      putting msg on onPubChan
[DEBUG] [net]      done putting msg on incomingPubChan
[DEBUG] [net]      logic waiting for msg on ibound
[DEBUG] [pinger]   ping check 5.00120789
[DEBUG] [net]      Received Message
[DEBUG] [net]      logic got msg on ibound
[DEBUG] [net]      received publish, msgId: 0
[DEBUG] [net]      putting msg on onPubChan
[DEBUG] [net]      done putting msg on incomingPubChan
[DEBUG] [net]      logic waiting for msg on ibound

-> restart container

[DEBUG] [pinger]   ping check 9.997213474
[ERROR] [net]      incoming stopped with error EOF
[ERROR] [net]      error triggered, stopping
[DEBUG] [pinger]   keepalive stopped
[DEBUG] [net]      outgoing stopped
[WARN]  [net]      logic stopped
[mqtt] WARN 2020/02/15 12:50:09 nas.fritz.box:1883 connection lost: EOF
[DEBUG] [client]   enter reconnect
[DEBUG] [client]   about to write new connect msg
[DEBUG] [client]   socket connected to broker
[DEBUG] [client]   Using MQTT 3.1.1 protocol
[DEBUG] [net]      connect started
[ERROR] [net]      connect got error EOF
[ERROR] [client]   Connecting to tcp://nas.fritz.box:1883 CONNACK was not Accepted, but rather Connection Error
[DEBUG] [client]   Reconnect failed, sleeping for 1 seconds
[DEBUG] [client]   about to write new connect msg

-> reconnect

[DEBUG] [client]   socket connected to broker
[DEBUG] [client]   Using MQTT 3.1.1 protocol
[DEBUG] [net]      connect started
[DEBUG] [net]      received connack
[DEBUG] [client]   client is reconnected
[DEBUG] [net]      incoming started
[DEBUG] [net]      logic started
[DEBUG] [net]      logic waiting for msg on ibound
[DEBUG] [pinger]   keepalive starting
[DEBUG] [net]      outgoing started
[DEBUG] [net]      outgoing waiting for an outbound message
[DEBUG] [pinger]   ping check 5.005701821
[load] ERRO 2020/02/15 12:50:17 wallbe mbmd/sdm1-1/Power outdated value (17.493025686s)
[DEBUG] [pinger]   ping check 10.005753548

-> ping ok but no inbound message received

[load] ERRO 2020/02/15 12:50:22 wallbe mbmd/sdm1-1/Power outdated value (22.493812462s)
[load] ERRO 2020/02/15 12:50:22 wallbe mbmd/sdm1-2/Power outdated value (19.012775176s)
[DEBUG] [pinger]   ping check 15.000325228
[load] ERRO 2020/02/15 12:50:27 wallbe mbmd/sdm1-2/Power outdated value (24.009564937s)
[load] ERRO 2020/02/15 12:50:27 wallbe mbmd/sdm1-1/Power outdated value (27.490995904s)
[DEBUG] [pinger]   ping check 20.005760065
[load] ERRO 2020/02/15 12:50:32 wallbe mbmd/sdm1-1/Power outdated value (32.500077398s)
[load] ERRO 2020/02/15 12:50:32 wallbe mbmd/sdm1-2/Power outdated value (29.01905041s)

Here's the matching mosquitto log:

1581767786: mosquitto version 1.6.8 terminating
1581767787: mosquitto version 1.6.8 starting
1581767787: Config loaded from /mosquitto/config/mosquitto.conf.
1581767787: Opening ipv4 listen socket on port 1883.
1581767787: Opening ipv6 listen socket on port 1883.
1581767787: New connection from 172.19.0.1 on port 1883.
1581767787: New client connected from 172.19.0.1 as mbmd (p2, c0, k30).
1581767787: New connection from 172.19.0.1 on port 1883.
1581767787: New client connected from 172.19.0.1 as evcc-38139 (p2, c0, k30).
1581767801: New connection from 172.19.0.1 on port 1883.
1581767801: New client connected from 172.19.0.1 as mqtt_2b41a55.64f755a (p1, c1, k60).
1581767805: New connection from 172.19.0.1 on port 1883.
1581767805: New client connected from 172.19.0.1 as ebusd_3.4_1 (p1, c1, k60).
andig commented 4 years ago

@MattBrittan the tests above are using 1.2.0 and master both, same behaviour. I'd be happy to debug what's going on but would need some pointers where to start digging.

MattBrittan commented 4 years ago

Thanks @andig,

I suspect that the issue will be on the mosquitto side (rather than within the golang client) because the reconnect appears to be successful and, that being the case, mosquitto should be sending through the queued messages (there is nothing in the logs to indicate anything else). You can verify this by increasing the logging level in mosquitto (log_type all).

A few points to note:

Note: If the above test (with mosquitto_sub etc) does not work then it would probably be best moving this discussion elsewhere (e.g. stackoverflow) because the issue will not be related to this client.

Matt

andig commented 4 years ago

I may not fully understand, but lets see. If mosquitto issue happy to move away:

❯ mosquitto_sub -c --id evcc-38139 -t mbmd/sdm1-1/Power -q 2

all quiet as expected, then restarting broker, then mosquitto_pub -t mbmd/sdm1-1/Power -m test123 -q 2 in new window: Now the subscribe above shows output:

test123

I don't fully get what the last mosquitto_sub -c --id evcc-38139 -t nothing -q 2 is for, sorry?

Note: If the above test (with mosquitto_sub etc) does not work then it would probably be best moving this discussion elsewhere

It seems the test is successful as message received even after reconnect?

As for persistence, maybe I have the wrong expectations. I'm not worried about receiving any messages on reconnect (persisted or otherwise). I'm only concerned with renewing the subscriptions. I.e. when- after reconnect- a client publishes, I'd expect to receive those without re-subscribing from application side.

I generally subscribe from within the OnConnectHandler

Makes perfect sense and I see this as workaround. Unfortunately at this time the app is structured in a way that does not make this possible easily.

I'd suggest that I come up with a very simple demo app to look at.

andig commented 4 years ago

Here we go:

package main

import (
    "log"
    "os"

    mqtt "github.com/eclipse/paho.mqtt.golang"
)

const (
    broker   = "nas.fritz.box:1883"
    clientID = "evcc-38139"
    topic    = "foo"
    qos      = 1
)

func main() {
    mqtt.ERROR = log.New(os.Stdout, "[ERROR] ", 0)
    mqtt.CRITICAL = log.New(os.Stdout, "[CRIT] ", 0)
    mqtt.WARN = log.New(os.Stdout, "[WARN]  ", 0)
    mqtt.DEBUG = log.New(os.Stdout, "[DEBUG] ", 0)

    options := mqtt.NewClientOptions()
    options.AddBroker(broker)
    options.SetClientID(clientID)
    options.SetCleanSession(false)
    options.SetAutoReconnect(true)

    client := mqtt.NewClient(options)
    if token := client.Connect(); token.Wait() && token.Error() != nil {
        log.Fatalf("error connecting: %v", token.Error())
    }

    token := client.Subscribe(topic, qos, func(c mqtt.Client, msg mqtt.Message) {
        s := string(msg.Payload())
        log.Println(s)
    })

    if token.Wait() && token.Error() != nil {
        log.Fatalf("error: %v", token.Error())
    }

    for {

    }
}

Receives fine before the broker restarts and no more afterwards:

[DEBUG] [client]   Connect()
[DEBUG] [store]    memorystore initialized
[DEBUG] [client]   about to write new connect msg
[DEBUG] [client]   socket connected to broker
[DEBUG] [client]   Using MQTT 3.1.1 protocol
[DEBUG] [net]      connect started
[DEBUG] [net]      received connack
[DEBUG] [client]   client is connected
[DEBUG] [client]   exit startClient
[DEBUG] [client]   enter Subscribe
[DEBUG] [pinger]   keepalive starting
[DEBUG] [client]   SUBSCRIBE: dup: false qos: 1 retain: false rLength: 0 MessageID: 0 topics: [foo]
[DEBUG] [client]   exit Subscribe
[DEBUG] [net]      outgoing started
[DEBUG] [net]      outgoing waiting for an outbound message
[DEBUG] [net]      incoming started
[DEBUG] [net]      logic started
[DEBUG] [net]      obound priority msg to write, type *packets.SubscribePacket
[DEBUG] [net]      logic waiting for msg on ibound
[DEBUG] [net]      outgoing waiting for an outbound message
[DEBUG] [net]      Received Message
[DEBUG] [net]      logic got msg on ibound
[WARN]  [store]    memorystore del: message 1 not found
[DEBUG] [net]      received suback, id: 1
[DEBUG] [net]      granted qoss [1]
[DEBUG] [net]      logic waiting for msg on ibound
[DEBUG] [net]      Received Message
[DEBUG] [net]      logic got msg on ibound
[DEBUG] [net]      received publish, msgId: 0
[DEBUG] [net]      putting msg on onPubChan
[DEBUG] [net]      done putting msg on incomingPubChan
[DEBUG] [net]      logic waiting for msg on ibound
2020/02/16 11:09:55 1

after restart no more messages:

[DEBUG] [pinger]   ping check 5.003953128
[DEBUG] [pinger]   ping check 10.004153273
[ERROR] [net]      incoming stopped with error EOF
[ERROR] [net]      error triggered, stopping
[DEBUG] [pinger]   keepalive stopped
[WARN]  [net]      logic stopped
[DEBUG] [net]      outgoing stopped
[DEBUG] Connection lost: EOF
[DEBUG] [client]   enter reconnect
[DEBUG] [client]   about to write new connect msg
[DEBUG] [client]   socket connected to broker
[DEBUG] [client]   Using MQTT 3.1.1 protocol
[DEBUG] [net]      connect started
[ERROR] [net]      connect got error read tcp 192.168.0.68:58715->192.168.0.41:1883: read: connection reset by peer
[ERROR] [client]   Connecting to tcp://nas.fritz.box:1883 CONNACK was not Accepted, but rather Connection Error
[DEBUG] [client]   Reconnect failed, sleeping for 1 seconds
[DEBUG] [client]   about to write new connect msg
[DEBUG] [client]   socket connected to broker
[DEBUG] [client]   Using MQTT 3.1.1 protocol
[DEBUG] [net]      connect started
[DEBUG] [net]      received connack
[DEBUG] [client]   client is reconnected
[DEBUG] [net]      incoming started
[DEBUG] [pinger]   keepalive starting
[DEBUG] [net]      logic started
[DEBUG] [net]      logic waiting for msg on ibound
[DEBUG] [net]      outgoing started
[DEBUG] [net]      outgoing waiting for an outbound message
[DEBUG] [pinger]   ping check 5.00460668
^Csignal: interrupt

So it might come down the the question of having the right expectations: should subscriptions be restored when client reconnects?

MattBrittan commented 4 years ago

Hi @andig ,

Thanks for your test code. Unfortunately when I run this on my system it works exactly as expected; that is after the reconnect the app continues to receive/print messages (my test code with docker setup and mosquitto config). To test this I:

  1. Started mosquitto docker container
  2. Started script (publish.ps1) that publishes a message every 5 seconds
  3. Started your application and verified it was receiving messages
  4. Restarted mosquitto container
  5. Verified that your application was still receiving messages

Unfortunately the logs from your test run do not show anything that would help address this; I'd need the mosquitto logs to confirm it is sending something (the client logs show no record of any messages being received).

As for persistence, maybe I have the wrong expectations.

I suspect that you may have missed the fact that the broker will only send messages on to clients that are subscribed to the topic. This means that the broker needs to retain a record of what client is subscribed to what topic; if the broker looses this information when restarted then no messages will be passed on until the client resubscribes. This means that to achieve the result you are looking for persistence must be enabled in the mosquitto config (you can use max_queued_messages to limit how many messages are stored per client).

Unfortunately the test you did with mosquitto_sub/mosquitto_pub does not establish anything because mosquitto_sub automatically resubscribes when the connection is lost/reconnected. This is the reason that I run it with a second topic (so it does not resubscribe to the one we are interested in; this mimics your application).

Here is a slightly extended (for ease of understanding) version of my test process; I feel that this is important because I'm fairly confident that this is an issue with your mosquitto setup rather than this package.

Firstly ensure mosquitto is running and start up two terminal sessions (lets call them "pub" and "sub").

In Sub terminal session

mosquitto_sub -c --id evcc-38139 -t foo -q 1

Let this start then exit (ctrl-c). The point of this is to establish a QOS 1 subscription to the topic "foo" for the client evcc-38139.

mosquitto_sub -c --id evcc-38139 -t bar -q 1

mosquitto_sub will not run without a topic so I am giving it one (bar in this case) but the actual topic is irrelevant (as long as its NOT foo). So the client evcc-38139 should now be subscribed to BOTH foo and bar (and mosquitto_sub will display messages received on either topic). Leave this running.

In Pub terminal session

mosquitto_pub -t foo -m test123 -q 1

This publishes a message on topic foo. Check that the message appears in the Sub console.

Now restart mosquitto.

In Sub terminal session

mosquitto_sub should survice the restart (it reconnects and automatically resubscribes to bar). If it did stop you can restart it:

mosquitto_sub -c --id evcc-38139 -t bar -q 1

Note that we are still using topic bar here so have not resubscribed to foo (the test is to see if the broker retained that subscription).

In Pub terminal session

mosquitto_pub -t foo -m test123 -q 1

This publishes another message on topic foo. Check that the message appears in the Sub console. I suspect nothing will appear in the Sub console; if that is the case then the issue is with your mosquitto setup (it is not retaining subscription info through the restart).

As mentioned in my previous comment if this all works then you might want to run mosquitto_sub --id evcc-38139 -t nothing -q 0 to clear out the subscriptions made during the above process (otherwise a correctly configured mosquitto will retain the subscription info). This command does not have the -c option meaning the cleansession flag will be set.

If the above does all work (indicating that there is a problem with this package) then please add the mosquitto logs showing the initial connection, the subscription being processed, messages arriving and the subsequent reconnection.

andig commented 4 years ago

Hello @MattBrittan,

If the above does all work...

It seems it doesn't- I should haven seen the test123 twice:

❯ mosquitto_sub -c --id evcc-38139 -t foo -q 1
^C
❯ mosquitto_sub -c --id evcc-38139 -t bar -q 1
test123

In separate terminal:

❯ mosquitto_pub -t foo -m test123 -q 1

Restart mosquitto server, then:

❯ mosquitto_pub -t foo -m test123 -q 1

The first pub is received, the second is not. I'll double-check the mosquitto config. To become independent from the server config I'll follow your suggestion of re-subscribing in the OnConnect handler.

Thanks a lot for taking the time to investigate and explain.

ilaotan commented 1 year ago

yes , re-subscribing in the OnConnect handler is ok