Connection to HiveMQ dropping with an error #1623
Comments
|
Under the assumption that this error is on our Android app, I'll transfer this issue. |
|
Difficult to know what's going on here. Could be the network, could be the broker not being responsive, could be the device not waking the app to do keepalives.... |
|
Hi, I have exactly the same issue: The Android phone (Samsung Galaxy S21 FE) connects to the broker, keeps the connection for "exactly" 1 minute, then disconnects. Then I see the error above. It doesn't matter if the phone uses WiFi or mobile network. Since it happens almost exactly each minute and the immediate reconnect works, it doesn't look to me like some network or server issue. My iPhone stays connected all the time if I leave the app open. Running in the background it connects on demand (pushing location) and closes the connection afterwards. Btw, I use MQTT over websockets. The MQTT broker sits behind an nginx reverse proxy. |
|
Probably nginx terminates the connection after 60 seconds of inactivity (https://nginx.org/en/docs/http/websocket.html) |
|
Yep, it looks like increasing the timeouts in nginx solved it for me 😉 |
|
@nicholasmparker can you confirm this solves the issue for you likewise? |
|
After increasing the timeouts to 1 day in nginx I monitored the reconnects a few days. Sometimes the phone kept the connection for 2h, sometimes for 1h or 30 min or 22 min. The reconnect usually happened within 0 to 10 minutes. And when the connection is lost I see the error from the first post. Maybe these are "normal" connection losses due to ... Android stuff 😉 But today I switched the MQTT broker to Mosquitto, without changing the nginx config. Now I see the error log every exact 5 minutes while keep alive is set to 900s in the app. Reconnect happens immediately according to mosquitto logs. I do not see this behavior when opening the iOS app for let's say 10 minutes. It stays connected all the time. Any ideas where this new magic 5 minutes come from? This was not the case with the last broker I used (aedes based). |
|
You've not said what device you're using, and that 5 mins could be a device thing. Do you see anything in the OT log about why it dropped the connection? |
|
It is a Galaxy S21 FE. The OT log shows the error from the first posts here ( A few days ago I switched back from Mosquitto to my other broker, and the connection losses every exact 5 minutes are gone. Now I am back to the behavior where the Android app can sometimes keep the connection for 2 hours, sometimes for 20 minutes and so on, which I guess is normal. I don't know what the problem is between Android app and Mosquitto, because my other broker works well. I can solve both problems by replacing Mosquitto (v2.0.18 btw) which is fine for me. |
|
I'm having a hard time following. What is "my other broker", is that HiveMQ? We're not aware of issues with Android and Mosquitto over MQTT, in fact most of us have that combination. Can you get rid of the websocket connection and use plain MQTT (port 1883, or 8883 with TLS)? |
|
When switching between differen MQTT backends make sure to empty queues on the broker end by either
|
It's my own broker based on aedes (will be released soon).
That's interesting. Unfortunately I don't have permanent access to the Android phone, so testing that scenario is a bit difficult. Maybe I can find an old Android phone here and reproduce the issue.
I did the latter by setting the clean flag in the app and restarting the app, then switched back to clean=false and restarted the app again. |
|
Marking issue with request for more data as stale, due to no updates. |
|
Any updates? |
|
@compuguy updates for what? We're awaiting a response from OP. |
Apologies for that. I'm not sure if it is the same issue (I use the free HiveMQ MQTT service), but I've had similar connection timeout/disconnect issues with the latest beta build of Owntracks (Beta 3). I'm connecting via a websocket though. I've redacted/changed certain information for privacy reasons: |
|
@compuguy Is there any pattern to the periodicity of the disconnects? The bottom line with a lot of this stuff is that relying on (or expecting) long-term TCP connections to never disconnect is highly optimistic, especially in a mobile context where changes to the connected network interface, the mobile OS, the whims of the other party and the internet all conspire to drop / ignore packets. TCP's particularly susceptible to lost packets, as the default fall-back error recovering mechanism is just to tear down the connection and start again. |
|
I'm not sure this is the same issue but I am noticing this series of errors every hours or so. The symptom I am seeing is that the app frequently is not reporting the current locations of Friends (users). My Home Assistant is also subscribed to the queue and seems to be successfully updating. Is there a setting in the Owntracks app and/or HiveMQ I need to adjust? Owntracks Version 2.5.0 Also seeing this with ... ... |
I agree. Once a prelease or an actual release of 2.5.2 is cut, I can confirm that this isn't an issue. |
|
Marking issue with request for more data as stale, due to no updates. |
Anyone experiencing this? From the debug logs
2024-03-01 10:47:36.005 E MessageProcessorEndpointMqtt: connectionLost error
(32109) - java.io.EOFException
at org.eclipse.paho.client.mqttv3.internal.CommsReceiver.run(Unknown Source:213)
at java.lang.Thread.run(Thread.java:1012)
Caused by: java.io.EOFException
at java.io.DataInputStream.readByte(DataInputStream.java:275)
at org.eclipse.paho.client.mqttv3.internal.wire.MqttInputStream.readMqttWireMessage(SourceFile:14)
at org.eclipse.paho.client.mqttv3.internal.CommsReceiver.run(Unknown Source:64)
... 1 more
The text was updated successfully, but these errors were encountered: