eclipse-mosquitto / mosquitto

Eclipse Mosquitto - An open source MQTT broker
https://mosquitto.org
Other
9.06k stars 2.39k forks source link

Mosquitto broker stop publishing on subscribed topics #1821

Open ashu3123 opened 4 years ago

ashu3123 commented 4 years ago

when our client code start publishing on topics , mosquitto broker show that it is continuous publishing. we see it on a command prompt .but at the same time when we subscribe the topic we see it that after some messages it stops and give warning : received PUBREL from client for unknown packet identifier 16. So how can we solve this issue? CLIP-1F060161

ralight commented 4 years ago

The message "Outgoing messages are being dropped for client client001" means that the broker has a queue of QoS 1 or QoS 2 messages in a queue waiting to be delivered to client001. By default this queue can get up to 120 messages (20 in flight and 100 queued). If more messages are received for client001 beyond this limit, they will be dropped and so not get sent to the client. If the client is connected when this happens, it indicates that the client is not able to deal with the rate of messages being sent to it, or there is a bug in the client.

The other log message about an unknown packet identifier relates to a QoS 2 message coming from the client to the broker. The QoS 2 message flow in this case is PUBLISH (to broker), PUBREC (to client), PUBREL (to broker), PUBCOMP (to client). So to receive a PUBREL with an unknown packet identifier suggests could mean that the client has a bug that means it mixes up the packet identifiers, or another similar bug, but I think that is unlikely. Another more likely scenario is that you are using MQTT v5, and the publishing client does not fully implement the spec. When a client publishes a QoS 2 message, if the broker knows that there are no subscribers for the topic, it is allowed in MQTT v5 to send a PUBREC with a reason code of no-matching-subscribers. In that situation, it is not necessary to complete the message flow. If your client does not take this reason code into account, then it would attempt to continue the full QoS 2 message flow, at which point the broker would produce the log message that you see. It isn't a problem in that situation though.

More up to date versions of the broker (I would suggest that you upgrade to 1.6.12) do not log that message because it isn't really that important.

ashu3123 commented 4 years ago

Thanks for the response, but when i use Bevywise broker i didn't get any warning .If i use another client to subscribe on the topic over which i am publishing i get around 16 message using mosquitto but using bevywise i get continuous message. so any changes are required in the setting?

ralight commented 4 years ago

It seems likely that Bevywise simply ignores the case where it receives unknown PUBREL messages, which Mosquitto does as well in more recent versions than you are using. Alternatively, Bevywise does not support the MQTT v5 shortened QoS 2 flow. That should not be occurring if you have a subscriber though.

If your subscribing client is not receiving all of the messages you expect, either there is a bug in the client - which seems unlikely if you see the expected behaviour with another broker - or you have modified the inflight and queued messages settings I described above to be very small.

Can you provide an example of what you are seeing in a wireshark/tcpdump trace? Also your broker configuration?

ashu3123 commented 4 years ago

Thanks for your reply. i have upgraded it to latest version 1.6.12.There also problem remains same. Actually i am using pahoo mqtt client code with winsock api for secure communication. The code is in multi threading and while publishing if i give around 400 millisecond sleep to thread which is publishing i get good results but if i reduces less then 400 it stops after some message.Although on cmd prompt it shows continuous publishing but at subscriber end i get around 100 messages only.i haven't changed any settings in mosquitto it remain same as i downloaded.