You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by "Hudalla Kai (INST/ECS4)" <ka...@bosch-si.com> on 2018/05/24 11:53:06 UTC
Handling of undeliverable messages in Dispatch Router
Hi,
we are experiencing some unwanted/unexpected behavior when using message routing in Dispatch Router 1.0.1.
1. Receiver opens a receiver link on control/my-tenant/my-device
2. Sender opens a sender link on control/my-tenant/my-device
3. Sender gets credit from the router
4. Receiver closes its link with the router
5. Sender sends an unsettled message on its sender link
6. dispatch router does not accept nor reject the message, in fact, the sender does not get any disposition at all
7. As soon as the receiver opens a new link on the address, it gets the message
Is this the intended behavior? The Dispatch Router book states in section 4.2 [1]:
Address semantics include the following considerations:
* Routing pattern - direct, multicast, balanced
* Undeliverable action - drop, hold and retry, redirect
* Reliability - N destinations, etc.
In particular, the "undeliverable action" seems to be of importance here (the default seems to be "hold and retry"). Is this configurable? In our case it would be more desirable to have the router reject the message instead.
[1] https://qpid.apache.org/releases/qpid-dispatch-1.0.1/book/index.html#addressing
Mit freundlichen Grüßen / Best regards
Kai Hudalla
Chief Software Architect
Bosch Software Innovations GmbH
Ullsteinstraße 128
12109 Berlin
GERMANY
www.bosch-si.com
Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B;
Chairman of the Supervisory Board: Dr.-Ing. Thorsten Lücke; Managing Directors: Dr. Stefan Ferber, Michael Hahn
Re: Handling of undeliverable messages in Dispatch Router
Posted by Ted Ross <tr...@redhat.com>.
https://issues.apache.org/jira/browse/DISPATCH-1012
On Fri, May 25, 2018 at 8:20 AM, Hudalla Kai (INST/ECS4)
<ka...@bosch-si.com> wrote:
> I agree, releasing undeliverable messages sounds like the reasonable thing to do and would indeed solve our problem.
>
>
> @Ted: can you post the JIRA's URL so that we can track it?
>
> ________________________________
> From: Ted Ross <tr...@redhat.com>
> Sent: Thursday, May 24, 2018 5:59:32 PM
> To: users@qpid.apache.org
> Subject: Re: Handling of undeliverable messages in Dispatch Router
>
> I've given this a bit more thought and I think that the second option
> is the correct one. Philosophically, Qpid Dispatch Router is about
> minimizing the number of deliveries in flight. This reduces latency,
> reduces memory use, and increases aggregate capacity and scale.
>
> Releasing rather than holding undeliverable messages is more in-line
> with this philosophy. TTL should be implemented in brokers that hold
> messages in queues for extended periods of time.
>
> I'll raise a Jira for this.
>
> -Ted
>
> On Thu, May 24, 2018 at 7:56 AM, Ted Ross <tr...@redhat.com> wrote:
>> Hi Kai,
>>
>> What you describe is the current behavior of the router. When the
>> consumer detaches, the router does not revoke the credit already given
>> to the producer. There are two ways we can address this issue (I
>> agree that the current behavior is not optimal).
>>
>> We could implement time-to-live expiration so the delivery would be
>> rejected if it sits in the buffer longer than the specified TTL.
>>
>> Alternatively, we could release deliveries for which there is no
>> longer a valid destination. This leaves the "retry or not" decision
>> up to the producer.
>>
>> Thoughts?
>>
>> -Ted
>>
>> On Thu, May 24, 2018 at 4:53 AM, Hudalla Kai (INST/ECS4)
>> <ka...@bosch-si.com> wrote:
>>> Hi,
>>>
>>>
>>> we are experiencing some unwanted/unexpected behavior when using message routing in Dispatch Router 1.0.1.
>>>
>>>
>>> 1. Receiver opens a receiver link on control/my-tenant/my-device
>>> 2. Sender opens a sender link on control/my-tenant/my-device
>>> 3. Sender gets credit from the router
>>> 4. Receiver closes its link with the router
>>> 5. Sender sends an unsettled message on its sender link
>>> 6. dispatch router does not accept nor reject the message, in fact, the sender does not get any disposition at all
>>> 7. As soon as the receiver opens a new link on the address, it gets the message
>>>
>>> Is this the intended behavior? The Dispatch Router book states in section 4.2 [1]:
>>>
>>>
>>> Address semantics include the following considerations:
>>>
>>> * Routing pattern - direct, multicast, balanced
>>>
>>> * Undeliverable action - drop, hold and retry, redirect
>>>
>>> * Reliability - N destinations, etc.
>>>
>>> In particular, the "undeliverable action" seems to be of importance here (the default seems to be "hold and retry"). Is this configurable? In our case it would be more desirable to have the router reject the message instead.
>>>
>>>
>>> [1] https://qpid.apache.org/releases/qpid-dispatch-1.0.1/book/index.html#addressing
>>>
>>>
>>> Mit freundlichen Grüßen / Best regards
>>>
>>> Kai Hudalla
>>> Chief Software Architect
>>>
>>> Bosch Software Innovations GmbH
>>> Ullsteinstraße 128
>>> 12109 Berlin
>>> GERMANY
>>> www.bosch-si.com<http://www.bosch-si.com>
>>>
>>> Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B;
>>> Chairman of the Supervisory Board: Dr.-Ing. Thorsten Lücke; Managing Directors: Dr. Stefan Ferber, Michael Hahn
>
> ---------------------------------------------------------------------
> 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: Handling of undeliverable messages in Dispatch Router
Posted by "Hudalla Kai (INST/ECS4)" <ka...@bosch-si.com>.
I agree, releasing undeliverable messages sounds like the reasonable thing to do and would indeed solve our problem.
@Ted: can you post the JIRA's URL so that we can track it?
________________________________
From: Ted Ross <tr...@redhat.com>
Sent: Thursday, May 24, 2018 5:59:32 PM
To: users@qpid.apache.org
Subject: Re: Handling of undeliverable messages in Dispatch Router
I've given this a bit more thought and I think that the second option
is the correct one. Philosophically, Qpid Dispatch Router is about
minimizing the number of deliveries in flight. This reduces latency,
reduces memory use, and increases aggregate capacity and scale.
Releasing rather than holding undeliverable messages is more in-line
with this philosophy. TTL should be implemented in brokers that hold
messages in queues for extended periods of time.
I'll raise a Jira for this.
-Ted
On Thu, May 24, 2018 at 7:56 AM, Ted Ross <tr...@redhat.com> wrote:
> Hi Kai,
>
> What you describe is the current behavior of the router. When the
> consumer detaches, the router does not revoke the credit already given
> to the producer. There are two ways we can address this issue (I
> agree that the current behavior is not optimal).
>
> We could implement time-to-live expiration so the delivery would be
> rejected if it sits in the buffer longer than the specified TTL.
>
> Alternatively, we could release deliveries for which there is no
> longer a valid destination. This leaves the "retry or not" decision
> up to the producer.
>
> Thoughts?
>
> -Ted
>
> On Thu, May 24, 2018 at 4:53 AM, Hudalla Kai (INST/ECS4)
> <ka...@bosch-si.com> wrote:
>> Hi,
>>
>>
>> we are experiencing some unwanted/unexpected behavior when using message routing in Dispatch Router 1.0.1.
>>
>>
>> 1. Receiver opens a receiver link on control/my-tenant/my-device
>> 2. Sender opens a sender link on control/my-tenant/my-device
>> 3. Sender gets credit from the router
>> 4. Receiver closes its link with the router
>> 5. Sender sends an unsettled message on its sender link
>> 6. dispatch router does not accept nor reject the message, in fact, the sender does not get any disposition at all
>> 7. As soon as the receiver opens a new link on the address, it gets the message
>>
>> Is this the intended behavior? The Dispatch Router book states in section 4.2 [1]:
>>
>>
>> Address semantics include the following considerations:
>>
>> * Routing pattern - direct, multicast, balanced
>>
>> * Undeliverable action - drop, hold and retry, redirect
>>
>> * Reliability - N destinations, etc.
>>
>> In particular, the "undeliverable action" seems to be of importance here (the default seems to be "hold and retry"). Is this configurable? In our case it would be more desirable to have the router reject the message instead.
>>
>>
>> [1] https://qpid.apache.org/releases/qpid-dispatch-1.0.1/book/index.html#addressing
>>
>>
>> Mit freundlichen Grüßen / Best regards
>>
>> Kai Hudalla
>> Chief Software Architect
>>
>> Bosch Software Innovations GmbH
>> Ullsteinstraße 128
>> 12109 Berlin
>> GERMANY
>> www.bosch-si.com<http://www.bosch-si.com>
>>
>> Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B;
>> Chairman of the Supervisory Board: Dr.-Ing. Thorsten Lücke; Managing Directors: Dr. Stefan Ferber, Michael Hahn
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Handling of undeliverable messages in Dispatch Router
Posted by Ted Ross <tr...@redhat.com>.
For the record, I'm almost done with a patch for this issue. There
remains one problem with the accounting of dropped presettled
deliveries in two tests.
The approach I've taken with credit is to stop issuing replacement
credit when there are no destinations for delivery. For each delivery
dropped/released due to no-destination, credit will not be replenished
until there is an attached destination. Once a valid destination is
reachable, the credit will be restored such that the sender has
"capacity" credits to use.
-Ted
On Tue, May 29, 2018 at 8:47 AM, Rob Godfrey <ro...@gmail.com> wrote:
> On Tue, 29 May 2018 at 17:05, Robbie Gemmell <ro...@gmail.com>
> wrote:
>
>> I wasn't referering to the unsettled message maybe not being accepted,
>> but rather how the reciever side will react when they realise the
>> sender exceeded the reduced transfer limit (if they already sent
>> something with the revoked credit). The protocol allows either closing
>> the link with a transfer-limit-exceeded error or processing the
>> deliveries normally, and as a sender finding yourself in the position
>> you cant tell which will occur, though at the end of the day you need
>> to be ready for both in regular situations too like you said.
>
>
> Yeah - I don't think I consider that particular part as "uncertainty". As
> a sender all you can do is assume the receiver is going to process things
> normally, but handle abrupt link detachment (which you should always be
> able to do).
>
>
>> As a
>> receiver, the nicer (but more awkward) thing to do as the awkward peer
>> revoking credit would seem to be to process them. The only
>> implementation I've seen allow revoking went the
>> transfer-limit-exceeded route.
>>
>
> From a broker-like perspective I think it is entirely reasonable to suppose
> that you can revoke credit but should process incoming messages. As a
> broker-like entity you might want to normally allow more credit in total
> across all publishers than can actually be handled, but in low resource
> conditions revoke credit that appears unused. I would reserve abruptly
> detaching links solely for the case where you literally do not have the
> resources to process the message.
>
> -- Rob
>
>
>>
>> Robbie
>>
>> On 29 May 2018 at 15:52, Rob Godfrey <ro...@gmail.com> wrote:
>> > On Tue, 29 May 2018 at 15:15, Robbie Gemmell <ro...@gmail.com>
>> > wrote:
>> >
>> >> The only 'other solution' is one Chuck already mentioned, draining
>> >> (not revoking) the credit issued. In practice its typically the same
>> >> effect as trying to reset credit to 0, but without the
>> >> protocol-defined uncertainty resulting for the sender if theyve
>> >> already used some of the credit (since if they had something to send,
>> >> and credit to do so, they have probably already sent it).
>> >>
>> >
>> > I wouldn't say there is "protocol-defined uncertainty" at the sender. If
>> > the message has been sent, it has been sent. If the message was sent
>> > unsettled then you always have the risk that the receiver may decide not
>> to
>> > accept the message, the only question is whether the sender can glean
>> > enough information from the disposition given by the receiver to know
>> that
>> > it should attempt re-sending.
>> >
>> > -- Rob
>> >
>> >
>> >>
>> >> On 28 May 2018 at 17:23, Alan Conway <ac...@redhat.com> wrote:
>> >> > On Thu, May 24, 2018 at 1:59 PM, Ganesh Murthy <gm...@redhat.com>
>> >> wrote:
>> >> >
>> >> >> On Thu, May 24, 2018 at 1:48 PM, Chuck Rolke <cr...@redhat.com>
>> wrote:
>> >> >>
>> >> >> > Releasing the messages sounds like the better choice.
>> >> >> >
>> >> >> > It also would be nice if the router could revoke the sender's
>> credit
>> >> so
>> >> >> > that he could not send any more. This would create the same state
>> as
>> >> >> > when the sender attaches and there's no receiver available. Kind of
>> >> like
>> >> >> > a receiver-initiated drain.
>> >> >> >
>> >> >> > Or just stop re-issuing credit. Credit would dwindle as the sender
>> >> >> > sends until the sender credit runs out. This might be more reliable
>> >> >> > as it should work with all sender clients.
>> >> >> >
>> >> >>
>> >> >> Not re-issuing credit seems like the better option to me.
>> >> >>
>> >> >
>> >> > +1 - I've looked at revoking credit before. AMQP does allow it but we
>> >> don't
>> >> > test our clients for it and I'd be surprised if it actually worked.
>> >> > Proton-C models it as negative credit, which is surprising and wrong -
>> >> IMO
>> >> > to correctly handle revoked credit the client needs to keep a stack of
>> >> past
>> >> > credit history, pushing onto the stack each time it loses credit and
>> >> > popping when the consequences of that batch of "lost credit" have been
>> >> > worked out. The simple algorithm of a single credit number works
>> properly
>> >> > only if credit is never revoked. Proton's negative credit doesn't give
>> >> you
>> >> > enough info to handle in-flight messages except in simple cases, and a
>> >> > signed/unsigned conversion slip turns revoked credit into
>> near-infinite
>> >> > credit. Wahey!
>> >> >
>> >> > It's probably something we should address and test across the board
>> since
>> >> > it is a feature of AMQP, but we haven't needed it so far and I would
>> >> avoid
>> >> > it if there's another solution as even if we do put our house in order
>> >> > it'll be a backwards interop issue for a long time.
>> >> >
>> >> >
>> >> >> Overall, I also like the idea of releasing the messages. Keeping the
>> >> >> messages around increases the router's
>> >> >> memory footprint. The messages could stay forever in the sender's
>> >> >> undelivered FIFO if the sender does not disconnect
>> >> >> and a receiver never shows up.
>> >> >>
>> >> >> >
>> >> >> > ----- Original Message -----
>> >> >> > > From: "Ted Ross" <tr...@redhat.com>
>> >> >> > > To: users@qpid.apache.org
>> >> >> > > Sent: Thursday, May 24, 2018 11:59:32 AM
>> >> >> > > Subject: Re: Handling of undeliverable messages in Dispatch
>> Router
>> >> >> > >
>> >> >> > > I've given this a bit more thought and I think that the second
>> >> option
>> >> >> > > is the correct one. Philosophically, Qpid Dispatch Router is
>> about
>> >> >> > > minimizing the number of deliveries in flight. This reduces
>> >> latency,
>> >> >> > > reduces memory use, and increases aggregate capacity and scale.
>> >> >> > >
>> >> >> > > Releasing rather than holding undeliverable messages is more
>> in-line
>> >> >> > > with this philosophy. TTL should be implemented in brokers that
>> >> hold
>> >> >> > > messages in queues for extended periods of time.
>> >> >> > >
>> >> >> > > I'll raise a Jira for this.
>> >> >> > >
>> >> >> > > -Ted
>> >> >> > >
>> >> >> > > On Thu, May 24, 2018 at 7:56 AM, Ted Ross <tr...@redhat.com>
>> wrote:
>> >> >> > > > Hi Kai,
>> >> >> > > >
>> >> >> > > > What you describe is the current behavior of the router. When
>> the
>> >> >> > > > consumer detaches, the router does not revoke the credit
>> already
>> >> >> given
>> >> >> > > > to the producer. There are two ways we can address this issue
>> (I
>> >> >> > > > agree that the current behavior is not optimal).
>> >> >> > > >
>> >> >> > > > We could implement time-to-live expiration so the delivery
>> would
>> >> be
>> >> >> > > > rejected if it sits in the buffer longer than the specified
>> TTL.
>> >> >> > > >
>> >> >> > > > Alternatively, we could release deliveries for which there is
>> no
>> >> >> > > > longer a valid destination. This leaves the "retry or not"
>> >> decision
>> >> >> > > > up to the producer.
>> >> >> > > >
>> >> >> > > > Thoughts?
>> >> >> > > >
>> >> >> > > > -Ted
>> >> >> > > >
>> >> >> > > > On Thu, May 24, 2018 at 4:53 AM, Hudalla Kai (INST/ECS4)
>> >> >> > > > <ka...@bosch-si.com> wrote:
>> >> >> > > >> Hi,
>> >> >> > > >>
>> >> >> > > >>
>> >> >> > > >> we are experiencing some unwanted/unexpected behavior when
>> using
>> >> >> > message
>> >> >> > > >> routing in Dispatch Router 1.0.1.
>> >> >> > > >>
>> >> >> > > >>
>> >> >> > > >> 1. Receiver opens a receiver link on
>> >> control/my-tenant/my-device
>> >> >> > > >> 2. Sender opens a sender link on
>> control/my-tenant/my-device
>> >> >> > > >> 3. Sender gets credit from the router
>> >> >> > > >> 4. Receiver closes its link with the router
>> >> >> > > >> 5. Sender sends an unsettled message on its sender link
>> >> >> > > >> 6. dispatch router does not accept nor reject the message,
>> in
>> >> >> > fact, the
>> >> >> > > >> sender does not get any disposition at all
>> >> >> > > >> 7. As soon as the receiver opens a new link on the
>> address, it
>> >> >> > gets the
>> >> >> > > >> message
>> >> >> > > >>
>> >> >> > > >> Is this the intended behavior? The Dispatch Router book
>> states in
>> >> >> > section
>> >> >> > > >> 4.2 [1]:
>> >> >> > > >>
>> >> >> > > >>
>> >> >> > > >> Address semantics include the following considerations:
>> >> >> > > >>
>> >> >> > > >> * Routing pattern - direct, multicast, balanced
>> >> >> > > >>
>> >> >> > > >> * Undeliverable action - drop, hold and retry, redirect
>> >> >> > > >>
>> >> >> > > >> * Reliability - N destinations, etc.
>> >> >> > > >>
>> >> >> > > >> In particular, the "undeliverable action" seems to be of
>> >> importance
>> >> >> > here
>> >> >> > > >> (the default seems to be "hold and retry"). Is this
>> >> configurable? In
>> >> >> > our
>> >> >> > > >> case it would be more desirable to have the router reject the
>> >> >> message
>> >> >> > > >> instead.
>> >> >> > > >>
>> >> >> > > >>
>> >> >> > > >> [1]
>> >> >> > > >> https://qpid.apache.org/releases/qpid-dispatch-1.0.1/
>> >> >> > book/index.html#addressing
>> >> >> > > >>
>> >> >> > > >>
>> >> >> > > >> Mit freundlichen Grüßen / Best regards
>> >> >> > > >>
>> >> >> > > >> Kai Hudalla
>> >> >> > > >> Chief Software Architect
>> >> >> > > >>
>> >> >> > > >> Bosch Software Innovations GmbH
>> >> >> > > >> Ullsteinstraße 128
>> >> >> > > >> 12109 Berlin
>> >> >> > > >> GERMANY
>> >> >> > > >> www.bosch-si.com
>> >> >> > > >>
>> >> >> > > >> Registered office: Berlin, Register court: Amtsgericht
>> >> >> > Charlottenburg, HRB
>> >> >> > > >> 148411 B;
>> >> >> > > >> Chairman of the Supervisory Board: Dr.-Ing. Thorsten Lücke;
>> >> Managing
>> >> >> > > >> Directors: Dr. Stefan Ferber, Michael Hahn
>> >> >> > >
>> >> >> > >
>> >> ---------------------------------------------------------------------
>> >> >> > > 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
>> >> >> >
>> >> >> >
>> >> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> 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
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Handling of undeliverable messages in Dispatch Router
Posted by Rob Godfrey <ro...@gmail.com>.
On Tue, 29 May 2018 at 17:05, Robbie Gemmell <ro...@gmail.com>
wrote:
> I wasn't referering to the unsettled message maybe not being accepted,
> but rather how the reciever side will react when they realise the
> sender exceeded the reduced transfer limit (if they already sent
> something with the revoked credit). The protocol allows either closing
> the link with a transfer-limit-exceeded error or processing the
> deliveries normally, and as a sender finding yourself in the position
> you cant tell which will occur, though at the end of the day you need
> to be ready for both in regular situations too like you said.
Yeah - I don't think I consider that particular part as "uncertainty". As
a sender all you can do is assume the receiver is going to process things
normally, but handle abrupt link detachment (which you should always be
able to do).
> As a
> receiver, the nicer (but more awkward) thing to do as the awkward peer
> revoking credit would seem to be to process them. The only
> implementation I've seen allow revoking went the
> transfer-limit-exceeded route.
>
From a broker-like perspective I think it is entirely reasonable to suppose
that you can revoke credit but should process incoming messages. As a
broker-like entity you might want to normally allow more credit in total
across all publishers than can actually be handled, but in low resource
conditions revoke credit that appears unused. I would reserve abruptly
detaching links solely for the case where you literally do not have the
resources to process the message.
-- Rob
>
> Robbie
>
> On 29 May 2018 at 15:52, Rob Godfrey <ro...@gmail.com> wrote:
> > On Tue, 29 May 2018 at 15:15, Robbie Gemmell <ro...@gmail.com>
> > wrote:
> >
> >> The only 'other solution' is one Chuck already mentioned, draining
> >> (not revoking) the credit issued. In practice its typically the same
> >> effect as trying to reset credit to 0, but without the
> >> protocol-defined uncertainty resulting for the sender if theyve
> >> already used some of the credit (since if they had something to send,
> >> and credit to do so, they have probably already sent it).
> >>
> >
> > I wouldn't say there is "protocol-defined uncertainty" at the sender. If
> > the message has been sent, it has been sent. If the message was sent
> > unsettled then you always have the risk that the receiver may decide not
> to
> > accept the message, the only question is whether the sender can glean
> > enough information from the disposition given by the receiver to know
> that
> > it should attempt re-sending.
> >
> > -- Rob
> >
> >
> >>
> >> On 28 May 2018 at 17:23, Alan Conway <ac...@redhat.com> wrote:
> >> > On Thu, May 24, 2018 at 1:59 PM, Ganesh Murthy <gm...@redhat.com>
> >> wrote:
> >> >
> >> >> On Thu, May 24, 2018 at 1:48 PM, Chuck Rolke <cr...@redhat.com>
> wrote:
> >> >>
> >> >> > Releasing the messages sounds like the better choice.
> >> >> >
> >> >> > It also would be nice if the router could revoke the sender's
> credit
> >> so
> >> >> > that he could not send any more. This would create the same state
> as
> >> >> > when the sender attaches and there's no receiver available. Kind of
> >> like
> >> >> > a receiver-initiated drain.
> >> >> >
> >> >> > Or just stop re-issuing credit. Credit would dwindle as the sender
> >> >> > sends until the sender credit runs out. This might be more reliable
> >> >> > as it should work with all sender clients.
> >> >> >
> >> >>
> >> >> Not re-issuing credit seems like the better option to me.
> >> >>
> >> >
> >> > +1 - I've looked at revoking credit before. AMQP does allow it but we
> >> don't
> >> > test our clients for it and I'd be surprised if it actually worked.
> >> > Proton-C models it as negative credit, which is surprising and wrong -
> >> IMO
> >> > to correctly handle revoked credit the client needs to keep a stack of
> >> past
> >> > credit history, pushing onto the stack each time it loses credit and
> >> > popping when the consequences of that batch of "lost credit" have been
> >> > worked out. The simple algorithm of a single credit number works
> properly
> >> > only if credit is never revoked. Proton's negative credit doesn't give
> >> you
> >> > enough info to handle in-flight messages except in simple cases, and a
> >> > signed/unsigned conversion slip turns revoked credit into
> near-infinite
> >> > credit. Wahey!
> >> >
> >> > It's probably something we should address and test across the board
> since
> >> > it is a feature of AMQP, but we haven't needed it so far and I would
> >> avoid
> >> > it if there's another solution as even if we do put our house in order
> >> > it'll be a backwards interop issue for a long time.
> >> >
> >> >
> >> >> Overall, I also like the idea of releasing the messages. Keeping the
> >> >> messages around increases the router's
> >> >> memory footprint. The messages could stay forever in the sender's
> >> >> undelivered FIFO if the sender does not disconnect
> >> >> and a receiver never shows up.
> >> >>
> >> >> >
> >> >> > ----- Original Message -----
> >> >> > > From: "Ted Ross" <tr...@redhat.com>
> >> >> > > To: users@qpid.apache.org
> >> >> > > Sent: Thursday, May 24, 2018 11:59:32 AM
> >> >> > > Subject: Re: Handling of undeliverable messages in Dispatch
> Router
> >> >> > >
> >> >> > > I've given this a bit more thought and I think that the second
> >> option
> >> >> > > is the correct one. Philosophically, Qpid Dispatch Router is
> about
> >> >> > > minimizing the number of deliveries in flight. This reduces
> >> latency,
> >> >> > > reduces memory use, and increases aggregate capacity and scale.
> >> >> > >
> >> >> > > Releasing rather than holding undeliverable messages is more
> in-line
> >> >> > > with this philosophy. TTL should be implemented in brokers that
> >> hold
> >> >> > > messages in queues for extended periods of time.
> >> >> > >
> >> >> > > I'll raise a Jira for this.
> >> >> > >
> >> >> > > -Ted
> >> >> > >
> >> >> > > On Thu, May 24, 2018 at 7:56 AM, Ted Ross <tr...@redhat.com>
> wrote:
> >> >> > > > Hi Kai,
> >> >> > > >
> >> >> > > > What you describe is the current behavior of the router. When
> the
> >> >> > > > consumer detaches, the router does not revoke the credit
> already
> >> >> given
> >> >> > > > to the producer. There are two ways we can address this issue
> (I
> >> >> > > > agree that the current behavior is not optimal).
> >> >> > > >
> >> >> > > > We could implement time-to-live expiration so the delivery
> would
> >> be
> >> >> > > > rejected if it sits in the buffer longer than the specified
> TTL.
> >> >> > > >
> >> >> > > > Alternatively, we could release deliveries for which there is
> no
> >> >> > > > longer a valid destination. This leaves the "retry or not"
> >> decision
> >> >> > > > up to the producer.
> >> >> > > >
> >> >> > > > Thoughts?
> >> >> > > >
> >> >> > > > -Ted
> >> >> > > >
> >> >> > > > On Thu, May 24, 2018 at 4:53 AM, Hudalla Kai (INST/ECS4)
> >> >> > > > <ka...@bosch-si.com> wrote:
> >> >> > > >> Hi,
> >> >> > > >>
> >> >> > > >>
> >> >> > > >> we are experiencing some unwanted/unexpected behavior when
> using
> >> >> > message
> >> >> > > >> routing in Dispatch Router 1.0.1.
> >> >> > > >>
> >> >> > > >>
> >> >> > > >> 1. Receiver opens a receiver link on
> >> control/my-tenant/my-device
> >> >> > > >> 2. Sender opens a sender link on
> control/my-tenant/my-device
> >> >> > > >> 3. Sender gets credit from the router
> >> >> > > >> 4. Receiver closes its link with the router
> >> >> > > >> 5. Sender sends an unsettled message on its sender link
> >> >> > > >> 6. dispatch router does not accept nor reject the message,
> in
> >> >> > fact, the
> >> >> > > >> sender does not get any disposition at all
> >> >> > > >> 7. As soon as the receiver opens a new link on the
> address, it
> >> >> > gets the
> >> >> > > >> message
> >> >> > > >>
> >> >> > > >> Is this the intended behavior? The Dispatch Router book
> states in
> >> >> > section
> >> >> > > >> 4.2 [1]:
> >> >> > > >>
> >> >> > > >>
> >> >> > > >> Address semantics include the following considerations:
> >> >> > > >>
> >> >> > > >> * Routing pattern - direct, multicast, balanced
> >> >> > > >>
> >> >> > > >> * Undeliverable action - drop, hold and retry, redirect
> >> >> > > >>
> >> >> > > >> * Reliability - N destinations, etc.
> >> >> > > >>
> >> >> > > >> In particular, the "undeliverable action" seems to be of
> >> importance
> >> >> > here
> >> >> > > >> (the default seems to be "hold and retry"). Is this
> >> configurable? In
> >> >> > our
> >> >> > > >> case it would be more desirable to have the router reject the
> >> >> message
> >> >> > > >> instead.
> >> >> > > >>
> >> >> > > >>
> >> >> > > >> [1]
> >> >> > > >> https://qpid.apache.org/releases/qpid-dispatch-1.0.1/
> >> >> > book/index.html#addressing
> >> >> > > >>
> >> >> > > >>
> >> >> > > >> Mit freundlichen Grüßen / Best regards
> >> >> > > >>
> >> >> > > >> Kai Hudalla
> >> >> > > >> Chief Software Architect
> >> >> > > >>
> >> >> > > >> Bosch Software Innovations GmbH
> >> >> > > >> Ullsteinstraße 128
> >> >> > > >> 12109 Berlin
> >> >> > > >> GERMANY
> >> >> > > >> www.bosch-si.com
> >> >> > > >>
> >> >> > > >> Registered office: Berlin, Register court: Amtsgericht
> >> >> > Charlottenburg, HRB
> >> >> > > >> 148411 B;
> >> >> > > >> Chairman of the Supervisory Board: Dr.-Ing. Thorsten Lücke;
> >> Managing
> >> >> > > >> Directors: Dr. Stefan Ferber, Michael Hahn
> >> >> > >
> >> >> > >
> >> ---------------------------------------------------------------------
> >> >> > > 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
> >> >> >
> >> >> >
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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: Handling of undeliverable messages in Dispatch Router
Posted by Robbie Gemmell <ro...@gmail.com>.
I wasn't referering to the unsettled message maybe not being accepted,
but rather how the reciever side will react when they realise the
sender exceeded the reduced transfer limit (if they already sent
something with the revoked credit). The protocol allows either closing
the link with a transfer-limit-exceeded error or processing the
deliveries normally, and as a sender finding yourself in the position
you cant tell which will occur, though at the end of the day you need
to be ready for both in regular situations too like you said. As a
receiver, the nicer (but more awkward) thing to do as the awkward peer
revoking credit would seem to be to process them. The only
implementation I've seen allow revoking went the
transfer-limit-exceeded route.
Robbie
On 29 May 2018 at 15:52, Rob Godfrey <ro...@gmail.com> wrote:
> On Tue, 29 May 2018 at 15:15, Robbie Gemmell <ro...@gmail.com>
> wrote:
>
>> The only 'other solution' is one Chuck already mentioned, draining
>> (not revoking) the credit issued. In practice its typically the same
>> effect as trying to reset credit to 0, but without the
>> protocol-defined uncertainty resulting for the sender if theyve
>> already used some of the credit (since if they had something to send,
>> and credit to do so, they have probably already sent it).
>>
>
> I wouldn't say there is "protocol-defined uncertainty" at the sender. If
> the message has been sent, it has been sent. If the message was sent
> unsettled then you always have the risk that the receiver may decide not to
> accept the message, the only question is whether the sender can glean
> enough information from the disposition given by the receiver to know that
> it should attempt re-sending.
>
> -- Rob
>
>
>>
>> On 28 May 2018 at 17:23, Alan Conway <ac...@redhat.com> wrote:
>> > On Thu, May 24, 2018 at 1:59 PM, Ganesh Murthy <gm...@redhat.com>
>> wrote:
>> >
>> >> On Thu, May 24, 2018 at 1:48 PM, Chuck Rolke <cr...@redhat.com> wrote:
>> >>
>> >> > Releasing the messages sounds like the better choice.
>> >> >
>> >> > It also would be nice if the router could revoke the sender's credit
>> so
>> >> > that he could not send any more. This would create the same state as
>> >> > when the sender attaches and there's no receiver available. Kind of
>> like
>> >> > a receiver-initiated drain.
>> >> >
>> >> > Or just stop re-issuing credit. Credit would dwindle as the sender
>> >> > sends until the sender credit runs out. This might be more reliable
>> >> > as it should work with all sender clients.
>> >> >
>> >>
>> >> Not re-issuing credit seems like the better option to me.
>> >>
>> >
>> > +1 - I've looked at revoking credit before. AMQP does allow it but we
>> don't
>> > test our clients for it and I'd be surprised if it actually worked.
>> > Proton-C models it as negative credit, which is surprising and wrong -
>> IMO
>> > to correctly handle revoked credit the client needs to keep a stack of
>> past
>> > credit history, pushing onto the stack each time it loses credit and
>> > popping when the consequences of that batch of "lost credit" have been
>> > worked out. The simple algorithm of a single credit number works properly
>> > only if credit is never revoked. Proton's negative credit doesn't give
>> you
>> > enough info to handle in-flight messages except in simple cases, and a
>> > signed/unsigned conversion slip turns revoked credit into near-infinite
>> > credit. Wahey!
>> >
>> > It's probably something we should address and test across the board since
>> > it is a feature of AMQP, but we haven't needed it so far and I would
>> avoid
>> > it if there's another solution as even if we do put our house in order
>> > it'll be a backwards interop issue for a long time.
>> >
>> >
>> >> Overall, I also like the idea of releasing the messages. Keeping the
>> >> messages around increases the router's
>> >> memory footprint. The messages could stay forever in the sender's
>> >> undelivered FIFO if the sender does not disconnect
>> >> and a receiver never shows up.
>> >>
>> >> >
>> >> > ----- Original Message -----
>> >> > > From: "Ted Ross" <tr...@redhat.com>
>> >> > > To: users@qpid.apache.org
>> >> > > Sent: Thursday, May 24, 2018 11:59:32 AM
>> >> > > Subject: Re: Handling of undeliverable messages in Dispatch Router
>> >> > >
>> >> > > I've given this a bit more thought and I think that the second
>> option
>> >> > > is the correct one. Philosophically, Qpid Dispatch Router is about
>> >> > > minimizing the number of deliveries in flight. This reduces
>> latency,
>> >> > > reduces memory use, and increases aggregate capacity and scale.
>> >> > >
>> >> > > Releasing rather than holding undeliverable messages is more in-line
>> >> > > with this philosophy. TTL should be implemented in brokers that
>> hold
>> >> > > messages in queues for extended periods of time.
>> >> > >
>> >> > > I'll raise a Jira for this.
>> >> > >
>> >> > > -Ted
>> >> > >
>> >> > > On Thu, May 24, 2018 at 7:56 AM, Ted Ross <tr...@redhat.com> wrote:
>> >> > > > Hi Kai,
>> >> > > >
>> >> > > > What you describe is the current behavior of the router. When the
>> >> > > > consumer detaches, the router does not revoke the credit already
>> >> given
>> >> > > > to the producer. There are two ways we can address this issue (I
>> >> > > > agree that the current behavior is not optimal).
>> >> > > >
>> >> > > > We could implement time-to-live expiration so the delivery would
>> be
>> >> > > > rejected if it sits in the buffer longer than the specified TTL.
>> >> > > >
>> >> > > > Alternatively, we could release deliveries for which there is no
>> >> > > > longer a valid destination. This leaves the "retry or not"
>> decision
>> >> > > > up to the producer.
>> >> > > >
>> >> > > > Thoughts?
>> >> > > >
>> >> > > > -Ted
>> >> > > >
>> >> > > > On Thu, May 24, 2018 at 4:53 AM, Hudalla Kai (INST/ECS4)
>> >> > > > <ka...@bosch-si.com> wrote:
>> >> > > >> Hi,
>> >> > > >>
>> >> > > >>
>> >> > > >> we are experiencing some unwanted/unexpected behavior when using
>> >> > message
>> >> > > >> routing in Dispatch Router 1.0.1.
>> >> > > >>
>> >> > > >>
>> >> > > >> 1. Receiver opens a receiver link on
>> control/my-tenant/my-device
>> >> > > >> 2. Sender opens a sender link on control/my-tenant/my-device
>> >> > > >> 3. Sender gets credit from the router
>> >> > > >> 4. Receiver closes its link with the router
>> >> > > >> 5. Sender sends an unsettled message on its sender link
>> >> > > >> 6. dispatch router does not accept nor reject the message, in
>> >> > fact, the
>> >> > > >> sender does not get any disposition at all
>> >> > > >> 7. As soon as the receiver opens a new link on the address, it
>> >> > gets the
>> >> > > >> message
>> >> > > >>
>> >> > > >> Is this the intended behavior? The Dispatch Router book states in
>> >> > section
>> >> > > >> 4.2 [1]:
>> >> > > >>
>> >> > > >>
>> >> > > >> Address semantics include the following considerations:
>> >> > > >>
>> >> > > >> * Routing pattern - direct, multicast, balanced
>> >> > > >>
>> >> > > >> * Undeliverable action - drop, hold and retry, redirect
>> >> > > >>
>> >> > > >> * Reliability - N destinations, etc.
>> >> > > >>
>> >> > > >> In particular, the "undeliverable action" seems to be of
>> importance
>> >> > here
>> >> > > >> (the default seems to be "hold and retry"). Is this
>> configurable? In
>> >> > our
>> >> > > >> case it would be more desirable to have the router reject the
>> >> message
>> >> > > >> instead.
>> >> > > >>
>> >> > > >>
>> >> > > >> [1]
>> >> > > >> https://qpid.apache.org/releases/qpid-dispatch-1.0.1/
>> >> > book/index.html#addressing
>> >> > > >>
>> >> > > >>
>> >> > > >> Mit freundlichen Grüßen / Best regards
>> >> > > >>
>> >> > > >> Kai Hudalla
>> >> > > >> Chief Software Architect
>> >> > > >>
>> >> > > >> Bosch Software Innovations GmbH
>> >> > > >> Ullsteinstraße 128
>> >> > > >> 12109 Berlin
>> >> > > >> GERMANY
>> >> > > >> www.bosch-si.com
>> >> > > >>
>> >> > > >> Registered office: Berlin, Register court: Amtsgericht
>> >> > Charlottenburg, HRB
>> >> > > >> 148411 B;
>> >> > > >> Chairman of the Supervisory Board: Dr.-Ing. Thorsten Lücke;
>> Managing
>> >> > > >> Directors: Dr. Stefan Ferber, Michael Hahn
>> >> > >
>> >> > >
>> ---------------------------------------------------------------------
>> >> > > 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
>> >> >
>> >> >
>> >>
>>
>> ---------------------------------------------------------------------
>> 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: Handling of undeliverable messages in Dispatch Router
Posted by Rob Godfrey <ro...@gmail.com>.
On Tue, 29 May 2018 at 15:15, Robbie Gemmell <ro...@gmail.com>
wrote:
> The only 'other solution' is one Chuck already mentioned, draining
> (not revoking) the credit issued. In practice its typically the same
> effect as trying to reset credit to 0, but without the
> protocol-defined uncertainty resulting for the sender if theyve
> already used some of the credit (since if they had something to send,
> and credit to do so, they have probably already sent it).
>
I wouldn't say there is "protocol-defined uncertainty" at the sender. If
the message has been sent, it has been sent. If the message was sent
unsettled then you always have the risk that the receiver may decide not to
accept the message, the only question is whether the sender can glean
enough information from the disposition given by the receiver to know that
it should attempt re-sending.
-- Rob
>
> On 28 May 2018 at 17:23, Alan Conway <ac...@redhat.com> wrote:
> > On Thu, May 24, 2018 at 1:59 PM, Ganesh Murthy <gm...@redhat.com>
> wrote:
> >
> >> On Thu, May 24, 2018 at 1:48 PM, Chuck Rolke <cr...@redhat.com> wrote:
> >>
> >> > Releasing the messages sounds like the better choice.
> >> >
> >> > It also would be nice if the router could revoke the sender's credit
> so
> >> > that he could not send any more. This would create the same state as
> >> > when the sender attaches and there's no receiver available. Kind of
> like
> >> > a receiver-initiated drain.
> >> >
> >> > Or just stop re-issuing credit. Credit would dwindle as the sender
> >> > sends until the sender credit runs out. This might be more reliable
> >> > as it should work with all sender clients.
> >> >
> >>
> >> Not re-issuing credit seems like the better option to me.
> >>
> >
> > +1 - I've looked at revoking credit before. AMQP does allow it but we
> don't
> > test our clients for it and I'd be surprised if it actually worked.
> > Proton-C models it as negative credit, which is surprising and wrong -
> IMO
> > to correctly handle revoked credit the client needs to keep a stack of
> past
> > credit history, pushing onto the stack each time it loses credit and
> > popping when the consequences of that batch of "lost credit" have been
> > worked out. The simple algorithm of a single credit number works properly
> > only if credit is never revoked. Proton's negative credit doesn't give
> you
> > enough info to handle in-flight messages except in simple cases, and a
> > signed/unsigned conversion slip turns revoked credit into near-infinite
> > credit. Wahey!
> >
> > It's probably something we should address and test across the board since
> > it is a feature of AMQP, but we haven't needed it so far and I would
> avoid
> > it if there's another solution as even if we do put our house in order
> > it'll be a backwards interop issue for a long time.
> >
> >
> >> Overall, I also like the idea of releasing the messages. Keeping the
> >> messages around increases the router's
> >> memory footprint. The messages could stay forever in the sender's
> >> undelivered FIFO if the sender does not disconnect
> >> and a receiver never shows up.
> >>
> >> >
> >> > ----- Original Message -----
> >> > > From: "Ted Ross" <tr...@redhat.com>
> >> > > To: users@qpid.apache.org
> >> > > Sent: Thursday, May 24, 2018 11:59:32 AM
> >> > > Subject: Re: Handling of undeliverable messages in Dispatch Router
> >> > >
> >> > > I've given this a bit more thought and I think that the second
> option
> >> > > is the correct one. Philosophically, Qpid Dispatch Router is about
> >> > > minimizing the number of deliveries in flight. This reduces
> latency,
> >> > > reduces memory use, and increases aggregate capacity and scale.
> >> > >
> >> > > Releasing rather than holding undeliverable messages is more in-line
> >> > > with this philosophy. TTL should be implemented in brokers that
> hold
> >> > > messages in queues for extended periods of time.
> >> > >
> >> > > I'll raise a Jira for this.
> >> > >
> >> > > -Ted
> >> > >
> >> > > On Thu, May 24, 2018 at 7:56 AM, Ted Ross <tr...@redhat.com> wrote:
> >> > > > Hi Kai,
> >> > > >
> >> > > > What you describe is the current behavior of the router. When the
> >> > > > consumer detaches, the router does not revoke the credit already
> >> given
> >> > > > to the producer. There are two ways we can address this issue (I
> >> > > > agree that the current behavior is not optimal).
> >> > > >
> >> > > > We could implement time-to-live expiration so the delivery would
> be
> >> > > > rejected if it sits in the buffer longer than the specified TTL.
> >> > > >
> >> > > > Alternatively, we could release deliveries for which there is no
> >> > > > longer a valid destination. This leaves the "retry or not"
> decision
> >> > > > up to the producer.
> >> > > >
> >> > > > Thoughts?
> >> > > >
> >> > > > -Ted
> >> > > >
> >> > > > On Thu, May 24, 2018 at 4:53 AM, Hudalla Kai (INST/ECS4)
> >> > > > <ka...@bosch-si.com> wrote:
> >> > > >> Hi,
> >> > > >>
> >> > > >>
> >> > > >> we are experiencing some unwanted/unexpected behavior when using
> >> > message
> >> > > >> routing in Dispatch Router 1.0.1.
> >> > > >>
> >> > > >>
> >> > > >> 1. Receiver opens a receiver link on
> control/my-tenant/my-device
> >> > > >> 2. Sender opens a sender link on control/my-tenant/my-device
> >> > > >> 3. Sender gets credit from the router
> >> > > >> 4. Receiver closes its link with the router
> >> > > >> 5. Sender sends an unsettled message on its sender link
> >> > > >> 6. dispatch router does not accept nor reject the message, in
> >> > fact, the
> >> > > >> sender does not get any disposition at all
> >> > > >> 7. As soon as the receiver opens a new link on the address, it
> >> > gets the
> >> > > >> message
> >> > > >>
> >> > > >> Is this the intended behavior? The Dispatch Router book states in
> >> > section
> >> > > >> 4.2 [1]:
> >> > > >>
> >> > > >>
> >> > > >> Address semantics include the following considerations:
> >> > > >>
> >> > > >> * Routing pattern - direct, multicast, balanced
> >> > > >>
> >> > > >> * Undeliverable action - drop, hold and retry, redirect
> >> > > >>
> >> > > >> * Reliability - N destinations, etc.
> >> > > >>
> >> > > >> In particular, the "undeliverable action" seems to be of
> importance
> >> > here
> >> > > >> (the default seems to be "hold and retry"). Is this
> configurable? In
> >> > our
> >> > > >> case it would be more desirable to have the router reject the
> >> message
> >> > > >> instead.
> >> > > >>
> >> > > >>
> >> > > >> [1]
> >> > > >> https://qpid.apache.org/releases/qpid-dispatch-1.0.1/
> >> > book/index.html#addressing
> >> > > >>
> >> > > >>
> >> > > >> Mit freundlichen Grüßen / Best regards
> >> > > >>
> >> > > >> Kai Hudalla
> >> > > >> Chief Software Architect
> >> > > >>
> >> > > >> Bosch Software Innovations GmbH
> >> > > >> Ullsteinstraße 128
> >> > > >> 12109 Berlin
> >> > > >> GERMANY
> >> > > >> www.bosch-si.com
> >> > > >>
> >> > > >> Registered office: Berlin, Register court: Amtsgericht
> >> > Charlottenburg, HRB
> >> > > >> 148411 B;
> >> > > >> Chairman of the Supervisory Board: Dr.-Ing. Thorsten Lücke;
> Managing
> >> > > >> Directors: Dr. Stefan Ferber, Michael Hahn
> >> > >
> >> > >
> ---------------------------------------------------------------------
> >> > > 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
> >> >
> >> >
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Handling of undeliverable messages in Dispatch Router
Posted by Robbie Gemmell <ro...@gmail.com>.
The only 'other solution' is one Chuck already mentioned, draining
(not revoking) the credit issued. In practice its typically the same
effect as trying to reset credit to 0, but without the
protocol-defined uncertainty resulting for the sender if theyve
already used some of the credit (since if they had something to send,
and credit to do so, they have probably already sent it).
On 28 May 2018 at 17:23, Alan Conway <ac...@redhat.com> wrote:
> On Thu, May 24, 2018 at 1:59 PM, Ganesh Murthy <gm...@redhat.com> wrote:
>
>> On Thu, May 24, 2018 at 1:48 PM, Chuck Rolke <cr...@redhat.com> wrote:
>>
>> > Releasing the messages sounds like the better choice.
>> >
>> > It also would be nice if the router could revoke the sender's credit so
>> > that he could not send any more. This would create the same state as
>> > when the sender attaches and there's no receiver available. Kind of like
>> > a receiver-initiated drain.
>> >
>> > Or just stop re-issuing credit. Credit would dwindle as the sender
>> > sends until the sender credit runs out. This might be more reliable
>> > as it should work with all sender clients.
>> >
>>
>> Not re-issuing credit seems like the better option to me.
>>
>
> +1 - I've looked at revoking credit before. AMQP does allow it but we don't
> test our clients for it and I'd be surprised if it actually worked.
> Proton-C models it as negative credit, which is surprising and wrong - IMO
> to correctly handle revoked credit the client needs to keep a stack of past
> credit history, pushing onto the stack each time it loses credit and
> popping when the consequences of that batch of "lost credit" have been
> worked out. The simple algorithm of a single credit number works properly
> only if credit is never revoked. Proton's negative credit doesn't give you
> enough info to handle in-flight messages except in simple cases, and a
> signed/unsigned conversion slip turns revoked credit into near-infinite
> credit. Wahey!
>
> It's probably something we should address and test across the board since
> it is a feature of AMQP, but we haven't needed it so far and I would avoid
> it if there's another solution as even if we do put our house in order
> it'll be a backwards interop issue for a long time.
>
>
>> Overall, I also like the idea of releasing the messages. Keeping the
>> messages around increases the router's
>> memory footprint. The messages could stay forever in the sender's
>> undelivered FIFO if the sender does not disconnect
>> and a receiver never shows up.
>>
>> >
>> > ----- Original Message -----
>> > > From: "Ted Ross" <tr...@redhat.com>
>> > > To: users@qpid.apache.org
>> > > Sent: Thursday, May 24, 2018 11:59:32 AM
>> > > Subject: Re: Handling of undeliverable messages in Dispatch Router
>> > >
>> > > I've given this a bit more thought and I think that the second option
>> > > is the correct one. Philosophically, Qpid Dispatch Router is about
>> > > minimizing the number of deliveries in flight. This reduces latency,
>> > > reduces memory use, and increases aggregate capacity and scale.
>> > >
>> > > Releasing rather than holding undeliverable messages is more in-line
>> > > with this philosophy. TTL should be implemented in brokers that hold
>> > > messages in queues for extended periods of time.
>> > >
>> > > I'll raise a Jira for this.
>> > >
>> > > -Ted
>> > >
>> > > On Thu, May 24, 2018 at 7:56 AM, Ted Ross <tr...@redhat.com> wrote:
>> > > > Hi Kai,
>> > > >
>> > > > What you describe is the current behavior of the router. When the
>> > > > consumer detaches, the router does not revoke the credit already
>> given
>> > > > to the producer. There are two ways we can address this issue (I
>> > > > agree that the current behavior is not optimal).
>> > > >
>> > > > We could implement time-to-live expiration so the delivery would be
>> > > > rejected if it sits in the buffer longer than the specified TTL.
>> > > >
>> > > > Alternatively, we could release deliveries for which there is no
>> > > > longer a valid destination. This leaves the "retry or not" decision
>> > > > up to the producer.
>> > > >
>> > > > Thoughts?
>> > > >
>> > > > -Ted
>> > > >
>> > > > On Thu, May 24, 2018 at 4:53 AM, Hudalla Kai (INST/ECS4)
>> > > > <ka...@bosch-si.com> wrote:
>> > > >> Hi,
>> > > >>
>> > > >>
>> > > >> we are experiencing some unwanted/unexpected behavior when using
>> > message
>> > > >> routing in Dispatch Router 1.0.1.
>> > > >>
>> > > >>
>> > > >> 1. Receiver opens a receiver link on control/my-tenant/my-device
>> > > >> 2. Sender opens a sender link on control/my-tenant/my-device
>> > > >> 3. Sender gets credit from the router
>> > > >> 4. Receiver closes its link with the router
>> > > >> 5. Sender sends an unsettled message on its sender link
>> > > >> 6. dispatch router does not accept nor reject the message, in
>> > fact, the
>> > > >> sender does not get any disposition at all
>> > > >> 7. As soon as the receiver opens a new link on the address, it
>> > gets the
>> > > >> message
>> > > >>
>> > > >> Is this the intended behavior? The Dispatch Router book states in
>> > section
>> > > >> 4.2 [1]:
>> > > >>
>> > > >>
>> > > >> Address semantics include the following considerations:
>> > > >>
>> > > >> * Routing pattern - direct, multicast, balanced
>> > > >>
>> > > >> * Undeliverable action - drop, hold and retry, redirect
>> > > >>
>> > > >> * Reliability - N destinations, etc.
>> > > >>
>> > > >> In particular, the "undeliverable action" seems to be of importance
>> > here
>> > > >> (the default seems to be "hold and retry"). Is this configurable? In
>> > our
>> > > >> case it would be more desirable to have the router reject the
>> message
>> > > >> instead.
>> > > >>
>> > > >>
>> > > >> [1]
>> > > >> https://qpid.apache.org/releases/qpid-dispatch-1.0.1/
>> > book/index.html#addressing
>> > > >>
>> > > >>
>> > > >> Mit freundlichen Grüßen / Best regards
>> > > >>
>> > > >> Kai Hudalla
>> > > >> Chief Software Architect
>> > > >>
>> > > >> Bosch Software Innovations GmbH
>> > > >> Ullsteinstraße 128
>> > > >> 12109 Berlin
>> > > >> GERMANY
>> > > >> www.bosch-si.com
>> > > >>
>> > > >> Registered office: Berlin, Register court: Amtsgericht
>> > Charlottenburg, HRB
>> > > >> 148411 B;
>> > > >> Chairman of the Supervisory Board: Dr.-Ing. Thorsten Lücke; Managing
>> > > >> Directors: Dr. Stefan Ferber, Michael Hahn
>> > >
>> > > ---------------------------------------------------------------------
>> > > 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
>> >
>> >
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Handling of undeliverable messages in Dispatch Router
Posted by Alan Conway <ac...@redhat.com>.
On Thu, May 24, 2018 at 1:59 PM, Ganesh Murthy <gm...@redhat.com> wrote:
> On Thu, May 24, 2018 at 1:48 PM, Chuck Rolke <cr...@redhat.com> wrote:
>
> > Releasing the messages sounds like the better choice.
> >
> > It also would be nice if the router could revoke the sender's credit so
> > that he could not send any more. This would create the same state as
> > when the sender attaches and there's no receiver available. Kind of like
> > a receiver-initiated drain.
> >
> > Or just stop re-issuing credit. Credit would dwindle as the sender
> > sends until the sender credit runs out. This might be more reliable
> > as it should work with all sender clients.
> >
>
> Not re-issuing credit seems like the better option to me.
>
+1 - I've looked at revoking credit before. AMQP does allow it but we don't
test our clients for it and I'd be surprised if it actually worked.
Proton-C models it as negative credit, which is surprising and wrong - IMO
to correctly handle revoked credit the client needs to keep a stack of past
credit history, pushing onto the stack each time it loses credit and
popping when the consequences of that batch of "lost credit" have been
worked out. The simple algorithm of a single credit number works properly
only if credit is never revoked. Proton's negative credit doesn't give you
enough info to handle in-flight messages except in simple cases, and a
signed/unsigned conversion slip turns revoked credit into near-infinite
credit. Wahey!
It's probably something we should address and test across the board since
it is a feature of AMQP, but we haven't needed it so far and I would avoid
it if there's another solution as even if we do put our house in order
it'll be a backwards interop issue for a long time.
> Overall, I also like the idea of releasing the messages. Keeping the
> messages around increases the router's
> memory footprint. The messages could stay forever in the sender's
> undelivered FIFO if the sender does not disconnect
> and a receiver never shows up.
>
> >
> > ----- Original Message -----
> > > From: "Ted Ross" <tr...@redhat.com>
> > > To: users@qpid.apache.org
> > > Sent: Thursday, May 24, 2018 11:59:32 AM
> > > Subject: Re: Handling of undeliverable messages in Dispatch Router
> > >
> > > I've given this a bit more thought and I think that the second option
> > > is the correct one. Philosophically, Qpid Dispatch Router is about
> > > minimizing the number of deliveries in flight. This reduces latency,
> > > reduces memory use, and increases aggregate capacity and scale.
> > >
> > > Releasing rather than holding undeliverable messages is more in-line
> > > with this philosophy. TTL should be implemented in brokers that hold
> > > messages in queues for extended periods of time.
> > >
> > > I'll raise a Jira for this.
> > >
> > > -Ted
> > >
> > > On Thu, May 24, 2018 at 7:56 AM, Ted Ross <tr...@redhat.com> wrote:
> > > > Hi Kai,
> > > >
> > > > What you describe is the current behavior of the router. When the
> > > > consumer detaches, the router does not revoke the credit already
> given
> > > > to the producer. There are two ways we can address this issue (I
> > > > agree that the current behavior is not optimal).
> > > >
> > > > We could implement time-to-live expiration so the delivery would be
> > > > rejected if it sits in the buffer longer than the specified TTL.
> > > >
> > > > Alternatively, we could release deliveries for which there is no
> > > > longer a valid destination. This leaves the "retry or not" decision
> > > > up to the producer.
> > > >
> > > > Thoughts?
> > > >
> > > > -Ted
> > > >
> > > > On Thu, May 24, 2018 at 4:53 AM, Hudalla Kai (INST/ECS4)
> > > > <ka...@bosch-si.com> wrote:
> > > >> Hi,
> > > >>
> > > >>
> > > >> we are experiencing some unwanted/unexpected behavior when using
> > message
> > > >> routing in Dispatch Router 1.0.1.
> > > >>
> > > >>
> > > >> 1. Receiver opens a receiver link on control/my-tenant/my-device
> > > >> 2. Sender opens a sender link on control/my-tenant/my-device
> > > >> 3. Sender gets credit from the router
> > > >> 4. Receiver closes its link with the router
> > > >> 5. Sender sends an unsettled message on its sender link
> > > >> 6. dispatch router does not accept nor reject the message, in
> > fact, the
> > > >> sender does not get any disposition at all
> > > >> 7. As soon as the receiver opens a new link on the address, it
> > gets the
> > > >> message
> > > >>
> > > >> Is this the intended behavior? The Dispatch Router book states in
> > section
> > > >> 4.2 [1]:
> > > >>
> > > >>
> > > >> Address semantics include the following considerations:
> > > >>
> > > >> * Routing pattern - direct, multicast, balanced
> > > >>
> > > >> * Undeliverable action - drop, hold and retry, redirect
> > > >>
> > > >> * Reliability - N destinations, etc.
> > > >>
> > > >> In particular, the "undeliverable action" seems to be of importance
> > here
> > > >> (the default seems to be "hold and retry"). Is this configurable? In
> > our
> > > >> case it would be more desirable to have the router reject the
> message
> > > >> instead.
> > > >>
> > > >>
> > > >> [1]
> > > >> https://qpid.apache.org/releases/qpid-dispatch-1.0.1/
> > book/index.html#addressing
> > > >>
> > > >>
> > > >> Mit freundlichen Grüßen / Best regards
> > > >>
> > > >> Kai Hudalla
> > > >> Chief Software Architect
> > > >>
> > > >> Bosch Software Innovations GmbH
> > > >> Ullsteinstraße 128
> > > >> 12109 Berlin
> > > >> GERMANY
> > > >> www.bosch-si.com
> > > >>
> > > >> Registered office: Berlin, Register court: Amtsgericht
> > Charlottenburg, HRB
> > > >> 148411 B;
> > > >> Chairman of the Supervisory Board: Dr.-Ing. Thorsten Lücke; Managing
> > > >> Directors: Dr. Stefan Ferber, Michael Hahn
> > >
> > > ---------------------------------------------------------------------
> > > 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: Handling of undeliverable messages in Dispatch Router
Posted by Ganesh Murthy <gm...@redhat.com>.
On Thu, May 24, 2018 at 1:48 PM, Chuck Rolke <cr...@redhat.com> wrote:
> Releasing the messages sounds like the better choice.
>
> It also would be nice if the router could revoke the sender's credit so
> that he could not send any more. This would create the same state as
> when the sender attaches and there's no receiver available. Kind of like
> a receiver-initiated drain.
>
> Or just stop re-issuing credit. Credit would dwindle as the sender
> sends until the sender credit runs out. This might be more reliable
> as it should work with all sender clients.
>
Not re-issuing credit seems like the better option to me.
Overall, I also like the idea of releasing the messages. Keeping the
messages around increases the router's
memory footprint. The messages could stay forever in the sender's
undelivered FIFO if the sender does not disconnect
and a receiver never shows up.
>
> ----- Original Message -----
> > From: "Ted Ross" <tr...@redhat.com>
> > To: users@qpid.apache.org
> > Sent: Thursday, May 24, 2018 11:59:32 AM
> > Subject: Re: Handling of undeliverable messages in Dispatch Router
> >
> > I've given this a bit more thought and I think that the second option
> > is the correct one. Philosophically, Qpid Dispatch Router is about
> > minimizing the number of deliveries in flight. This reduces latency,
> > reduces memory use, and increases aggregate capacity and scale.
> >
> > Releasing rather than holding undeliverable messages is more in-line
> > with this philosophy. TTL should be implemented in brokers that hold
> > messages in queues for extended periods of time.
> >
> > I'll raise a Jira for this.
> >
> > -Ted
> >
> > On Thu, May 24, 2018 at 7:56 AM, Ted Ross <tr...@redhat.com> wrote:
> > > Hi Kai,
> > >
> > > What you describe is the current behavior of the router. When the
> > > consumer detaches, the router does not revoke the credit already given
> > > to the producer. There are two ways we can address this issue (I
> > > agree that the current behavior is not optimal).
> > >
> > > We could implement time-to-live expiration so the delivery would be
> > > rejected if it sits in the buffer longer than the specified TTL.
> > >
> > > Alternatively, we could release deliveries for which there is no
> > > longer a valid destination. This leaves the "retry or not" decision
> > > up to the producer.
> > >
> > > Thoughts?
> > >
> > > -Ted
> > >
> > > On Thu, May 24, 2018 at 4:53 AM, Hudalla Kai (INST/ECS4)
> > > <ka...@bosch-si.com> wrote:
> > >> Hi,
> > >>
> > >>
> > >> we are experiencing some unwanted/unexpected behavior when using
> message
> > >> routing in Dispatch Router 1.0.1.
> > >>
> > >>
> > >> 1. Receiver opens a receiver link on control/my-tenant/my-device
> > >> 2. Sender opens a sender link on control/my-tenant/my-device
> > >> 3. Sender gets credit from the router
> > >> 4. Receiver closes its link with the router
> > >> 5. Sender sends an unsettled message on its sender link
> > >> 6. dispatch router does not accept nor reject the message, in
> fact, the
> > >> sender does not get any disposition at all
> > >> 7. As soon as the receiver opens a new link on the address, it
> gets the
> > >> message
> > >>
> > >> Is this the intended behavior? The Dispatch Router book states in
> section
> > >> 4.2 [1]:
> > >>
> > >>
> > >> Address semantics include the following considerations:
> > >>
> > >> * Routing pattern - direct, multicast, balanced
> > >>
> > >> * Undeliverable action - drop, hold and retry, redirect
> > >>
> > >> * Reliability - N destinations, etc.
> > >>
> > >> In particular, the "undeliverable action" seems to be of importance
> here
> > >> (the default seems to be "hold and retry"). Is this configurable? In
> our
> > >> case it would be more desirable to have the router reject the message
> > >> instead.
> > >>
> > >>
> > >> [1]
> > >> https://qpid.apache.org/releases/qpid-dispatch-1.0.1/
> book/index.html#addressing
> > >>
> > >>
> > >> Mit freundlichen Grüßen / Best regards
> > >>
> > >> Kai Hudalla
> > >> Chief Software Architect
> > >>
> > >> Bosch Software Innovations GmbH
> > >> Ullsteinstraße 128
> > >> 12109 Berlin
> > >> GERMANY
> > >> www.bosch-si.com
> > >>
> > >> Registered office: Berlin, Register court: Amtsgericht
> Charlottenburg, HRB
> > >> 148411 B;
> > >> Chairman of the Supervisory Board: Dr.-Ing. Thorsten Lücke; Managing
> > >> Directors: Dr. Stefan Ferber, Michael Hahn
> >
> > ---------------------------------------------------------------------
> > 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: Handling of undeliverable messages in Dispatch Router
Posted by Chuck Rolke <cr...@redhat.com>.
Releasing the messages sounds like the better choice.
It also would be nice if the router could revoke the sender's credit so
that he could not send any more. This would create the same state as
when the sender attaches and there's no receiver available. Kind of like
a receiver-initiated drain.
Or just stop re-issuing credit. Credit would dwindle as the sender
sends until the sender credit runs out. This might be more reliable
as it should work with all sender clients.
----- Original Message -----
> From: "Ted Ross" <tr...@redhat.com>
> To: users@qpid.apache.org
> Sent: Thursday, May 24, 2018 11:59:32 AM
> Subject: Re: Handling of undeliverable messages in Dispatch Router
>
> I've given this a bit more thought and I think that the second option
> is the correct one. Philosophically, Qpid Dispatch Router is about
> minimizing the number of deliveries in flight. This reduces latency,
> reduces memory use, and increases aggregate capacity and scale.
>
> Releasing rather than holding undeliverable messages is more in-line
> with this philosophy. TTL should be implemented in brokers that hold
> messages in queues for extended periods of time.
>
> I'll raise a Jira for this.
>
> -Ted
>
> On Thu, May 24, 2018 at 7:56 AM, Ted Ross <tr...@redhat.com> wrote:
> > Hi Kai,
> >
> > What you describe is the current behavior of the router. When the
> > consumer detaches, the router does not revoke the credit already given
> > to the producer. There are two ways we can address this issue (I
> > agree that the current behavior is not optimal).
> >
> > We could implement time-to-live expiration so the delivery would be
> > rejected if it sits in the buffer longer than the specified TTL.
> >
> > Alternatively, we could release deliveries for which there is no
> > longer a valid destination. This leaves the "retry or not" decision
> > up to the producer.
> >
> > Thoughts?
> >
> > -Ted
> >
> > On Thu, May 24, 2018 at 4:53 AM, Hudalla Kai (INST/ECS4)
> > <ka...@bosch-si.com> wrote:
> >> Hi,
> >>
> >>
> >> we are experiencing some unwanted/unexpected behavior when using message
> >> routing in Dispatch Router 1.0.1.
> >>
> >>
> >> 1. Receiver opens a receiver link on control/my-tenant/my-device
> >> 2. Sender opens a sender link on control/my-tenant/my-device
> >> 3. Sender gets credit from the router
> >> 4. Receiver closes its link with the router
> >> 5. Sender sends an unsettled message on its sender link
> >> 6. dispatch router does not accept nor reject the message, in fact, the
> >> sender does not get any disposition at all
> >> 7. As soon as the receiver opens a new link on the address, it gets the
> >> message
> >>
> >> Is this the intended behavior? The Dispatch Router book states in section
> >> 4.2 [1]:
> >>
> >>
> >> Address semantics include the following considerations:
> >>
> >> * Routing pattern - direct, multicast, balanced
> >>
> >> * Undeliverable action - drop, hold and retry, redirect
> >>
> >> * Reliability - N destinations, etc.
> >>
> >> In particular, the "undeliverable action" seems to be of importance here
> >> (the default seems to be "hold and retry"). Is this configurable? In our
> >> case it would be more desirable to have the router reject the message
> >> instead.
> >>
> >>
> >> [1]
> >> https://qpid.apache.org/releases/qpid-dispatch-1.0.1/book/index.html#addressing
> >>
> >>
> >> Mit freundlichen Grüßen / Best regards
> >>
> >> Kai Hudalla
> >> Chief Software Architect
> >>
> >> Bosch Software Innovations GmbH
> >> Ullsteinstraße 128
> >> 12109 Berlin
> >> GERMANY
> >> www.bosch-si.com
> >>
> >> Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB
> >> 148411 B;
> >> Chairman of the Supervisory Board: Dr.-Ing. Thorsten Lücke; Managing
> >> Directors: Dr. Stefan Ferber, Michael Hahn
>
> ---------------------------------------------------------------------
> 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: Handling of undeliverable messages in Dispatch Router
Posted by Ted Ross <tr...@redhat.com>.
I've given this a bit more thought and I think that the second option
is the correct one. Philosophically, Qpid Dispatch Router is about
minimizing the number of deliveries in flight. This reduces latency,
reduces memory use, and increases aggregate capacity and scale.
Releasing rather than holding undeliverable messages is more in-line
with this philosophy. TTL should be implemented in brokers that hold
messages in queues for extended periods of time.
I'll raise a Jira for this.
-Ted
On Thu, May 24, 2018 at 7:56 AM, Ted Ross <tr...@redhat.com> wrote:
> Hi Kai,
>
> What you describe is the current behavior of the router. When the
> consumer detaches, the router does not revoke the credit already given
> to the producer. There are two ways we can address this issue (I
> agree that the current behavior is not optimal).
>
> We could implement time-to-live expiration so the delivery would be
> rejected if it sits in the buffer longer than the specified TTL.
>
> Alternatively, we could release deliveries for which there is no
> longer a valid destination. This leaves the "retry or not" decision
> up to the producer.
>
> Thoughts?
>
> -Ted
>
> On Thu, May 24, 2018 at 4:53 AM, Hudalla Kai (INST/ECS4)
> <ka...@bosch-si.com> wrote:
>> Hi,
>>
>>
>> we are experiencing some unwanted/unexpected behavior when using message routing in Dispatch Router 1.0.1.
>>
>>
>> 1. Receiver opens a receiver link on control/my-tenant/my-device
>> 2. Sender opens a sender link on control/my-tenant/my-device
>> 3. Sender gets credit from the router
>> 4. Receiver closes its link with the router
>> 5. Sender sends an unsettled message on its sender link
>> 6. dispatch router does not accept nor reject the message, in fact, the sender does not get any disposition at all
>> 7. As soon as the receiver opens a new link on the address, it gets the message
>>
>> Is this the intended behavior? The Dispatch Router book states in section 4.2 [1]:
>>
>>
>> Address semantics include the following considerations:
>>
>> * Routing pattern - direct, multicast, balanced
>>
>> * Undeliverable action - drop, hold and retry, redirect
>>
>> * Reliability - N destinations, etc.
>>
>> In particular, the "undeliverable action" seems to be of importance here (the default seems to be "hold and retry"). Is this configurable? In our case it would be more desirable to have the router reject the message instead.
>>
>>
>> [1] https://qpid.apache.org/releases/qpid-dispatch-1.0.1/book/index.html#addressing
>>
>>
>> Mit freundlichen Grüßen / Best regards
>>
>> Kai Hudalla
>> Chief Software Architect
>>
>> Bosch Software Innovations GmbH
>> Ullsteinstraße 128
>> 12109 Berlin
>> GERMANY
>> www.bosch-si.com
>>
>> Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B;
>> Chairman of the Supervisory Board: Dr.-Ing. Thorsten Lücke; Managing Directors: Dr. Stefan Ferber, Michael Hahn
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Handling of undeliverable messages in Dispatch Router
Posted by Ted Ross <tr...@redhat.com>.
Hi Kai,
What you describe is the current behavior of the router. When the
consumer detaches, the router does not revoke the credit already given
to the producer. There are two ways we can address this issue (I
agree that the current behavior is not optimal).
We could implement time-to-live expiration so the delivery would be
rejected if it sits in the buffer longer than the specified TTL.
Alternatively, we could release deliveries for which there is no
longer a valid destination. This leaves the "retry or not" decision
up to the producer.
Thoughts?
-Ted
On Thu, May 24, 2018 at 4:53 AM, Hudalla Kai (INST/ECS4)
<ka...@bosch-si.com> wrote:
> Hi,
>
>
> we are experiencing some unwanted/unexpected behavior when using message routing in Dispatch Router 1.0.1.
>
>
> 1. Receiver opens a receiver link on control/my-tenant/my-device
> 2. Sender opens a sender link on control/my-tenant/my-device
> 3. Sender gets credit from the router
> 4. Receiver closes its link with the router
> 5. Sender sends an unsettled message on its sender link
> 6. dispatch router does not accept nor reject the message, in fact, the sender does not get any disposition at all
> 7. As soon as the receiver opens a new link on the address, it gets the message
>
> Is this the intended behavior? The Dispatch Router book states in section 4.2 [1]:
>
>
> Address semantics include the following considerations:
>
> * Routing pattern - direct, multicast, balanced
>
> * Undeliverable action - drop, hold and retry, redirect
>
> * Reliability - N destinations, etc.
>
> In particular, the "undeliverable action" seems to be of importance here (the default seems to be "hold and retry"). Is this configurable? In our case it would be more desirable to have the router reject the message instead.
>
>
> [1] https://qpid.apache.org/releases/qpid-dispatch-1.0.1/book/index.html#addressing
>
>
> Mit freundlichen Grüßen / Best regards
>
> Kai Hudalla
> Chief Software Architect
>
> Bosch Software Innovations GmbH
> Ullsteinstraße 128
> 12109 Berlin
> GERMANY
> www.bosch-si.com
>
> Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B;
> Chairman of the Supervisory Board: Dr.-Ing. Thorsten Lücke; Managing Directors: Dr. Stefan Ferber, Michael Hahn
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org