On Mon, Oct 5, 2020 at 7:10 AM Lohmann Carsten (IOC/PAP-HU) <[email protected]> wrote:
> Hi, > > let's imagine a Sender application sending an unsettled message to the > Qpid dispatch router and a Receiver application (usually) consuming and > settling it. > > The sender is interested in the outcome of the delivery and waits for the > disposition update. But the sender shall not wait forever. So, after a > configured time period with no received disposition update, the sender > considers the delivery to be failed and stops waiting. If the sender > doesn't do anything with the delivery in such a scenario and the receiver > doesn't send an disposition update later on either, it looks like the > delivery will be kept "in flight" in the router for as long as the link > lives. And if that happens for as many messages as the configured link > capacity in the router, the client will get no credits anymore for sending > further messages (even if the receiver has sent credits in the meantime). > > The question is now how to handle such a case (receiver not sending a > disposition in time) from the sender side, basically canceling the delivery. > > Would it be the recommended approach to release and settle the delivery > from the sender then? > > Hi Lohmann, At minimum the sender should settle the delivery. Having the sender set the outcome is optional. The receiver will get a delivery update indicating the sender settled the delivery (and the final outcome if you choose to set it). The receiver should then settle the delivery as well. > I don't see such a scenario to be explicitly referred to in the AMQP spec, > but I don't see it disallowing this approach either. > And I guess the example in the description of the Released outcome [1] > could be seen as somewhat similar: > --- > The source MAY spontaneously attain the released outcome for a message > (for example the source might implement some sort of time-bound acquisition > lock, after which the acquisition of a message at a node is revoked to > allow for delivery to an alternative consumer). > --- > > The Qpid router seems to handle this disposition frame from the sender in > the expected way, forwarding it to the receiver. > So, would that be the recommended way to handle this case? > > > [1] > http://docs.oasis-open.org/amqp/core/v1.0/amqp-core-complete-v1.0.pdf#subsection.3.4.4 > > > Best regards > > Carsten Lohmann > > Bosch IoT Hub - Product Area IoT Platform (IOC/PAP-HU) > Bosch.IO GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch.io > > Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B > Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. > Stefan Ferber, Dr. Aleksandar Mitrovic, Yvonne Reckling > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- -K
