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
[CHANGED] MQTT RMS consumer: instead of deleting/creating, create a u… #5017
Conversation
…nique one with an InactiveThreshold
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change look ok to me, but not sure what the issue was and how is this going to be different.
I am concerned by what I saw for a customer that might be triggered by quick succession of delete and add with same name but different NRG assignment. |
@derekcollison I can't get past the build error after several retries, |
I have seen this test starting to flap on Travis. I can have a look say tomorrow, but for now, if it is a blocker, add a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM - Small comment but not blocking.
// The old one should expire and get deleted due to inactivity. The name for | ||
// the durable is $MQTT_rmsgs_{uuid}_{server-name}, the server name is just | ||
// for readability. | ||
rmDurName := mqttRetainedMsgsStreamName + "_" + nuid.Next() + "_" + s.String() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not really durable, just the name, and we only really expect it to live for the lifetime of the running server.
Every time MQTT was initialized for an account on a server, it was re-creating the server-specific RMS consumer by deleting it and creating again, with the same name. @derek though it might be causing issues and suggested this change.
Now, always create a new consumer with a unique name, and a 5 minute inactivity threshold. Kept the code to delete the "legacy"-named consumer, even though it'd get executed at most once, errors ignored.