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" <paul.n.g...@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 <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