Skip to content
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

createRetainedStream is per topic #122

Closed
behrad opened this issue Jul 1, 2017 · 5 comments
Closed

createRetainedStream is per topic #122

behrad opened this issue Jul 1, 2017 · 5 comments

Comments

@behrad
Copy link
Collaborator

behrad commented Jul 1, 2017

createRetainedStream is called per subscription topic, for client's with multiple subscriptions it looks weird. e.g. redis persistence currently runs hget retained n times for a client connecting with n offline subscriptions.
Can we

  1. change createRetainedStream(topic) to createRetainedStream(topics) in persistence api.
  2. move sendRetained calls here to the end of completeSubscribe called with the whole packet.subscriptions.map(s=>s.topic)
@mcollina
Copy link
Collaborator

mcollina commented Jul 2, 2017

How big is n in your experience? It would be nice to have some numbers before committing.

This would need to be changed in aedes-persistence, and then downstream to all implementors. I'm 👍 if you want to tackle this one.

@behrad
Copy link
Collaborator Author

behrad commented Jul 2, 2017

How big is n in your experience?

  1. n >= 3 for each of my clients
  2. Bad news is that sendRetained runs at the end of handle subscribe, which is called on each CONNECT (on restore sub). So even if clients don't SUBSCRIBE, retained check will be done on each connect.
    And in our environment we have a ratio of 100 conn/disconn per sec!

and please clarify something for me, I had checked mqtt spec some time ago, but can't remember if we should sendRetained both on CONNECT/SUBSCRIBE, or only as a response to a SUBSCRIBE command? I mean when a client SUBSCRIBEs with qos=1 and clean=false, should we send retained on each subsequent feature connects only?

@behrad
Copy link
Collaborator Author

behrad commented Jul 2, 2017

we had a somehow related disscusion here @mcollina, However I'm not sure my statement there was right!

@mcollina
Copy link
Collaborator

mcollina commented Jul 3, 2017

had checked mqtt spec some time ago, but can't remember if we should sendRetained both on CONNECT/SUBSCRIBE, or only as a response to a SUBSCRIBE command?

@behrad the retained check is part of the mqtt implementation decisions :(. Mosquitto implements it the same way we do, resending the retained message on connect. However, the spec is unclear to me.
You might want to ask them, maybe.

@behrad go ahead and start making the changes. However, I would implement it in as a non-breaking changes. Adding a new createdRetainedStreamCombi(topics) which in the default implementation calls createRetainedStream(topic), so that we do not have to implement it for all the persistences right now.

@behrad
Copy link
Collaborator Author

behrad commented Jul 7, 2017

handled in #121

@behrad behrad closed this as completed Jul 7, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants