I also started summarizing and jotting down things in a JIRA ticket. https://issues.apache.org/jira/browse/ARTEMIS-847
John On Thu, Nov 10, 2016 at 9:46 PM John D. Ament <johndam...@apache.org> wrote: > So, the ack process is something essentially there already in most > protocols. The difference is that you have a persistent TCP connection > from client to server. With HTTP, its a new socket each time. > > I suspect there's some level of node affinity that may exist in the code > that may be a problem for this. For instance, a "session" is no longer > based on that connection, but instead probably based on some subscriber ID > field being shared. I might even expect that this continues to work > independent of server you access. If you're in a cluster, the entire > cluster should be aware of the messages you're processing. An > acknowledgement sent to any node should work. > > With regard to leveraging the existing REST API. I'd be ok with this new > REST being its own independent protocol. It's a larger dev effort, but > ideally we could even move away from the very weird REST impl that's there > today. Basically, the way I see it, this feature adds acknowledgement to > the REST API, without assuming each message is auto acknowledged (at least > last I looked at the REST API, it was auto-ack). > > John > > > On Thu, Nov 10, 2016 at 7:23 PM Matt Pavlovich <mattr...@gmail.com> wrote: > > Sounds good, this sounds like an interesting use case. The one upside I > see of being a subscription strategy is that you could theoretically add > that behavior to all clients (that support some sort of ack) using any > protocol vs having it be REST-only. > > On 11/10/16 4:09 PM, John D. Ament wrote: > > What Martyn is describing is closer to what I'm thinking. It may even > make > > sense to refactor rest into a protocol as a part of this. > > > > I'll respond tonight with a few more details of what I was thinking. > > Thanks for the input so far guys! > > > > John > > > > On Nov 10, 2016 16:20, "Martyn Taylor" <mtay...@redhat.com> wrote: > > > > The Artemis REST API is already an independent service that layers on top > > of JMS. If we're adding this API to the REST module it'd be independent > > > > That said... this could be done as a protocol module (the protocol > modules > > are pluggable) when deployed it'd then be managed by the broker. Just > like > > AMQP or any other protocol. The benefit of doing it this way is that > you'd > > have more fine grained control via the internal CORE API. Also means you > > can plug in to the security layer etc... it does mean starting from > > scratch though... > > > > On 10 Nov 2016 21:01, "Matt Pavlovich" <mattr...@gmail.com> wrote: > > > >> How do you see the service layering on top of Artemis? A fully > > independent service with a "seen message id" repository, or a > subscription > > recovery-style policy within the broker with a REST service on top? > >> > >> On 11/9/16 11:54 AM, John D. Ament wrote: > >>> All, > >>> > >>> One thing I see come up quite often when looking at cloud based > messaging > >>> systems is the concept of a reservation (there's a couple of terms out > >>> there, reservation seems to describe it best). The reservation acts > like > >>> this: > >>> > >>> - Client polls for messages and get some number of messages back. > >>> - When a client polls again, those messages are not returned for some > >>> duration since it read them. > >>> - The messages are not auto-acknowledged. > >>> - A second API is invoked indicating that the client has acknowledged > > that > >>> message, typically using some message id or reservation id. > >>> - If after some duration, a message was not acknowledged, it becomes > >>> eligible for reception again. > >>> > >>> I'd like to add this type of capability to the REST API for Artemis. > > What > >>> do others think? > >>> > >>> John > >>> > >
