If you are using temporary queues, I think you should first create the
receivers before sending the request. Otherwise, if the responder is fast
it might send the delivery_ack / response before you create the receivers.
I would probably also use the same address for both the delivery
acknowledgement and the response and place it into reply-to. That way the
address will be used only in the field where it belongs and not in a string
property.
Regards
Jakub
On Thu, Mar 31, 2016 at 4:33 PM, Flores, Paul A. <paul.a.flo...@saic.com>
wrote:
> This is the idealized flow as I see it. Any comments?
>
> The Requestor:
> Set up addresses in the request message for both:
> reply to ->(#response)
> delivery acknowledgement ->(#delivery_ack) a 'custom' message property
> that will need to be added
>
> Send the request ->send(request, true) ):
> after preliminary acknowledgement:
> create receiver for the delivery acknowledgement ->Receiver
> ack_receiver=session.createReceiver(delivery_ack)
> wait for delivery acknowledgement for a specified time
> ->ack_receiver.fetch(ack_message, delivery_ack_time_out)
> Once deliver acknowledgement message has been received:
> create receiver for the response ->Receiver
> response_receiver=session.createReceiver(response_queue)
> wait for the response for a specific time->
> response_receiver.fetch(response_message, response_time_out)
> Continue processing after the receipt of the response
>
> The Responder:
> After message receipt:
> If ‘reply to’ is not empty {
> if ‘delivery acknowledgement’ is not empty{
> create the delivery acknowledgement sender
> -> Sender ack_sender=session.createSender(delivery_ack)
> create a delivery acknowledgement message
> :Message ack_message; ack_message.message_content -> time stamp & message
> correlation id?
> send delivery acknowledgement message
> ->ack_sender.send(ack_message, true)
> }
> create a reply handler-> std::shared_ptr<qpid::messaging::Sender>
> responder= make_shared<Sender>(session.createSender(reply_to));
> }
> capture operation/method response and encode into a response message
> if reply handler is not null send the response message ->
> responder->send(response_msg,true)
>
> ________________________________________
> From: Jakub Scholz [ja...@scholz.cz]
> Sent: Wednesday, March 30, 2016 3:25 PM
> To: users@qpid.apache.org
> Subject: Re: Basic question : Is message delivery acknowledgement by
> message receipient possible/supported?
>
> 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.flo...@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
> >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>
