On Tue, 29 May 2018 at 17:05, Robbie Gemmell <robbie.gemm...@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 <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 > >
