We've realized an odd property of our architecture, and I'm curious if there's a standard solution.
Currently we have router processes using a bound ZMQ_ROUTER socket to receive messages from client processes, each connected to multiple routers via a ZMQ_DEALER socket. If a client process reboots, it will reconnect using a new zmq identity for its dealer sockets. This means that any messages (acknowledgements, certain scheduling packets) that are addressed to the old zmq identity from before the client rebooted will never be sent. I *think* that means they will pile up unsent in the router socket. In order to avoid piled-up messages on a slow router, we use a very low HWM in most of our sockets - 1 by default. This seems like a single errant message could prevent a router from sending to any of its clients again until the socket was closed and reopened (which means rebooting the router for us right now). Is there a standard solution to this problem? I know ZMQ (intentionally) doesn't let you ask "how many messages are queued right now on this socket?". But that means that genuinely stale messages seem like they would be forever undetectable. Is there any way to "expire" messages after a given period of time? -- *Noah Gibbs* Software Engineer | [email protected] | (510) 260-5409 (cell) www.ooyala.com | blog <http://www.ooyala.com/blog> | @ooyala<http://www.twitter.com/ooyala>
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
