I thought about it some more over night. I think we can do the current rest api pretty easily as just a plain protocol. Both CXF and RestEasy have netty backends (or as CXF calls it transport) which means we can plugin in their handlers into . Once the rest api is converted start to make changes to it. It also means we can start to break the hard dependency on resteasy on the JAX-RS layer. It would also mean we can remove the servlet container requirement.
John On Tue, Dec 13, 2016 at 10:34 AM Clebert Suconic <clebert.suco...@gmail.com> wrote: > 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 >
