Looking for extensive knowledge with Active MQ

[Ori Lahav]

any is working with it?
into the more advanced features of it?

outbrain is looking for some know how.

[Boris Shulman]

We worked with ActiveMQ in NewACT but didn't use any of the advance features.

[David Peleg]

What do you mean advanced features?

Can you give some examples?

I once dealt a bit with synchronous vs. asynchronous messaging, about the way to interact cheaply inside the JVM without serializing things  with no real reason, and things like that.

If these are the things you are interested in, I can search for the link I've read.

David.

On Sun, Nov 21, 2010 at 10:35 PM, Ori Lahav <ola...@gmail.com> wrote:

[Ori Lahav]

We are dealing with it for a while with advanced features like Topics, Virtual topics, Mash brokers architecture, etc...

It never went smooth and we would like to know if someone have more extensive experience with it.

Ori

--
http://olahav.typepad.com

[Boris Shulman]

As I mentioned we never dealt with more advanced features, but even
without them it was usually unstable and needed to be closely
monitored. But I think that in the latest version it is more stable
than it used to be... Anyway I think it is worth while looking on
HornetQ as an alternative.

[Eran Sandler]

From my experience, the overhead of ActiveMQ and other AMQP implementations (RabbitMQ) are not really useful 99% of the time.

While the latest version of RabbitMQ added a new way to persist messages to the disk instead of saving everything in memory (thus allowing more graceful handling of spikes where you get a LOT more messages queued), I still prefer easier solutions.

Specifically, I would recommend taking a look at Twitter's Kestrel: https://github.com/robey/kestrel

It's written in Scala (a language that runs on top of JVM and allows access to all of the Java goodness) and uses the memcaced protocol with minor syntax addons for (sort of) transactional syntax (a little more info on the syntax sugar: http://robey.lag.net/2008/11/27/scarling-to-kestrel.html).

Any memcached client that uses the text protocol can be used as a client (with all the relevant client based key hashing to work with more servers and distribute load).

The best feature, in my mind, is the flow-to-disk. In cases where you have spikes (like Twitter has in breaking news events and such) and if certain conditions are met (total memory of the queue is larger than X and/or more than Y messages), it will throw the messages directly to the disk and will allow you to still process messages (reading from disk to memory when you empty the memory of the queue). 

This allows very easy integration (any memcached client) with a very easy and rather configurable server that can handle load spikes easily.

Eran

On Sun, Nov 21, 2010 at 10:35 PM, Ori Lahav <ola...@gmail.com> wrote: