Real example from gambling. We have thousands users betting from their phones. For end user a bet is just a click in UI, but for backend it's a bunch of remote calls to services. If service is not available, then bet message will stuck in 0mq in-mem message queue (up to hwm). The game UI can wait up to certain timeout and then render something akin to "We have communication problem with our backend. Try again later." So at this point user believes that bet wasn't succeeded (.. this is important). What happens then -- ITOps get their pager rings, and then during 1hr they do their best to restart a failed service. Ok?
After 1hr or so service restarts and now what? Now queued bet will be delivered to restarted service. And this is not goood, because 1hr earlier we ensured user that "we had a backend issue" and his bet wasn't suceeded. So the question arised -- how to not redeliver messages upon reconnect? 2013/12/20 artemv zmq <[email protected]> > Hello there, > > Is there a any option in 0mq which would allow to decide end client what > to do with queued messages (up to hwm) after reconnect succeeded? I > have a situation when re-delivering messages after communication is rather > harmful than useful. As my mind 0mq after reconnect succeeded -- just > delivers messages w/o asking original sender. > > I.e. if connection was lost, and 0mq recognized this event, then -- don't > resend messages in queue upon reconnect and simply clear message queue. > > So, two questions -- does it make sense for broad auditory (?), and is > this doable (?) . > > > Thank you in advance. >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
