-
Notifications
You must be signed in to change notification settings - Fork 387
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
Listeners are not removed upon unsubscribe() #288
Comments
Curious if anyone else has experienced this or have a good work around? |
I'm not sure in what scenario to use |
Essentially the scenario is if you register multiple subscribers on the topic and want to close all at once/shut down the whole topic (and later reconnect without a page refresh). Ideally one would always keep track of all registered callback listeners, but that might not be the case or there might be connection issues and you reload only parts of the state (we had modal views in one application, connecting and disconnecting on open/close). From my point of view it is not about whether the feature is used, but what the expected behaviour is as long as it exists. It should either be removed or work like expected. Making a difference in behaviour beween Regarding a workaround -- I use a fork with some modifications and just pull regularly new versions from the official repo. |
I think you could interpret a
For 2 the problem is there is no way to resubscribe all the topics that were unsubscribed with a |
Perhaps I'm not using it the way it was intended either... but I create a listener
and here is what it looks like:
I subscribe to the message:
and now it looks like this (note the subscribeID and _events.message:
regardless of how I try to unsubscribe:
the only thing that happens (at least that I can visibly see) is that subscribeId remains and becomes null... the callback is still there.
now when I try to re-subscribe I get 2 call backs instead of one:
and thus 2 messages instead of 1... here is my workaround for now:
(but have to appropriately check that it is defined first)... |
Are you storing the handle so you can later unsubscribe? var handle = listener.subscribe(handleMsg);
listener.unsubscribe(handle); |
yes, I've tried it that way... though I believe the documentation (http://robotwebtools.org/jsdoc/roslibjs/current/Topic.html) implies that you use the Admittedly I'm instantiating the listener through react-ros (https://github.com/flynneva/react-ros), but it looks like a pass-through to roslib for the listener creation:
when I try to save the handle of the subscribe this issue (#165) seems to imply that unsubscribe does not touch the callback and instead need to use same issue, still open here: #343 |
Can confirm that
I tried it with
|
If
topic.unsubscribe()
is called without a parameter, it will not remove the callbacks, but instead unregister the whole topic at the rosconnection. This is fine as long as the topic object is destroyed after unsubscribing, but in my use case we subscribe to the same topic instance again. This adds a new callback and re-registers at the ros connection, which means now two callbacks are executed...The problem seems to be acknowledged in this code comment:
roslibjs/src/core/Topic.js
Line 125 in 47336fa
I do not see why the client would want to handle this itself, as it seems to be the expected outcome.
unsubscribe(X)
removes callback X from the topic's listener-list so the paradigm seems to be "unsubscribe X from the topic`. This should be the same without parameters, but currently it is "unsubscribe the topic from ros", which changes the direction of the method.I propose not only unsubscribing to ros, but also removing all listener callbacks.
The text was updated successfully, but these errors were encountered: