What about implementing LVQ activemq plugin? http://activemq.apache.org/developing-plugins.html
Here are a bunch of examples: http://svn.apache.org/viewvc/activemq/trunk/activemq-broker/src/main/java/org/apache/activemq/broker/util/ http://svn.apache.org/viewvc/activemq/trunk/activemq-broker/src/main/java/org/apache/activemq/plugin/ Best Regards, Sergey Zhemzhitsky Phone. +7 495 2580500 ext. 1246 -----Original Message----- From: Claus Ibsen [mailto:claus.ib...@gmail.com] Sent: Tuesday, February 26, 2013 11:09 AM To: users@camel.apache.org Subject: Re: Is it possible to implement "Last value queue" using Camel? On Tue, Feb 26, 2013 at 4:09 AM, 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? > 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 <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 >> -- Claus Ibsen ----------------- Red Hat, Inc. FuseSource is now part of Red Hat Email: cib...@redhat.com Web: http://fusesource.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen _______________________________________________________ CONFIDENTIALITY NOTICE: This email and any files attached to it may be confidential. If you are not the intended recipient you are notified that using, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error please notify the sender and delete this email.
