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