Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Subject: Re: [DISCUSS] Reservation Based Rest API for Artemis
To: dev@activemq.apache.org
References: <CAOqetn-uUyh9PXinCmSf-B_z61WcJ3gHL9p22GNOB9_0_WfmnQ@mail.gmail.com>
 <c795f5f4-305e-e412-8dd5-0c3eac1c2828@gmail.com>
 <CAH6wpnoP12DEbnMzQew8NfNuHmii1cRNi+J3ziYdit8VwF_iOQ@mail.gmail.com>
 <CAOqetn-LWHMfPhk6+ob3gtqHkbQp82vQLQ3hAWVG7NjZzi6hbw@mail.gmail.com>
 <CAOqetn-fSgGeADY5N8V-22QZjKMMxaabe0dtsY+3qTJpgO0VEA@mail.gmail.com>
From: Matt Pavlovich <mattrpav@gmail.com>
Message-ID: <a0a0f467-1e64-3424-082e-64da460e4412@gmail.com>
Date: Thu, 10 Nov 2016 18:23:14 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0)
 Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <CAOqetn-fSgGeADY5N8V-22QZjKMMxaabe0dtsY+3qTJpgO0VEA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
archived-at: Fri, 11 Nov 2016 00:23:20 -0000

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
>>>