https://issues.apache.org/jira/browse/DISPATCH-1012
On Fri, May 25, 2018 at 8:20 AM, Hudalla Kai (INST/ECS4) <kai.huda...@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) >> <kai.huda...@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-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
