Nice Re-Org of Client Class Allows Users to Balance Load
This morning I was working on how to decrease the latency of my ticker plant client for very large subscription sets when it hit me. In my original design, I had a single ZeroMQ receiver that fed any number of subscribed clients. That's OK for small sets, and maybe that's OK for large sets with conflation, but I wanted something that allowed the user a lot more flexibility.
So I stopped making the ZeroMQ receiver a static ivar of the client class, and made it a regular ivar of the client. I then changed the ZeroMQ receiver to make it's amq::context_t a singleton in the process (static ivar of the ZeroMQ receiver class) so that I could control the thread usage there. There will still be a single zmq::socket_t for each receiver, and since the receivers are paired with the clients, we'll have the ability to use the filtering of the reliable multicast on the individual client subscriptions.
Now, if you want to subscribe to a large dataset you can. It'll all come to the one client. But if you want to handle things a little more quickly, subscribe to smaller groups, and each client will get just that portion of the whole that it asks for, but will have the threading to be able to take it as fast as it can.
Controllable speed. If you don't need it, just subscribe to a big block. But if you need it, it's there. This is a great little compromise that should give the users a lot more flexibility than they have now.
Excited about looking at the results at the open. Should be exciting.