With moving branch to 2.0.0.. it may be a good opportunity to make big changes and break compatibility.
On Mon, Dec 12, 2016 at 10:58 PM, John D. Ament <johndam...@apache.org> wrote: > So I'm sitting here laughing a little bit, as I started to write down code > to make this work. I realized that the REST interface supports most of > this already, The key difference right now, acknowledgements are based on > the last message received and its fully server stateful, doesn't seem to > handle a multiple server deployment. > > I know it was discussed a while ago about the compatibility of the REST > API, while most of its functional, there's some call outs I see: > > - Separation of logic. Right now a lot of the logic is embedded directly > in the rest endpoint classes, makes it hard to follow. > - Refactor the actual API, or maybe introduce a new API that better > supports messaging strategies people are using - JSON for instance. > > I'm inclined to start with this codebase, but introduce it as a new > module. This way if anyone's using the REST API its not broken. It would > give the opportunity to also move this into a protocol implementation as > well. > > John > > On Thu, Nov 10, 2016 at 10:10 PM John D. Ament <johndam...@apache.org> > wrote: > >> 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 >> >>> >> >> -- Clebert Suconic
