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

artemv zmq artemv.zmq at gmail.com
Fri Dec 20 11:16:08 CET 2013


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 <artemv.zmq at gmail.com>

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131220/5d536416/attachment.htm>


More information about the zeromq-dev mailing list