On 09/16/2014 08:55 AM, Flavio Percoco wrote:
pub/sub doesn't necessarily guarantees messages delivery, it really
depends on the implementation.

As I understand it, the model for pub-sub in Zaqar is to have multiple subscribers polling the queue with gets, and have the messages removed from the queue only when they expire. Is that right?

If the ttl of the messages is long enough, a subscriber can start getting the queue from where they left off (if they have or can recover their last used marker) or from the head of the queue.

So although not acknowledged, subscribers can retry on failover providing they do so before the message expires.

That said, there are ways to guarantee
that depending on the method used. For example, if the subscriber is a
webhook, we can use the response status code to ack the message. if it
has a persistent connection like websocket or even (long|short)-poll an
ack may be needed.

In the pub-sub case, to remove a message based on acks you need to wait until all known subscribers have acked it. With the current model there is no explicit concept of subscriber (nor of ack in the non-competing consumer case). Without changing that I don't think you can use the response of a webhook anyway (unless of course there are not get style subscribers on the queue).

OpenStack-dev mailing list

Reply via email to