camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <claus.ib...@gmail.com>
Subject Re: Is it possible to implement "Last value queue" using Camel?
Date Tue, 26 Feb 2013 07:09:06 GMT
On Tue, Feb 26, 2013 at 4:09 AM, Paul Gale <paul.n.gale@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 <raul@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 <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
>>



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

Mime
View raw message