-
Notifications
You must be signed in to change notification settings - Fork 812
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
Errors when updating moquette-broker from 0.15 to 0.16 #705
Comments
This happens because moquette/broker/src/main/java/io/moquette/broker/PostOffice.java Lines 629 to 632 in 9eb2a6f
That clientId is extracted from the packet, do you have any logs around the time the problem manifest? |
@andsel I'm afraid not, definitely not logs of the contents of packets. We have a number of clients integrating with us. Do you think it a pure coincidence that this started happening after this update, by some misbehaving client, or is there new code that could have affected this? |
@andsel This is the order of things happening: |
With version So your problem is not a coincidence, because before this code wasn't present. So the problem could:
|
@andsel also we saw many additional warning logs that did not accompany those exceptions, while we didn't see those logs occur before. |
Do you not already know the clientId from the open connection itself? Does it not make sense to get the clientId from a more permanent place to avoid misbehaving clients, if that is a possibility? |
Do you have a plain test form of the logs to share? |
ClientId (if present) is passed by the client to the server during the CONNECT, then the broker stores the clientID in MQTTConnection and in Session. |
Is it possible for the Publish packet to be handled before the code is run that sets the ClientID on the Channel? moquette/broker/src/main/java/io/moquette/broker/MQTTConnection.java Lines 204 to 237 in 9eb2a6f
(Actual setting in line 215 and 223) Maybe we should move the call to |
I had to do some redaction but this is what I have:
|
Yes that actually would be safer, however I don't think it's related to this. The publish on the new connection is done after it set the clientId in the channel's attributes:
The idea was to set up all connection related stuff after we the broker has a working connection with the client, so setting the clientId into the attributes after the broker was successful in sending the CONNACK. |
That's for sending queued messages with cleanSession=false. |
If |
If I understand the exception right, in this case it is the client itself that publishes, not another client. So is it possible for a client to send a PUBLISH before the CONNACK has gone fully through? Considering that from the client perspective the CONNACK may have been sent, but not processed yet due to our short buffering? |
From [MQTT-3.1.4-5] in MQTT 3.1.1 spec http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html
So this means that a PUB could be sent by the client after the CONNECT and before it receives the CONNACK. So this means that the clientId has to be setup in the Channel attributes before the server reply with a CONNACK. |
So this is a bug and the solution is to move the clientID assignment into Channel's attributes before the CONNACK message is written to the Channel itself. |
Running on JVM 17, yesterday we updated moquette-broker from 0.15 to 0.16 and started seeing these errors in our logs:
And before ánd after this:
Also, our consuming application started reporting errors so it wasn't just some heads-ups but things were actually failing.
Mind you, these didn't start happening immediately but took like half a day to appear.
Any idea what this could be?
The text was updated successfully, but these errors were encountered: