-
Notifications
You must be signed in to change notification settings - Fork 7
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
Messaging consolidation #14
Conversation
Signed-off-by: Rodrigo Tobar <rtobar@icrar.org>
It has been years since we use exclusively ZeroRPC for our RPC needs, so there really is no point on maintaining the alternatives. If we need them at some point we can bring them back, but most probably we will do fine without them. Signed-off-by: Rodrigo Tobar <rtobar@icrar.org>
We previously didn't do this, and while it didn't give us any problems it wasn't really what a good citizen should do with their sockets. Signed-off-by: Rodrigo Tobar <rtobar@icrar.org>
This change should decrease the latency with which a subscriber socket connects to its publisher, hopefully making the system more stable. Signed-off-by: Rodrigo Tobar <rtobar@icrar.org>
This commit introduces the creation of a unique ZeroMQ Context instance at the level of the NodeManager class that can be used instead of the per-class Context instances we have been using in the ZeroPubSubMixIn, ZeroRPCClient and ZeroRPCServer classes. In order to be usable from all of these, this context object must be created using zerorpc's Context class, which contains a few additions on top of a ZeroMQ's Context, and that are used by ZeroRPC's classes. Instead of managing their own Context instances, now the ZMQPubSubMixIn, the ZeroRPCClient and the ZeroRPCServer classes all share the new, unique Context instance created by the NodeManager classes, who takes care of creating it and terminating it. This change not only makes the code easier to maintain (because there is less resource management in general), it also should reduce the number of threads used by the node manager, since each Context will create at least one I/O thread. Signed-off-by: Rodrigo Tobar <rtobar@icrar.org>
We previously imported these modules only when required, since the RPC framework to use was a runtime choice. Now that we have removed that choice, and zerorpc is the only alternative, there is no point anymore on having conditional imports spread across the rpc module. Signed-off-by: Rodrigo Tobar <rtobar@icrar.org>
This is simply to keep the code more maintainable and easier to follow. Signed-off-by: Rodrigo Tobar <rtobar@icrar.org>
We already are within the context of an ZMQPubSubMixIn class so there's no need for additional "zmq" prefixes/suffixes in member names, it makes the code a bit more difficult to follow otherwise. The names of the different members also didn't properly describe what they did. The new names instead reflect a bit better the intent behind them. There was also a log statement that read "Receiving" instead of "Publishing", as it most probably got lost in this confusion of names. Signed-off-by: Rodrigo Tobar <rtobar@icrar.org>
This should help future readers (including myself) understand what's going on and why we chose to go this way in the first place. Signed-off-by: Rodrigo Tobar <rtobar@icrar.org>
Only once the connection has been fully made we can declare success and let the flow continue in the thread that initiated the subscription. Signed-off-by: Rodrigo Tobar <rtobar@icrar.org>
Thanks for a substantial improvement in code maintainability (removal of dead code, new comments, naming, single 0MQ context object ...) |
YAN-322 inserting ticket number |
@mdolensk Thanks for reviewing the PR. Would you mind marking it as reviewed, but without closing it? I'll then merge the code into the master branch. That way there is a better record of the acceptance actually happening. |
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.
Thanks for a substantial improvement in code maintainability (removal of dead code, new comments, naming, single 0MQ context object ...)
This set of changes contains a series of improvements on the inter-node messaging system: