You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by "Flores, Paul A." <PA...@SAIC.COM> on 2016/03/30 22:04:21 UTC
Basic question : Is message delivery acknowledgement by message
receipient possible/supported?
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
Re: Basic question : Is message delivery acknowledgement by message
receipient possible/supported?
Posted by Jakub Scholz <ja...@scholz.cz>.
Yes, that is what I usually use.
On Thu, Mar 31, 2016 at 9:46 PM, Flores, Paul A. <PA...@saic.com>
wrote:
> Thanks for the inputs!
>
> In regards to a 'response' queue. I am making an assumption that they
> would be temporary and would be deleted when the receiver is closed, right?
>
> ________________________________________
> From: Jakub Scholz [jakub@scholz.cz]
> Sent: Thursday, March 31, 2016 1:43 PM
> To: users@qpid.apache.org
> Subject: Re: Basic question : Is message delivery acknowledgement by
> message receipient possible/supported?
>
> 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. <PA...@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 [jakub@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.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
> > >
> > >
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
RE: Basic question : Is message delivery acknowledgement by message
receipient possible/supported?
Posted by "Flores, Paul A." <PA...@SAIC.COM>.
Thanks for the inputs!
In regards to a 'response' queue. I am making an assumption that they would be temporary and would be deleted when the receiver is closed, right?
________________________________________
From: Jakub Scholz [jakub@scholz.cz]
Sent: Thursday, March 31, 2016 1:43 PM
To: users@qpid.apache.org
Subject: Re: Basic question : Is message delivery acknowledgement by message receipient possible/supported?
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. <PA...@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 [jakub@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. <PA...@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-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Basic question : Is message delivery acknowledgement by message
receipient possible/supported?
Posted by Jakub Scholz <ja...@scholz.cz>.
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. <PA...@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 [jakub@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. <PA...@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-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
RE: Basic question : Is message delivery acknowledgement by message
receipient possible/supported?
Posted by "Flores, Paul A." <PA...@SAIC.COM>.
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 [jakub@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. <PA...@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-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Basic question : Is message delivery acknowledgement by message
receipient possible/supported?
Posted by Jakub Scholz <ja...@scholz.cz>.
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. <PA...@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
>
>
>
>
>