>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 <r...@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.g...@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
>

Reply via email to