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) > > <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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
