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 <rob.j.godf...@gmail.com> wrote: > On Tue, 29 May 2018 at 15:15, Robbie Gemmell <robbie.gemm...@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 <acon...@redhat.com> wrote: >> > On Thu, May 24, 2018 at 1:59 PM, Ganesh Murthy <gmur...@redhat.com> >> wrote: >> > >> >> On Thu, May 24, 2018 at 1:48 PM, Chuck Rolke <cro...@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) >> >> > > > <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 >> >> > >> >> > >> >> >> >> --------------------------------------------------------------------- >> 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
