[zeromq-dev] Can we customize a behaviour for in-mem queued messages after reconnect?

[Gregg Irwin]

Hi Artem,

az> Real example from gambling.

az> We have thousands users betting from their phones.  For end user a bet is
az> just a click in UI, but for backend it's  a bunch of remote calls to
az> services. If  service is not available, then bet message  will stuck
az> in 0mq in-mem message queue  (up to hwm).   The game UI can wait up to
az> certain timeout  and then render something akin to  "We have communication
az> problem with our backend. Try again later."  So at this point user believes
az> that bet wasn't succeeded (.. this is important).    What happens then --
az> ITOps get their pager rings, and then during 1hr they do their best to
az>  restart a failed service.  Ok?

az> After 1hr or so service restarts  and now what? Now queued bet will be
az> delivered to restarted service. And this is not goood, because 1hr earlier
az>  we ensured user that "we had a backend issue"  and his bet wasn't suceeded.

az> So  the  question arised --  how to not redeliver messages upon reconnect?

This sounds like an application problem, not a 0MQ problem. A request
to place the bet can be received, which doesn't guarantee that the bet
has been placed (if other work needs to be done). To know that the bet
was place, you need an ack. You can also ack that the *request* was
received. In your scenario above, timestamping the messages and giving
them a TTL lets you handle cases where requests could not be processed
in a timely manner, and possibly ask the user what they want to do.

-- Gregg