-
Notifications
You must be signed in to change notification settings - Fork 110
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
Subscribe does not remove subscriptions from map on failure #94
Comments
Hi @shekharhimanshu, PerformAction is agnostic to the type of MQTT action being performed. Hence we can't do any automatic cleanup after PerformAction fails as we cannot distinguish between a Subscribe failure or a Publish failure. The cleanup can be performed manually by calling RemoveAllSubscriptionsForPacketId but this API isn't currently exposed by MqttClient. I've added a task in our queue for exposing this API. Please let us know if you have any more questions. |
Hi @vareddy
Yes, you are correct about that. But consider the following sequence:
When above happens, Keep-alive thread will enter into an infinite loop of connect and disconnect. My point was there may be side effects of not cleaning unsuccessful subscriptions from the subscription map and hence IMO, should be handled with.
Yes, you are right about that too. I tried to correct this myself but due to above reason could not come up with a nice solution without drastically changing the design of current SDK.
Thank you for that. But my intention was not that though. In fact, users using this SDK have no idea about Thanks |
Hi @shekharhimanshu, A correction to the above is that One solution would be to keep track of at least one successful subscribe in another variable to ensure that the reconnect does not try to resubscribe to failed subscriptions (checking just the active flag will not help as the flag will be reset on a disconnect). Again this does not help in cleanup of failed subscriptions. That will require major redesign. Does this make sense to you? This can be accompanied by another API that cleans up the subscriptions that failed the first time. This won't refer to the map or packet ID, so the end user can call this on a failed subscription. I implemented the secondary flag fix and it seems to work for the basic testing that I did. |
Yes. I had this in my mind as well but seemed a bit hacky to me. So didn't propose it as a solution.
What kind of api do you have in mind? Is it something like IMO, we can create such an api and mention the subscription map behavior as a known issue with above as its workaround till some major re-design happens.
That's great! Thank you for trying. |
Hi @shekharhimanshu, With reference to the API to remove subscriptions, it could either remove all subscriptions that failed the first time (the addition of the extra flag makes it easy), or remove specific subscriptions as you suggested. |
Both of your proposals LGTM. Thanks. |
Greetings! Sorry to say but this is a very old issue that is probably not getting as much attention as it deservers. We encourage you to check if this is still an issue in the latest release and if you find that this is still a problem, please feel free to open a new one. |
Hello,
It looks like Subscribe api inserts the subscription into the subscription map before sending the actual request.
It then waits for the SUBACK packet.
Subscribe gives up if say, SUBACK is not received within specified time and
ResponseCode::MQTT_REQUEST_TIMEOUT_ERROR
is returned to the user.However, the subscription map is left untouched. Ideally since subscribe to the topic was not successful, it should be removed from the map to avoid any side effects.
One such side effect is inside the Keep-Alive thread:
The Keep-Alive thread will try to resubscribe to topics present in subscription map and hence will also retry those not successful subscriptions each time. In worst case scenario, reconnect might never succeed due to bad subscriptions present inside the subscription map.
Thanks.
The text was updated successfully, but these errors were encountered: