-
Notifications
You must be signed in to change notification settings - Fork 33
Conversation
So, it seems that Connext's request-reply uses some strange topic names. For example, the service server creates:
But the client creates:
Note what looks like a GUID attached to the reply topic. It's not clear to me how the replier (service server) delivers the reply to the requester (service client). I spent the better part of last night trying to figure out a better way to figure out when the service server is available for how Connext implements Request-Reply. I have some ideas, but as of right now this is not ready for merging. |
7fde876
to
8239f9a
Compare
5cdd35b
to
b8a1e26
Compare
b8a1e26
to
9013a0b
Compare
@@ -176,7 +198,7 @@ rmw_create_publisher( | |||
return nullptr; | |||
} | |||
|
|||
auto node_info = static_cast<ConnextNodeInfo *>(node->data); | |||
ConnextNodeInfo * node_info = static_cast<ConnextNodeInfo *>(node->data); |
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.
Should this be changed back to auto
?
Same below.
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.
I think I did that so my autocomplete would work, but I can change them back: 90d4c86
This recent change broke While not being actively tested at the moment maybe it can be easily fixed @wjwwood ? |
I believe it is now failing because the wait_for_service is still not implemented, see: The tests could be disabled, but I don't know if it is worth it since we're not regularly trying to figure out which failures are known and which are not for that rmw implementation. The fact that this function is not implemented is already tracked in an issue: #203 I'm not sure about the other failures. |
Since the merge numerous very simple tests which only do pub/sub are failing. I don't think the referenced ticket about |
Well I'm sorry it is broken, because it wasn't my intention to break it, in fact I spent some extra time trying to keep it up to speed. However, fixing this is not at the top of my priority list because it's not one of our supported rmw implementations right now. |
Fixes #168
This required, apparently for the first time, that the node is given to the
rmw_destroy_client
andrmw_destroy_service
calls, so that will change the rmw API.I'm still debugging some issues with the tests.