Skip to content
This repository has been archived by the owner on Feb 11, 2020. It is now read-only.

mongodb persistence is saving qos 0 packets #229

Closed
mazhack opened this issue Mar 30, 2015 · 3 comments · Fixed by #230
Closed

mongodb persistence is saving qos 0 packets #229

mazhack opened this issue Mar 30, 2015 · 3 comments · Fixed by #230

Comments

@mazhack
Copy link

mazhack commented Mar 30, 2015

cleansession false, subscription topic is qos 1, i send some qos 0 packets and this are stored, but must be discarded. mongodb has store many irrelevant packets and performance down...

Levelup store has same problem...

http://www.hivemq.com/mqtt-essentials-part-7-persistent-session-queuing-messages/

So what will be stored in the session?

  • Existence of a session, even if there are no subscriptions
  • All subscriptions
    *All messages in a Quality of Service (QoS) 1 or 2 flow, which are not confirmed by the client
    *All new QoS 1 or 2 messages, which the client missed while it was offlne
    *All received QoS 2 messages, which are not yet confirmed to the client

Mosquitto has a specific option for enabled it:

Clean session / Durable connections

On connection, a client sets the "clean session" flag, which is sometimes also known as the "clean start" flag. If clean session is set to false, then the connection is treated as durable. This means that when the client disconnects, any subscriptions it has will remain and any subsequent QoS 1 or 2 messages will be stored until it connects again in the future. If clean session is true, then all subscriptions will be removed for the client when it disconnects.

queue_qos0_messages [ true | false ]

Set to true to queue messages with QoS 0 when a persistent client is disconnected. These messages are included in the limit imposed by max_queued_messages. Defaults to false.

Note that the MQTT v3.1 spec states that only QoS 1 and 2 messages should be saved in this situation so this is a non-standard option.

My mosca servers are slow and clients are fail because mosca send to many qos 0 packets after reconnect...

in packet collection:
{
"_id": ObjectId("5519aa844299b6b52fa8735a"),
"client": "1100890580.990.1427234577275724365.7227479706",
"packet": {
"topic": "taxis/990",
"payload": "",
"messageId": NumberInt(5),
"qos": NumberInt(0),
"retain": false
}
}

thank you...

mazhack pushed a commit to mazhack/mosca that referenced this issue Mar 30, 2015
new option "store_qos0_messages"
mazhack pushed a commit to mazhack/mosca that referenced this issue Mar 30, 2015
all test passed, no new test
new option store_qos0_messages
@mazhack
Copy link
Author

mazhack commented Mar 30, 2015

after and before patch...
using mongodb, 700 clients connected

mosca_patch

mazhack pushed a commit to mazhack/mosca that referenced this issue Mar 31, 2015
add 4 new simple test for option store_qos0_messages
@mcollina
Copy link
Collaborator

mcollina commented Apr 1, 2015

Sorry, I only see one graph, can you please post them both, before and after the patch?

mazhack pushed a commit to mazhack/mosca that referenced this issue Apr 6, 2015
@mazhack
Copy link
Author

mazhack commented Apr 6, 2015

see before and after 12:00 in graphics, store qos 0 packets uses more cpu, there are 10 vm with mosca broker, reduce cpu usage with non store qos0 is better for us, and reconnections are less, so 2 problems fixed.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants