-
Notifications
You must be signed in to change notification settings - Fork 312
consistent failure: network i/o timeout #29
Comments
A failure after 45 seconds would be 1.5 times the service.minKeepAlive in client.go - could that be a hint? |
When this code is added, the problem goes away:
(but it's not enough to pass in In short: it looks like the keep-alive timer is not properly reset for use with publish-only clients. |
@jcw thanks for the detailed updates. I sincerely apologize for not having tracked this close. TBH I haven't had time to look at this project for a while. Would be happy to merge any PR if you have a fix. |
Unfortunately, I've not been able to chase this and reach a clear-cut conclusion. I'm not even sure that the above workaround is 100% correct - was hoping someone more versed in SurgeMQ than me would be able to look into it. I also ran into other issues with the last-Will (but am not ruling out my own confusion, to be honest). For now, I've decided to use another package as client, with Mosquitto as server. Would love to revisit this later, because I'd prefer a single-exe solution with the server also in Go - but I'm afraid I can't contribute anything more of substance at the moment. Hopefully the above small standalone example will eventually help someone find and fix this bug. |
@jcw It is a better approach to go for Mosquito and Eclipse Paho in any real-world application. Especially because SurgeMQ does not support ACK timeouts. Note: If you're looking for experiments, I rewrote the broker here. |
I find out why get this error so I change the code like below , and find another error #27
|
The following code fails, always after some 42 or 43 seconds (go 1.5.3, Mac OSX 10.11.3):
Sample error output from
go run blah.go -logtostderr
:I can't figure out what is causing this problem. Can anyone else reproduce this on a different system?
The text was updated successfully, but these errors were encountered: