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 >> >> 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
