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
