-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
new bridge config: something like bridge_reconnect_no_clean_session #601
Comments
You said the QoS messages "generated BEFORE a reconnect for a bridge" were not delivered AFTER that on cleansession true? It seems normal. |
Indeed it does. It's not a bug report, but a discussion / feature request. The point is that you can't have QoS without also getting retained messages and subscriptions for free, which may be undesirable. |
I understood that you agreed the current behavior of cleansession is right, and need something else to solve your situation. Right? |
Well, I think the clean session should be different for a reconnect than a connect. As I said, otherwise you can't use QoS without also getting retained values and subscriptions, always. |
Are you missing the retained flag on messges received are only received for messages that are published because they were retained, vs publishes that are "fresh" ? |
Sorry, could you maybe edit that :)? I don't quite get it. |
New MQTTv5 Publication Expiry Interval may solve your issue in the future. |
@wiebeytec will you wait for MQTTv5, or do you propose any specific change on current mosquitto? |
We worked around it for now (by doing manual retries), but the fact that you can't have QoS without also forcing retained messages and subscriptions on you, seems a conceptual problem. However, is it non-standard and therefore undesirable to implement the |
Mosquitto has the
cleansession
option for a bridge configuration. But, would it make sense to also have something likebridge_reconnect_no_clean_session = true
? This would obviously only apply to reconnects while Mosquitto is active.I'm running into the issue that QoS messages are not delivered after a reconnect for a bridge that is configured as
cleansession true
. But, I can't set the whole bridge tocleansession false
. One reason being, is that I don't want QoS messages from yesterday, last week, or last year.What complicates matters, is that the standard doesn't allow for an expire time on QoS messages. Otherwise setting
cleansession
to false would be easier (though still hard in our case).The text was updated successfully, but these errors were encountered: