-
Notifications
You must be signed in to change notification settings - Fork 98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PingHandler will not time time out #137
Comments
I'm not sure why this uses 1.5 x the ping timeout as the measure of success. The spec says:
So the one and a half times is a requirement on the server side (assuming the client sends a ping every I suspect this was modelled on the C library which uses the same basic methodology but will never send concurrent ping requests in flight (so changing |
I instead proposed a different design in #139, but I'm happy to open a different PR with the fix you describe. |
One more tangential issue with PingHandler is that, in theory the Client can accept a custom PingHandler but to initialise a PingHandler a FailureHandler is required which inherently requires internal field access. For the default one an anonymous function is used. https://github.com/eclipse/paho.golang/blob/master/paho/client.go#L150 This essentially limits the user to only use the default PingHandler. Maybe a better way would be to accept NewPingHandler func and then generate it and pass the same FailureHandler. |
No worries! I'm also curious what the use case is for custom PingHandlers. |
Really sorry for the lack of response on this - I am now beginning to accept PR's on the I think (as discussed in #207) we should also add something like If we are making a change then I also wonder if we should have so something like:
|
Sounds good, I went ahead and closed that PR (still kept the branch in my fork for reference). I'll open a brand new PR. What you propose sounds reasonable, will get a PR out soon. |
Describe the bug
The logic of
PingHandler
means that there will never be a timeout, andpingFailHandler
will never be called. I'm working on getting out a PR for this.To reproduce
Wrote a test which should pass if
PingHandler
times out, but the test fails:Expected behaviour
PingHandler
should eventually callpingFailHandler
ifPingResp()
is never called.Additional context
Looks like this happens because
p.lastPing
is reset every time aPINGREQ
is sent (approximately everypt
duration), sotime.Since(p.lastPing)
doesn't get the chance to get to 1.5xpt
for a timeout to be detected.The text was updated successfully, but these errors were encountered: