AnsweredAssumed Answered

Atom Queue - Publisher Subscriber Durability

Question asked by DavidTorre881 on Nov 23, 2015
Latest reply on Apr 6, 2016 by santosh.gunasekaran854179
Hello Boomi Community.

Hello. I'm trying to implement an enterprise service bus (ESB) function within Boomi using Atom Queues.

Reading this document: http://help.boomi.com/atomsphere/GUID-082DA7EF-435A-4A88-B65A-1C251251AD56.html it's my understanding that if I want to send data to multiple recipients, I would use a publisher/subscriber queue. I've tested this, and it works pretty well. That said, I'm having trouble with actual message queuing for durability / reliable delivery.

If a particular subscriber "goes away" altogether (e.g. the Boomi developer removes the Listener altogether) then obviously the Atom Queue shouldn't hold a message for a Listener that no longer exists. However, if there *is* in fact a Listener and a peice of the downstream process breaks, then shouldn't the Atom Queue hold the message?


Example topology:
0EM40000000IE3j
Imagine the top subscriber is an Atom Queue Listener pushing to Disk Connection. The second is also a Disk Connection, and the bottom is an HTTP Client pushing data to a REST endpoint.

If I "kill" the REST endpoint, the bottom subscriber "slurps" the message from the Start Shape (Atom Queue in Listen Operation) but when it flows down the shape path to the HTTP client, it barfs, and never "informs" the queue that delivery was unsuccesful. Thus, I never see any messages held in the queue. The Pub/Sub queue just assums everything was delivered succesfully.

Can someone tell me what I'm missing here? Shouldn't the queue hold a message that wasn't delivered end-to-end? Or does the queue just assume "all is well" once it goes past the start shape? (I don't see how the latter is useful without some complex try/catch logic that would probably re-inject messages into the queue, which every listern would get again and again.)
 

Outcomes