activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John D. Ament" <johndam...@apache.org>
Subject Re: [DISCUSS] Reservation Based Rest API for Artemis
Date Tue, 13 Dec 2016 15:48:05 GMT
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.suconic@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 <johndament@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 <johndament@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 <johndament@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 <mattrpav@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" <mtaylor@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" <mattrpav@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message