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

rospy: rospy.Publisher.unregister does not work (ros ticket #3900) #111

Open
tfoote opened this issue Jan 9, 2013 · 17 comments
Open

rospy: rospy.Publisher.unregister does not work (ros ticket #3900) #111

tfoote opened this issue Jan 9, 2013 · 17 comments
Labels
Milestone

Comments

@tfoote
Copy link
Member

tfoote commented Jan 9, 2013

Testing on latest fuerte. When Publisher.unregister() is called, the following error starts popping up periodically (from another thread):

{{{
[WARN] [WallTime: 1332168660.580924] Could not process inbound connection: ...
}}}

This makes it difficult to change the publisher of the same topic...

trac data:

@tfoote
Copy link
Member Author

tfoote commented Jan 9, 2013

[kwc] in r16546 I change the logger level to an internal logger that should be less noisy. The actual error message appears to be edited in your ticket, but my guess is that this is usually caused by a subscriber continuing to attempt to connect to a publisher (with stale registration information).

in r16547 I changed a potential stale reconnection logic that could cause the above.

@tfoote
Copy link
Member Author

tfoote commented Jan 9, 2013

[rdiankov] i'm not sure if it is normal to have that message, but even after putting in changes r16547, the message still pops up.

What i'm doing is unregistering the goal/cancel publishers of an actionlib ActionClient.

@tfoote
Copy link
Member Author

tfoote commented Jan 9, 2013

[kwc] per comment, you need r16546

@tfoote
Copy link
Member Author

tfoote commented Jan 9, 2013

[rdiankov] right, that only changes whether the messages shows on the screen or not. from your response, i thought these stale connections shouldn't be happening at all, but if they are a normal part of the operation then i have no complaints.

@tfoote
Copy link
Member Author

tfoote commented Jan 9, 2013

[kwc] From the perspective of the publisher, the message is an expected race condition, which is why the patch mostly addresses visibility. The other patch addresses one possible way in which the message could be raised, but there are others as well

If it happens periodically, then it means something, then something is happening on the subscriber side. There's not enough information in this ticket to debug that side of the issue, so I am marking 'fixed'. If you wish to open another ticket with something that can reproduce this, happy to look into it more.

@tfoote
Copy link
Member Author

tfoote commented Jan 9, 2013

[rdiankov] i'm attaching example scripts that reproduces the stale connections. To run it do:

{{{
roscore
python fibonacci_server.py
python testclient2.py
}}}

The stale connection junk should be printed on the client side:

{{{
[WARN] [WallTime: 1333157496.276146] Could not process inbound connection: [/testclient] is not a publisher of [/fibonacci/goal]. Topics are [['/fibonacci/cancel', 'actionlib_msgs/GoalID'], ['/rosout', 'rosgraph_msgs/Log']]{'message_definition': '# ====== DO NOT MODIFY! AUTOGENERATED FROM AN ACTION DEFINITION ======\n\nHeader header\nactionlib_msgs/GoalID goal_id\nFibonacciGoal goal\n\n================================================================================\nMSG: std_msgs/Header\n# Standard metadata for higher-level stamped data types.\n# This is generally used to communicate timestamped data \n# in a particular coordinate frame.\n# \n# sequence ID: consecutively increasing ID \nuint32 seq\n#Two-integer timestamp that is expressed as:\n# * stamp.secs: seconds (stamp_secs) since epoch\n# * stamp.nsecs: nanoseconds since stamp_secs\n# time-handling sugar is provided by the client library\ntime stamp\n#Frame this data is associated with\n# 0: no frame\n# 1: global frame\nstring frame_id\n\n================================================================================\nMSG: actionlib_msgs/GoalID\n# The stamp should store the time at which this goal was requested.\n# It is used by an action server when it tries to preempt all\n# goals that were requested before a certain time\ntime stamp\n\n# The id provides a way to associate feedback and\n# result message with specific goal requests. The id\n# specified must be unique.\nstring id\n\n\n================================================================================\nMSG: actionlib_tutorials/FibonacciGoal\n# ====== DO NOT MODIFY! AUTOGENERATED FROM AN ACTION DEFINITION ======\n#goal definition\nint32 order\n\n', 'callerid': '/fibonacci', 'tcp_nodelay': '0', 'md5sum': '006871c7fa1d0e3d5fe2226bf17b2a94', 'topic': '/fibonacci/goal', 'type': 'actionlib_tutorials/FibonacciActionGoal'}
[WARN] [WallTime: 1333157496.279872] Could not process inbound connection: [/testclient] is not a publisher of [/fibonacci/cancel]. Topics are [['/rosout', 'rosgraph_msgs/Log']]{'message_definition': '# The stamp should store the time at which this goal was requested.\n# It is used by an action server when it tries to preempt all\n# goals that were requested before a certain time\ntime stamp\n\n# The id provides a way to associate feedback and\n# result message with specific goal requests. The id\n# specified must be unique.\nstring id\n\n\n', 'callerid': '/fibonacci', 'tcp_nodelay': '0', 'md5sum': '302881f31927c1df708a2dbab0e80ee8', 'topic': '/fibonacci/cancel', 'type': 'actionlib_msgs/GoalID'}
}}}

Note that on the latest rospy, the messages are using rospywarn

@Hi-Zed
Copy link

Hi-Zed commented Jun 13, 2018

Is there any news on this issue? Is there a clean way to unsubscribe from a topic in rospy?
I'm using a python node where I want to publish a single message using a latched publisher, after that I want to unsubscribe from the topic. However if I do that, I get periodically the warning message.

@machinekoder
Copy link

The problem still exists. A workaround is to not unregister publisher sockets and leave them dangling. However, this is not very clean and might result in memory exhaust for a long-running process.

@Alkarex
Copy link

Alkarex commented Aug 22, 2018

This issue affects the ROS bridge http://wiki.ros.org/rosbridge_suite , RobotWebTools/rosbridge_suite#138 (and the many related issues) and is mitigated by using a very long timeout to avoid unregistering the closed connections RobotWebTools/rosbridge_suite#322 which is not a very a stable solution.

@dirk-thomas
Copy link
Member

Please consider to provide a PR to address the problem.

@ejalaa12
Copy link

The issue seems to be on the Subscriber side too.
I played with a simple python script to gather a few remarks about this issue.
Here are some conclusion:

  • When calling pub.unregister, if we have no subscriber then the call is successful.
  • Failure to call pub.unregister blocks further publishers from this node to publish to the same topic

You can find the script and more detailed remarks here

@SteveZhangBit
Copy link

Any news on this issue? I'm still encountering this on Indigo with Ubuntu 14.04. Just wondering is it solved in later distributions?

@gonzalocasas
Copy link

I second the request of @SteveZhangBit , is there any news about whether this would be fixed at some point? Considering it's open since 2013, I assume the fix is not trivial if people decided to spend time and work around it on other projects instead of fixing the root cause. Is that really the case or just that nobody has seriously tried to fix the root cause so far?

@hyansuper
Copy link

any updates?

@soulslicer
Copy link

Still broken

@dhirajdhule
Copy link

still broken

@snick-m
Copy link

snick-m commented Jan 12, 2023

This is still a problem apparently. Even after 10 whole years! I'm very much interested in implementing a fix for this. I would love if anyone could provide me some hints on what they understand could be the root problem.

From everything I've read related to the issue:-

  • It's caused by unregistering when there are subscribers registered.
  • It may have something to do with how unregisters are handled.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests