You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Paul Gale <pa...@gmail.com> on 2013/02/25 17:00:46 UTC
Is it possible to implement "Last value queue" using Camel?
Hi,
FYI: I am using ActiveMQ 5.8 with Camel 2.10.3.
Is it possible to implement 'last value queue' type semantics using Camel?
As far as I know ActiveMQ does not natively support 'last value queues'
therefore I am left trying to implement this via Camel.
The particular scenario I am looking to implement is as follows: using
Camel's Delayer EIP messages that match a certain criteria will be delayed
by 24 hours, say, before being delivered. If an update to a message already
held by the Delayer arrives it must over write the previously seen version
of the same message. For example, if ten updates to the same message arrive
during the delay period then only the tenth update is dispatched to the
consumer.
This is essentially the inverse of the IdempotentConsumer EIP which
dispatches the first (as opposed to the last) version of a message an then
filters out subsequent duplicates.
Thanks,
Paul
Re: Is it possible to implement "Last value queue" using Camel?
Posted by Christian Müller <ch...@gmail.com>.
Probably in Camel 3.0 which we will not see in short term. May be end of
the year...
Sent from a mobile device
Am 25.02.2013 19:10 schrieb "Paul Gale" <pa...@gmail.com>:
> >Your use case doesn't fit with the concept of messaging
>
> I don't see why as the concept of "last value" queues originates in
> queuing. In fact JBoss, HornetQ and Qpid all offer "last value queues".
> It's just that none of those products are an option for me.
>
> I've since found out that ActiveMQ does implement the moral equivalent of a
> "last value" queue, albeit as a topic. However, I don't yet know whether it
> is an _exact_ equivalent. It would seem that it's more of a consumer
> subscription option than an aspect of the way the queue itself was
> constructed. Regardless, in ActiveMQ it's called "last image caching". It
> is implemented as part of the lastImageSubscriptionRecoveryPolicy as
> documented here:
> http://activemq.apache.org/subscription-recovery-policy.html.
>
> Also, delaying a message for delivery at some point in the future seems to
> me to be in the sweet spot of the Delayer EIP. There's no place where it
> says that Delayer is only supposed to work with short delays. If I want to
> delay a message for days that should be just fine - that's why we have
> persistence. I realize that the Delayer does not support persistence so
> presumably everything is kept in memory making it failover intolerant. As
> you're a Camel committer do you know of any plans to make the Delayer EIP
> failover tolerant?
>
> This, I presume, is the same problem that plagues the Resequencer which, as
> far as I can tell, does not have a way to externalize it's temporal state
> either. Any news on when the Resequencer will have this feature added?
>
> Thanks,
> Paul
>
> On Mon, Feb 25, 2013 at 5:40 PM, Raul Kripalani <ra...@evosent.com> wrote:
>
> > You might be better off using Redis or another technology rather than
> > a message broker.
> > Your use case doesn't fit with the concept of messaging, lightweight
> > DB storage is better suited. While you can find ways to implement it
> > on AMQ, the solution will be suboptimal.
> > We offer a camel-redis component as of Camel 2.11. You can use it with
> > camel-jms to bridge JMS clients with Redis, if need be.
> >
> > Regards,
> > Raúl.
> > Apache Camel Committer
> >
> > On 25 Feb 2013, at 16:01, Paul Gale <pa...@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > FYI: I am using ActiveMQ 5.8 with Camel 2.10.3.
> > >
> > > Is it possible to implement 'last value queue' type semantics using
> > Camel?
> > > As far as I know ActiveMQ does not natively support 'last value queues'
> > > therefore I am left trying to implement this via Camel.
> > >
> > > The particular scenario I am looking to implement is as follows: using
> > > Camel's Delayer EIP messages that match a certain criteria will be
> > delayed
> > > by 24 hours, say, before being delivered. If an update to a message
> > already
> > > held by the Delayer arrives it must over write the previously seen
> > version
> > > of the same message. For example, if ten updates to the same message
> > arrive
> > > during the delay period then only the tenth update is dispatched to the
> > > consumer.
> > >
> > > This is essentially the inverse of the IdempotentConsumer EIP which
> > > dispatches the first (as opposed to the last) version of a message an
> > then
> > > filters out subsequent duplicates.
> > >
> > > Thanks,
> > > Paul
> >
>
RE: Is it possible to implement "Last value queue" using Camel?
Posted by Zhemzhitsky Sergey <Se...@sberbank-cib.ru>.
What about implementing LVQ activemq plugin?
http://activemq.apache.org/developing-plugins.html
Here are a bunch of examples:
http://svn.apache.org/viewvc/activemq/trunk/activemq-broker/src/main/java/org/apache/activemq/broker/util/
http://svn.apache.org/viewvc/activemq/trunk/activemq-broker/src/main/java/org/apache/activemq/plugin/
Best Regards,
Sergey Zhemzhitsky
Phone. +7 495 2580500 ext. 1246
-----Original Message-----
From: Claus Ibsen [mailto:claus.ibsen@gmail.com]
Sent: Tuesday, February 26, 2013 11:09 AM
To: users@camel.apache.org
Subject: Re: Is it possible to implement "Last value queue" using Camel?
On Tue, Feb 26, 2013 at 4:09 AM, Paul Gale <pa...@gmail.com> wrote:
>>Your use case doesn't fit with the concept of messaging
>
> I don't see why as the concept of "last value" queues originates in
> queuing. In fact JBoss, HornetQ and Qpid all offer "last value queues".
> It's just that none of those products are an option for me.
>
> I've since found out that ActiveMQ does implement the moral equivalent
> of a "last value" queue, albeit as a topic. However, I don't yet know
> whether it is an _exact_ equivalent. It would seem that it's more of
> a consumer subscription option than an aspect of the way the queue
> itself was constructed. Regardless, in ActiveMQ it's called "last
> image caching". It is implemented as part of the
> lastImageSubscriptionRecoveryPolicy as documented here:
> http://activemq.apache.org/subscription-recovery-policy.html.
>
> Also, delaying a message for delivery at some point in the future
> seems to me to be in the sweet spot of the Delayer EIP. There's no
> place where it says that Delayer is only supposed to work with short
> delays. If I want to delay a message for days that should be just fine
> - that's why we have persistence. I realize that the Delayer does not
> support persistence so presumably everything is kept in memory making
> it failover intolerant. As you're a Camel committer do you know of any
> plans to make the Delayer EIP failover tolerant?
>
> This, I presume, is the same problem that plagues the Resequencer
> which, as far as I can tell, does not have a way to externalize it's
> temporal state either. Any news on when the Resequencer will have this feature added?
>
ActiveMQ supports sending messages with a delayed timestamp / cron expression etc.
http://activemq.apache.org/delay-and-schedule-message-delivery.html
You can use that to schedule and delay a message for 24 hours. Then the message is persisted and forwarded.
The Camel delayer is in-memory only and NOT a good idea for long delays.
And ActiveMQ supports virtual topics
http://activemq.apache.org/virtual-destinations.html
Not sure if they would support the last image policy. But for this kind of question I suggest to ask on the ActiveMQ @user list.
> Thanks,
> Paul
>
> On Mon, Feb 25, 2013 at 5:40 PM, Raul Kripalani <ra...@evosent.com> wrote:
>
>> You might be better off using Redis or another technology rather than
>> a message broker.
>> Your use case doesn't fit with the concept of messaging, lightweight
>> DB storage is better suited. While you can find ways to implement it
>> on AMQ, the solution will be suboptimal.
>> We offer a camel-redis component as of Camel 2.11. You can use it
>> with camel-jms to bridge JMS clients with Redis, if need be.
>>
>> Regards,
>> Raúl.
>> Apache Camel Committer
>>
>> On 25 Feb 2013, at 16:01, Paul Gale <pa...@gmail.com> wrote:
>>
>> > Hi,
>> >
>> > FYI: I am using ActiveMQ 5.8 with Camel 2.10.3.
>> >
>> > Is it possible to implement 'last value queue' type semantics using
>> Camel?
>> > As far as I know ActiveMQ does not natively support 'last value queues'
>> > therefore I am left trying to implement this via Camel.
>> >
>> > The particular scenario I am looking to implement is as follows:
>> > using Camel's Delayer EIP messages that match a certain criteria
>> > will be
>> delayed
>> > by 24 hours, say, before being delivered. If an update to a message
>> already
>> > held by the Delayer arrives it must over write the previously seen
>> version
>> > of the same message. For example, if ten updates to the same
>> > message
>> arrive
>> > during the delay period then only the tenth update is dispatched to
>> > the consumer.
>> >
>> > This is essentially the inverse of the IdempotentConsumer EIP which
>> > dispatches the first (as opposed to the last) version of a message
>> > an
>> then
>> > filters out subsequent duplicates.
>> >
>> > Thanks,
>> > Paul
>>
--
Claus Ibsen
-----------------
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cibsen@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
_______________________________________________________
CONFIDENTIALITY NOTICE: This email and any files attached to it may be confidential. If you are not the intended recipient you are notified that using, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error please notify the sender and delete this email.
Re: Is it possible to implement "Last value queue" using Camel?
Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Feb 26, 2013 at 4:09 AM, Paul Gale <pa...@gmail.com> wrote:
>>Your use case doesn't fit with the concept of messaging
>
> I don't see why as the concept of "last value" queues originates in
> queuing. In fact JBoss, HornetQ and Qpid all offer "last value queues".
> It's just that none of those products are an option for me.
>
> I've since found out that ActiveMQ does implement the moral equivalent of a
> "last value" queue, albeit as a topic. However, I don't yet know whether it
> is an _exact_ equivalent. It would seem that it's more of a consumer
> subscription option than an aspect of the way the queue itself was
> constructed. Regardless, in ActiveMQ it's called "last image caching". It
> is implemented as part of the lastImageSubscriptionRecoveryPolicy as
> documented here:
> http://activemq.apache.org/subscription-recovery-policy.html.
>
> Also, delaying a message for delivery at some point in the future seems to
> me to be in the sweet spot of the Delayer EIP. There's no place where it
> says that Delayer is only supposed to work with short delays. If I want to
> delay a message for days that should be just fine - that's why we have
> persistence. I realize that the Delayer does not support persistence so
> presumably everything is kept in memory making it failover intolerant. As
> you're a Camel committer do you know of any plans to make the Delayer EIP
> failover tolerant?
>
> This, I presume, is the same problem that plagues the Resequencer which, as
> far as I can tell, does not have a way to externalize it's temporal state
> either. Any news on when the Resequencer will have this feature added?
>
ActiveMQ supports sending messages with a delayed timestamp / cron
expression etc.
http://activemq.apache.org/delay-and-schedule-message-delivery.html
You can use that to schedule and delay a message for 24 hours. Then
the message is persisted and forwarded.
The Camel delayer is in-memory only and NOT a good idea for long delays.
And ActiveMQ supports virtual topics
http://activemq.apache.org/virtual-destinations.html
Not sure if they would support the last image policy. But for this
kind of question I suggest to ask on the ActiveMQ @user list.
> Thanks,
> Paul
>
> On Mon, Feb 25, 2013 at 5:40 PM, Raul Kripalani <ra...@evosent.com> wrote:
>
>> You might be better off using Redis or another technology rather than
>> a message broker.
>> Your use case doesn't fit with the concept of messaging, lightweight
>> DB storage is better suited. While you can find ways to implement it
>> on AMQ, the solution will be suboptimal.
>> We offer a camel-redis component as of Camel 2.11. You can use it with
>> camel-jms to bridge JMS clients with Redis, if need be.
>>
>> Regards,
>> Raúl.
>> Apache Camel Committer
>>
>> On 25 Feb 2013, at 16:01, Paul Gale <pa...@gmail.com> wrote:
>>
>> > Hi,
>> >
>> > FYI: I am using ActiveMQ 5.8 with Camel 2.10.3.
>> >
>> > Is it possible to implement 'last value queue' type semantics using
>> Camel?
>> > As far as I know ActiveMQ does not natively support 'last value queues'
>> > therefore I am left trying to implement this via Camel.
>> >
>> > The particular scenario I am looking to implement is as follows: using
>> > Camel's Delayer EIP messages that match a certain criteria will be
>> delayed
>> > by 24 hours, say, before being delivered. If an update to a message
>> already
>> > held by the Delayer arrives it must over write the previously seen
>> version
>> > of the same message. For example, if ten updates to the same message
>> arrive
>> > during the delay period then only the tenth update is dispatched to the
>> > consumer.
>> >
>> > This is essentially the inverse of the IdempotentConsumer EIP which
>> > dispatches the first (as opposed to the last) version of a message an
>> then
>> > filters out subsequent duplicates.
>> >
>> > Thanks,
>> > Paul
>>
--
Claus Ibsen
-----------------
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cibsen@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: Is it possible to implement "Last value queue" using Camel?
Posted by Raul Kripalani <ra...@evosent.com>.
Hi Paul,
Last image caching for topics is part of the retroactive consumer
feature of AMQ. It allows for topic consumers to travel back to the
past without being durable subscribers.
I didn't mention it because, as far as I understood your use case, you
want the last message to be retained for each different value of a
particular property which acts like a bucket identifier. Correct? To
use the last image subscription recovery policy, you'd have to create
one topic per unique bucket ID, and your subscriber would have to
subscribe to all topics, which is a suboptimal solution in my opinion.
Performance would also be affected due to constant creation of topics
unless your buckets are finite.
Like someone mentioned, you could implement this as a broker plugin,
where you'd somehow keep track of the buckets and the
MessageReferences they contain, deleting old ones as newer messages
pop up. But I don't think it will be a simple plugin ;)
Maybe the AMQ user list could shed more light or instructions.
Regards,
Raúl.
On 26 Feb 2013, at 03:10, Paul Gale <pa...@gmail.com> wrote:
>> Your use case doesn't fit with the concept of messaging
>
> I don't see why as the concept of "last value" queues originates in
> queuing. In fact JBoss, HornetQ and Qpid all offer "last value queues".
> It's just that none of those products are an option for me.
>
> I've since found out that ActiveMQ does implement the moral equivalent of a
> "last value" queue, albeit as a topic. However, I don't yet know whether it
> is an _exact_ equivalent. It would seem that it's more of a consumer
> subscription option than an aspect of the way the queue itself was
> constructed. Regardless, in ActiveMQ it's called "last image caching". It
> is implemented as part of the lastImageSubscriptionRecoveryPolicy as
> documented here:
> http://activemq.apache.org/subscription-recovery-policy.html.
>
> Also, delaying a message for delivery at some point in the future seems to
> me to be in the sweet spot of the Delayer EIP. There's no place where it
> says that Delayer is only supposed to work with short delays. If I want to
> delay a message for days that should be just fine - that's why we have
> persistence. I realize that the Delayer does not support persistence so
> presumably everything is kept in memory making it failover intolerant. As
> you're a Camel committer do you know of any plans to make the Delayer EIP
> failover tolerant?
>
> This, I presume, is the same problem that plagues the Resequencer which, as
> far as I can tell, does not have a way to externalize it's temporal state
> either. Any news on when the Resequencer will have this feature added?
>
> Thanks,
> Paul
>
> On Mon, Feb 25, 2013 at 5:40 PM, Raul Kripalani <ra...@evosent.com> wrote:
>
>> You might be better off using Redis or another technology rather than
>> a message broker.
>> Your use case doesn't fit with the concept of messaging, lightweight
>> DB storage is better suited. While you can find ways to implement it
>> on AMQ, the solution will be suboptimal.
>> We offer a camel-redis component as of Camel 2.11. You can use it with
>> camel-jms to bridge JMS clients with Redis, if need be.
>>
>> Regards,
>> Raúl.
>> Apache Camel Committer
>>
>> On 25 Feb 2013, at 16:01, Paul Gale <pa...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> FYI: I am using ActiveMQ 5.8 with Camel 2.10.3.
>>>
>>> Is it possible to implement 'last value queue' type semantics using
>> Camel?
>>> As far as I know ActiveMQ does not natively support 'last value queues'
>>> therefore I am left trying to implement this via Camel.
>>>
>>> The particular scenario I am looking to implement is as follows: using
>>> Camel's Delayer EIP messages that match a certain criteria will be
>> delayed
>>> by 24 hours, say, before being delivered. If an update to a message
>> already
>>> held by the Delayer arrives it must over write the previously seen
>> version
>>> of the same message. For example, if ten updates to the same message
>> arrive
>>> during the delay period then only the tenth update is dispatched to the
>>> consumer.
>>>
>>> This is essentially the inverse of the IdempotentConsumer EIP which
>>> dispatches the first (as opposed to the last) version of a message an
>> then
>>> filters out subsequent duplicates.
>>>
>>> Thanks,
>>> Paul
>>
Re: Is it possible to implement "Last value queue" using Camel?
Posted by Paul Gale <pa...@gmail.com>.
>Your use case doesn't fit with the concept of messaging
I don't see why as the concept of "last value" queues originates in
queuing. In fact JBoss, HornetQ and Qpid all offer "last value queues".
It's just that none of those products are an option for me.
I've since found out that ActiveMQ does implement the moral equivalent of a
"last value" queue, albeit as a topic. However, I don't yet know whether it
is an _exact_ equivalent. It would seem that it's more of a consumer
subscription option than an aspect of the way the queue itself was
constructed. Regardless, in ActiveMQ it's called "last image caching". It
is implemented as part of the lastImageSubscriptionRecoveryPolicy as
documented here:
http://activemq.apache.org/subscription-recovery-policy.html.
Also, delaying a message for delivery at some point in the future seems to
me to be in the sweet spot of the Delayer EIP. There's no place where it
says that Delayer is only supposed to work with short delays. If I want to
delay a message for days that should be just fine - that's why we have
persistence. I realize that the Delayer does not support persistence so
presumably everything is kept in memory making it failover intolerant. As
you're a Camel committer do you know of any plans to make the Delayer EIP
failover tolerant?
This, I presume, is the same problem that plagues the Resequencer which, as
far as I can tell, does not have a way to externalize it's temporal state
either. Any news on when the Resequencer will have this feature added?
Thanks,
Paul
On Mon, Feb 25, 2013 at 5:40 PM, Raul Kripalani <ra...@evosent.com> wrote:
> You might be better off using Redis or another technology rather than
> a message broker.
> Your use case doesn't fit with the concept of messaging, lightweight
> DB storage is better suited. While you can find ways to implement it
> on AMQ, the solution will be suboptimal.
> We offer a camel-redis component as of Camel 2.11. You can use it with
> camel-jms to bridge JMS clients with Redis, if need be.
>
> Regards,
> Raúl.
> Apache Camel Committer
>
> On 25 Feb 2013, at 16:01, Paul Gale <pa...@gmail.com> wrote:
>
> > Hi,
> >
> > FYI: I am using ActiveMQ 5.8 with Camel 2.10.3.
> >
> > Is it possible to implement 'last value queue' type semantics using
> Camel?
> > As far as I know ActiveMQ does not natively support 'last value queues'
> > therefore I am left trying to implement this via Camel.
> >
> > The particular scenario I am looking to implement is as follows: using
> > Camel's Delayer EIP messages that match a certain criteria will be
> delayed
> > by 24 hours, say, before being delivered. If an update to a message
> already
> > held by the Delayer arrives it must over write the previously seen
> version
> > of the same message. For example, if ten updates to the same message
> arrive
> > during the delay period then only the tenth update is dispatched to the
> > consumer.
> >
> > This is essentially the inverse of the IdempotentConsumer EIP which
> > dispatches the first (as opposed to the last) version of a message an
> then
> > filters out subsequent duplicates.
> >
> > Thanks,
> > Paul
>
Re: Is it possible to implement "Last value queue" using Camel?
Posted by Willem jiang <wi...@gmail.com>.
I think it could be more easy to be done by using the caching for the last update, then store the result into some place.
I don't think the delayer is good solution if you have lots values need to be checked.
--
Willem Jiang
Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English)
http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On Tuesday, February 26, 2013 at 6:40 AM, Raul Kripalani wrote:
> You might be better off using Redis or another technology rather than
> a message broker.
> Your use case doesn't fit with the concept of messaging, lightweight
> DB storage is better suited. While you can find ways to implement it
> on AMQ, the solution will be suboptimal.
> We offer a camel-redis component as of Camel 2.11. You can use it with
> camel-jms to bridge JMS clients with Redis, if need be.
>
> Regards,
> Raúl.
> Apache Camel Committer
>
> On 25 Feb 2013, at 16:01, Paul Gale <paul.n.gale@gmail.com (mailto:paul.n.gale@gmail.com)> wrote:
>
> > Hi,
> >
> > FYI: I am using ActiveMQ 5.8 with Camel 2.10.3.
> >
> > Is it possible to implement 'last value queue' type semantics using Camel?
> > As far as I know ActiveMQ does not natively support 'last value queues'
> > therefore I am left trying to implement this via Camel.
> >
> > The particular scenario I am looking to implement is as follows: using
> > Camel's Delayer EIP messages that match a certain criteria will be delayed
> > by 24 hours, say, before being delivered. If an update to a message already
> > held by the Delayer arrives it must over write the previously seen version
> > of the same message. For example, if ten updates to the same message arrive
> > during the delay period then only the tenth update is dispatched to the
> > consumer.
> >
> > This is essentially the inverse of the IdempotentConsumer EIP which
> > dispatches the first (as opposed to the last) version of a message an then
> > filters out subsequent duplicates.
> >
> > Thanks,
> > Paul
>
Re: Is it possible to implement "Last value queue" using Camel?
Posted by Raul Kripalani <ra...@evosent.com>.
You might be better off using Redis or another technology rather than
a message broker.
Your use case doesn't fit with the concept of messaging, lightweight
DB storage is better suited. While you can find ways to implement it
on AMQ, the solution will be suboptimal.
We offer a camel-redis component as of Camel 2.11. You can use it with
camel-jms to bridge JMS clients with Redis, if need be.
Regards,
Raúl.
Apache Camel Committer
On 25 Feb 2013, at 16:01, Paul Gale <pa...@gmail.com> wrote:
> Hi,
>
> FYI: I am using ActiveMQ 5.8 with Camel 2.10.3.
>
> Is it possible to implement 'last value queue' type semantics using Camel?
> As far as I know ActiveMQ does not natively support 'last value queues'
> therefore I am left trying to implement this via Camel.
>
> The particular scenario I am looking to implement is as follows: using
> Camel's Delayer EIP messages that match a certain criteria will be delayed
> by 24 hours, say, before being delivered. If an update to a message already
> held by the Delayer arrives it must over write the previously seen version
> of the same message. For example, if ten updates to the same message arrive
> during the delay period then only the tenth update is dispatched to the
> consumer.
>
> This is essentially the inverse of the IdempotentConsumer EIP which
> dispatches the first (as opposed to the last) version of a message an then
> filters out subsequent duplicates.
>
> Thanks,
> Paul
Re: Is it possible to implement "Last value queue" using Camel?
Posted by Paul Gale <pa...@gmail.com>.
What are you defining as 'on top'?
- Do you mean by combining existing Camel EIPs somehow? If so please
provide a possible solution for this scenario.
- Or do you mean by implementing something lower level like a custom
component perhaps?
All detailed constructive guidance is much appreciated.
Thanks,
Paul
On Mon, Feb 25, 2013 at 4:32 PM, Christian Müller <
christian.mueller@gmail.com> wrote:
> You have to build your own solution on top of what Camel already
> provides...
>
> Best,
> Christian
>
> Sent from a mobile device
> Am 25.02.2013 08:01 schrieb "Paul Gale" <pa...@gmail.com>:
>
> > Hi,
> >
> > FYI: I am using ActiveMQ 5.8 with Camel 2.10.3.
> >
> > Is it possible to implement 'last value queue' type semantics using
> Camel?
> > As far as I know ActiveMQ does not natively support 'last value queues'
> > therefore I am left trying to implement this via Camel.
> >
> > The particular scenario I am looking to implement is as follows: using
> > Camel's Delayer EIP messages that match a certain criteria will be
> delayed
> > by 24 hours, say, before being delivered. If an update to a message
> already
> > held by the Delayer arrives it must over write the previously seen
> version
> > of the same message. For example, if ten updates to the same message
> arrive
> > during the delay period then only the tenth update is dispatched to the
> > consumer.
> >
> > This is essentially the inverse of the IdempotentConsumer EIP which
> > dispatches the first (as opposed to the last) version of a message an
> then
> > filters out subsequent duplicates.
> >
> > Thanks,
> > Paul
> >
>
Re: Is it possible to implement "Last value queue" using Camel?
Posted by Christian Müller <ch...@gmail.com>.
You have to build your own solution on top of what Camel already provides...
Best,
Christian
Sent from a mobile device
Am 25.02.2013 08:01 schrieb "Paul Gale" <pa...@gmail.com>:
> Hi,
>
> FYI: I am using ActiveMQ 5.8 with Camel 2.10.3.
>
> Is it possible to implement 'last value queue' type semantics using Camel?
> As far as I know ActiveMQ does not natively support 'last value queues'
> therefore I am left trying to implement this via Camel.
>
> The particular scenario I am looking to implement is as follows: using
> Camel's Delayer EIP messages that match a certain criteria will be delayed
> by 24 hours, say, before being delivered. If an update to a message already
> held by the Delayer arrives it must over write the previously seen version
> of the same message. For example, if ten updates to the same message arrive
> during the delay period then only the tenth update is dispatched to the
> consumer.
>
> This is essentially the inverse of the IdempotentConsumer EIP which
> dispatches the first (as opposed to the last) version of a message an then
> filters out subsequent duplicates.
>
> Thanks,
> Paul
>