activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Pavlovich <mattr...@gmail.com>
Subject Re: [DISCUSS] Reservation Based Rest API for Artemis
Date Fri, 11 Nov 2016 00:23:14 GMT
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
View raw message