qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakub Scholz <ja...@scholz.cz>
Subject Re: Basic question : Is message delivery acknowledgement by message receipient possible/supported?
Date Wed, 30 Mar 2016 20:25:53 GMT
The acknowledgements are always only between the  requestor and the broker
and the broker and the responder. I think you have two options how to
implement what you want to have:
- Send the acknowledgement as a regular response to the request. I.e. the
responder receives the request and acknowledges it to the broker using the
AMQP protocol acknowledgement. But it also sends a regular response message
using reply-to with a "functional acknowledgement" - i.e. with some content
which simply says that the responder received the request. And only later
the requestor sends a second response with the actual response. I'm using
this sometimes in places where the request processing takes longer time,
but I want to tell the requestor that it will be processed.
- I guess another option might be to use the Dispatch router, which doesn't
take ownership of the messages and thus the acknowledgements are sent
directly between the requestor and responder. But that depends how much you
need the broker - to decouple the requestor and responder, to store the
requests if responder is not running etc.

Jakub

On Wed, Mar 30, 2016 at 10:04 PM, Flores, Paul A. <PAUL.A.FLORES@saic.com>
wrote:

> At client site.
>
>
>
> Is this possible?
>
>
>
> Producer: Requester  ---- Message: Reply to --> Broker: queue <----- Fetch
> Message --------- Consumer: Responder
>
>
>                         ----- Message ---------------->
>
>
>  <----------------------------------------<------- Delivery receipt
> Consumer: Responder
>
>                        Listen     ------------------------------> Broker:
> reply to
>
>                                <------Message------------
>    queue<-------- Message-------------  Consumer: Responder
>
>
>
> Client is curious id above 'anticipated flow' is possible.  Overall goal
> is to emulate synchronous processing.
>
>
>
> Thanks for your inputs/thought/feedback it is all welcomed.
>
>
>
> Paul Flores
>
>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message