I've found the behavior while developing additional service: the MQTT client paho can hang and even start reconnecting by internal ping-checker because of long processing or deadlock of MQTT handler, which had been passed to paho during Subscribe(). So it's completely blocked.
the "Common Problems" paho-list on github says:
A MessageHandler (called when a new message is received) must not block (unless ClientOptions.SetOrderMatters(false) set). If you wish to perform a long-running task, or publish a message, then please use a go routine (blocking in the handler is a common cause of unexpected pingresp not received, disconnecting errors).
So my suggestion is simply to run all the methods as goroutines here in NS and gw-bridge also. As the current scheme can reduce performance at least.
Hello Brocaar. How are things going?
I've found the behavior while developing additional service: the MQTT client paho can hang and even start reconnecting by internal ping-checker because of long processing or deadlock of MQTT handler, which had been passed to paho during Subscribe(). So it's completely blocked.
the "Common Problems" paho-list on github says:
So my suggestion is simply to run all the methods as goroutines here in NS and gw-bridge also. As the current scheme can reduce performance at least.