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 _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
