activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clebert Suconic <clebert.suco...@gmail.com>
Subject Re: [DISCUSS] Reservation Based Rest API for Artemis
Date Tue, 13 Dec 2016 15:34:04 GMT
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
View raw message