You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "John D. Ament" <jo...@gmail.com> on 2016/11/09 17:54:39 UTC
[DISCUSS] Reservation Based Rest API for Artemis
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
Re: [DISCUSS] Reservation Based Rest API for Artemis
Posted by Justin Bertram <jb...@apache.com>.
I've wanted to make these kinds of changes (i.e. lessen RESTeasy dependency, use Netty back-end) for a while now but just haven't had the time to do it. I think what you've proposed is great.
Justin
----- Original Message -----
From: "John D. Ament" <jo...@apache.org>
To: dev@activemq.apache.org
Sent: Tuesday, December 13, 2016 9:48:05 AM
Subject: Re: [DISCUSS] Reservation Based Rest API for Artemis
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 <cl...@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 <jo...@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 <jo...@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 <jo...@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 <ma...@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" <mt...@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" <ma...@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
>
Re: [DISCUSS] Reservation Based Rest API for Artemis
Posted by "John D. Ament" <jo...@apache.org>.
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 <cl...@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 <jo...@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 <jo...@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 <jo...@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 <ma...@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" <mt...@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" <ma...@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
>
Re: [DISCUSS] Reservation Based Rest API for Artemis
Posted by Clebert Suconic <cl...@gmail.com>.
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 <jo...@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 <jo...@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 <jo...@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 <ma...@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" <mt...@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" <ma...@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
Re: [DISCUSS] Reservation Based Rest API for Artemis
Posted by "John D. Ament" <jo...@apache.org>.
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 <jo...@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 <jo...@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 <ma...@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" <mt...@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" <ma...@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
> >>>
>
>
Re: [DISCUSS] Reservation Based Rest API for Artemis
Posted by "John D. Ament" <jo...@apache.org>.
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 <jo...@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 <ma...@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" <mt...@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" <ma...@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
> >>>
>
>
Re: [DISCUSS] Reservation Based Rest API for Artemis
Posted by "John D. Ament" <jo...@apache.org>.
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 <ma...@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" <mt...@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" <ma...@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
> >>>
>
>
Re: [DISCUSS] Reservation Based Rest API for Artemis
Posted by Matt Pavlovich <ma...@gmail.com>.
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" <mt...@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" <ma...@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
>>>
Re: [DISCUSS] Reservation Based Rest API for Artemis
Posted by "John D. Ament" <jo...@gmail.com>.
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" <mt...@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" <ma...@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
>>
>
Re: [DISCUSS] Reservation Based Rest API for Artemis
Posted by Martyn Taylor <mt...@redhat.com>.
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" <ma...@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
>>
>
Re: [DISCUSS] Reservation Based Rest API for Artemis
Posted by Matt Pavlovich <ma...@gmail.com>.
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
>
Re: [DISCUSS] Reservation Based Rest API for Artemis
Posted by Martyn Taylor <mt...@redhat.com>.
This sounds like a great idea.
One thing I like about these services, particularly those based around REST
over HTTP, is that they're simple to use, intuitive and easily
integratable, no special client libs required.
Are there any common/standard APIs/protocols that do this? Would this look
similar to something like Amazon SQS?
On 9 Nov 2016 17:55, "John D. Ament" <jo...@gmail.com> 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
>