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 Fri, 11 Nov 2016 02:46:31 GMT
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
> >>>
>
>

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