the paho client appear no ack after receive message #441
Comments
|
Sorry - more focused information will be required to assist you with this. Could you please:
However the best way to get a resolution is to try and simplify your code so you can provide a minimal reproducable example. Often when creating such an example I find the issue within my own code (and if it is a bug in the paho client then having something I can use to duplicate it makes it much easer to solve). Assuming you are receiving messages and mean the PUBACK then this is only sent after a message handlers return (or never if there is no message handler) - see here. Most of the time this issue is raised that is the problem (i.e. your handler is not returning for whatever reason). There is also an outstanding pull request (#434) which could be related (but this is mainly focused on the issues whilst resuming). Note: If you are unable to more general help with this you might have better luck asking on one of the resources mentioned in the readme or on stackoverflow . There are only a few people who monitor issues here (and I have no experience with emqx). |
|
yes, I use the latest source from master. |
Note that it would also be worth logging your handlers (entry and exit). As mentioned this issue is often due to handlers that to not exit within the users code. |
|
hi, MattBrittan: following is my trace code: func StartService() error {
l := logger.Get()
l.Debug("start connect MQTT server ...")
c := MQTT.NewClient(opts)
c.AddRoute("/c2s/rpc/#", c2sRpcHandler)
c.AddRoute("/c2s/async_reply/#", c2sAsyncReplyHandler)
c.AddRoute("/c2s/async_stateless/#", c2sAsyncStatelessHandler)
c.AddRoute("/c2s/message/#", c2sMessageHandler)
c.AddRoute("/sc2s/rpc/#", c2sRpcHandler)
c.AddRoute("/sc2s/async_reply/#", c2sAsyncReplyHandler)
c.AddRoute("/sc2s/message/#", c2sMessageHandler)
c.AddRoute("$SYS/brokers/+/clients/#", brokerClientsHandler)
if config.Get().Common.Mode == "develop" {
MQTT.CRITICAL = log.New(os.Stdout, "", 0)
MQTT.DEBUG = log.New(os.Stdout, "", 0)
MQTT.WARN = log.New(os.Stdout, "", 0)
MQTT.ERROR = log.New(os.Stdout, "", 0)
}
if token := c.Connect(); token.Wait() && token.Error() != nil {
return token.Error()
}
//following check alive
go func() {
alive := time.Now().Unix()
c.Subscribe("test", 1, func(client MQTT.Client, msg MQTT.Message) {
alive = time.Now().Unix()
})
for _ = range time.NewTicker(5 * time.Second).C {
log := logger.Get()
log.Debug("will send test message ...")
if token := c.Publish("test", 1, false, ""); !token.WaitTimeout(3*time.Second) || token.Error() != nil {
log.Error("!!! the mqtt connection appear fault !!!")
if token.Error() != nil {
log.Error(token.Error().Error())
}
os.Exit(1)
}
if time.Now().Unix() > alive+10 {
log.Error("!!! It can't receive test message over 10 seconds !!!")
os.Exit(1)
}
}
}()
return nil
} |
|
2020-08-24T21:55:12.057+0800 debug /pipeline/source/src/isurpass/openservice/mqttservice/mqttservice.go:115 will send test message ... |
|
2020-08-24T21:55:05.999534734Z [net] Received Message |
|
Unfortunately I cannot spot anything obvious in the logs but do have a couple of suggestions below. In order to assist further I think I'd need a minimal, reproducible example application that demonstrates the issue (perhaps using broker.emqx.io). These issues can be difficult to track down and, unfortunately, with the limited amount of code you have provided I cannot see anything actionable (note that the issue may not be due to a problem with the go library). As far as I can see the go library is running OK; the ping checks exercise input/output and responses are fairly rapid; e.g.: I would also note that a network issue could result in your "check alive" message being lost and, because you are sending one every 5 seconds and raising an error if nothing is received for 10 seconds, all it would really take is one missing message (I'm unsure if emqx will resend a message that has not been acknowledged; the spec only requires that unacknowledged messages be resent when the connection is re-established). Default Message HandlerFrom the log: This means that the client is receiving messages for which there is no subscription (this means the message is totally ignored and no ACK will be sent). If you want to see what these messages are (and send an ACK) use You did not mention how long the application is running before it stops but one possibility is that the broker is exhausting available Packet Identifiers (called Check aliveThere is a potential for a data race here (you have separate go-routines reading/writing to |
|
@MattBrittan , thank you very much, I will enhance and continue to trace ~ |
|
Closing this due to inactivity; if the issue is still occurring and you have further info then feel free to re-open. |
the paho client appear suddenly no ack after receive message until I restart the program with the paho client
the following is the trace log from emqx server before restart the paho client :
openservice.fault.log
the following is the trace log from emqx server after restart the paho client :
openservice.ok.log
no any errror info in log, it seems the paho client dead lock, I had upgraded the paho client for the following bug before:
0526fed
can you tell me if exist another problem in the paho client ?
The text was updated successfully, but these errors were encountered: