On Tue, 28 Jan 2020 at 22:35, Alan Conway <acon...@redhat.com> wrote:
> On Mon, Jan 27, 2020 at 7:44 AM Justin Ross <justin.r...@gmail.com> wrote: > > > I like to think of the message as a pure value object. As a result, it > can > > have whatever lifecycle the API user chooses. For me, that's a reason to > > isolate it from the delivery and tracker, because they do have more > tightly > > defined lifecycles. > > > > If there was a substantial win in convenience, I wouldn't be too bothered > > to have them combined, but in practice, I don't think it does make a big > > difference in convenience terms. For me, the separation of concerns is a > > bigger win. > > > > Big +1 - you don't acknowledge a message, you acknowledge a delivery. It's > important because messages aren't just received, they also be sent, copied, > stored etc. > Hmmm.... The message data (and maybe the application properties), certainly. The annotations.... may be more dubious. Logically at the very least the delivery-annotations are closer to the delivery than to you abstract notion of message. Moreover one might consider some aspects of the message to be "owned" and set by the library... if, for instance, the expectation is that the message-id is set by the library, what does it mean when the "old" value is replaced by a different value on resending? I do agree that there is a notion of "message" that has scope beyond the delivery/sending of the message - but I'm not 100% convined that this is 1:1 with the representation of what is sent over the wire in AMQP as the message. -- Rob > It is meaningless to "acknowledge" a message you just read from a database > or took from an in-memory queue, or a new message you created in order to > send it. So acknowledge is a method on a Delivery, not a Message. Same for > trackers - they don't even exist until a message is sent, and they expire > when the message is acknowledged, data in the message can exist (or be > destroyed) independently. > > > > > On Wed, Jan 22, 2020 at 6:04 AM Robbie Gemmell <robbie.gemm...@gmail.com > > > > wrote: > > > > > On Wed, 22 Jan 2020 at 09:39, Rob Godfrey <rob.j.godf...@gmail.com> > > wrote: > > > > > > > > On Tue, 21 Jan 2020 at 18:31, Robbie Gemmell < > robbie.gemm...@gmail.com > > > > > > > wrote: > > > > > > > > > On Tue, 21 Jan 2020 at 17:06, Rob Godfrey <rob.j.godf...@gmail.com > > > > > wrote: > > > > > > > > > > > > On Tue, 21 Jan 2020 at 16:38, Robbie Gemmell < > > > robbie.gemm...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > On Tue, 21 Jan 2020 at 14:28, Rob Godfrey < > > rob.j.godf...@gmail.com > > > > > > > > > wrote: > > > > > > > > > > > > > > > > On Tue, 21 Jan 2020 at 14:24, Robbie Gemmell < > > > > > robbie.gemm...@gmail.com> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > On Tue, 21 Jan 2020 at 11:21, Rob Godfrey < > > > rob.j.godf...@gmail.com > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [... snip ...] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 6. receiver-options - "auto-accept : Automatically accept > > > > > deliveries > > > > > > > that > > > > > > > > > > are not explicitly acknowledged"... what does this mean - > > > when > > > > > does > > > > > > > the > > > > > > > > > > accept happen, when the message is initially received, or > > > only > > > > > if the > > > > > > > > > > delivery somehow goes out of scope? > > > > > > > > > > > > > > > > > > For receive calls it would be when received. > > > > > > > > > > > > > > > > > > > > > > > > If there was a listener > > > > > > > > > (TBD) it would be after that returned. Much the same as > > > existing > > > > > > > > > clients auto ack essentially. > > > > > > > > > > > > > > > > > > > > > > > > > So... looking through the API design... the only way I see to > > > > > receive a > > > > > > > > message is through messaging-handler.on-message. So the idea > > is > > > the > > > > > > > > auto-accept means that upon the return from on-message, if > the > > > > > outcome > > > > > > > has > > > > > > > > not been set to accepted, and the message has not already > been > > > > > settled > > > > > > > (by > > > > > > > > either side) then the outcome of the delivery will be set to > > > > > accepted. > > > > > > > > > > > > > > > > > > > > > > There are recieve calls on the reciever, see the bottom of > > > > > > > https://www.ssorj.net/pumpjack/client/receiver/index.html. > > > > > > > > > > > > > > > > > > > > How do you get from the delivery to the message? > > > > > > > > > > > > > > > > In one case at least, currently delivery.message() > > > > > > > > > > > > > Looping back to Alex's question then - does the separation of > delivery > > > and > > > > message actually save us anything in terms of being "lightweight" > then, > > > if > > > > the delivery always needs to refer to the message? > > > > > > Not as it currently works but that wouldnt be hard to address, e.g > > > saying reading the message from the delivery clears it going forward, > > > which is actually what we do in existing separation of delivery and > > > message bits elsewhere (though at a byte payload level). > > > > > > > I'm not intrinsically > > > > against the separation, though in some ways it feels a bit odd to > have > > > > different object types for tracking inbound and outbound deliveries > > (the > > > > tracker and delivery classes), but using a single type for both > inbound > > > and > > > > outbound messages > > > > > > > > -- Rob > > > > > > > > > > I actually suggested the same 'receive message' thing myself at points > > > in discussion previously, so I'm not entirely against that either. > > > Having the delivery there perhaps provides a nice split point to > > > handle some more advanced cases though. One thing it does do is that > > > using the message doesnt really impact the potentially-ongoing > > > delivery handling (even though its retrieved from there), while > > > combining them would mean it is tied start to finish and so threading > > > and usage considerations could become more of an issue, e.g we might > > > need to prevent that message being sent. > > > > > > One thing to perhaps note more clearly is that unlike the existing > > > reactive APIs an intent here is to allow application thread usage of > > > the clients APIs directly without needing to ensure use of the > > > appropriate client thread(s). > > > > > > The message stuff as a whole has not yet been given all that much > > > consideration. I wouldnt say it was settled there is only a single > > > message type for example. I did mention potential for multiple message > > > types in my reply to Alex, though I was admittedly meaning in a given > > > direction at the time. > > > > > > > > > > > > > > > > > > With the recevier.receive call... I'm not sure how the second > half > > > of the > > > > > > description "auto-accept : Automatically accept deliveries that > are > > > not > > > > > > explicitly acknowledged" makes any sense. I don't see how > > > "explicitly > > > > > > ackowledg[ing]" is even possible. > > > > > > > > > > > > > > > > It isnt, calling receive with auto-accept would be expected to > > > > > acknowledge immediately at present (unless some other behaviour > were > > > > > defined). The latter bit can only apply to the handler style usage. > > > > > > > > > > The text is loosely covering the bases, and was perhaps even copied > > > > > from previous reactive api bits where auto-accept is an option and > no > > > > > receive style use is possible. > > > > > > > > > > > -- Rob > > > > > > > > > > > > > > > > > > > > > > > > > The messaging-handler stuff is again mostly part of the > existing > > > > > > > reactive bits (in some cases), which indeed work essentially as > > you > > > > > > > describe. The idea would be something similar (but obviously > > > narrower > > > > > > > in operation scope) for the handler configurable in the > reciever > > > > > > > options. > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > 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 > > > > > > > > >
