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