Rebalancing the Multicast Channels Seems to Reduce Errors

ZeroMQ

I've been trying to track down some ZeroMQ errors I've been seeing today as I try to build a clean multi-threaded client for those folks that want more performance out of the ticker plant client. It's a decent design in that it devolves to the same client as I have now if you only create one client. The zmq::context_t is essentially a process singleton, by design, so I put that as a static class variable on my ZMQ receiver class, but then each receiver class has it's own zmq::socket_t instance which is what you connect() to the URLs that are the reliable multicast channels.

It all makes sense on paper, but I have been seeing a lot of errors that seem to be coming from ZeroMQ, and that's just pretty unlikely in my experience. So I started to wonder if there was some external factor that was causing ZeroMQ to have these problems. I had initially cut up the multicast channels into 27 per message type: A through Z and 'other'. I decided that OPRA had a balanced scheme for 48 channels, and that couldn't be worse, so I reconfigured my channels to match OPRA's.

As it's running, it's certainly doing better than before - even if it's not perfect, it's better. I'll have to keep an eye on it, and get the latest ZeroMQ to see if they have fixed any issues in the latest version on github. I know we're going to need something as ZeroMQ is a bit flakey still. But to be fair, I'm pushing it pretty hard.

UPDATE: OK, not perfect... we're still seeing errors, but it's better. Still have something to hammer on... I'll get it - eventually.