Comments on: Investigating Message Queueing systems

By: yangyang

yangyang — Thu, 25 Mar 2010 12:31:06 +0000

Grassroots Indigenous Multimedia announces the launch of their new Ojibwe Language learning software, Ojibwemodaa.Best Way : Rosetta stone learning Tips. Available in more than 30 languages, the Rosetta stone language-learning solution is used by schools, the consumer will write a message on the Personal Rosetta Stone. Download free language software, play online games and start learning a language now.

By: Kulbhushan

Kulbhushan — Tue, 12 Jan 2010 06:11:33 +0000

I think when you think about messaging you should also consider Tibco’s EMS http://www.tibco.com/software/messaging/enterprise-message-service/default.jsp.

By: Bhavin

Bhavin — Thu, 31 Dec 2009 12:09:05 +0000

@alexis: thanks for the addtl links. we have begun using rabbitmq in a test environment on one of our projects

By: alexis

alexis — Thu, 31 Dec 2009 09:42:53 +0000

In relation to RabbitMQ we try to keep an up to date set of introductory docs and links to other materials here: http://www.rabbitmq.com/how.html

.. and here: http://delicious.com/alexisrichardson/rabbitmq

I agree with the above comments – you should make sure you fully understand what your requirements are and how they relate to the product’s capabilities and configurations. There are LOTS of different patterns for messaging. You should also be thinking about scale, and location of your server or (possibly) servers if they are in many locations.

Cheers

alexis

By: Rob Davies

Rob Davies — Tue, 29 Dec 2009 16:36:29 +0000

Its worth paying attention to what persistence messages mean. For some messaging implementations – it simply means the message will be persisted if it isn’t consumed – it doesn’t mean you won’t loose messages (often a lot more than a few) on a hard failure.

For messaging systems that are JMS compatible, persistent delivery means ‘guaranteed’ – the send is synchronous and written to disk before its delivered to any consumer(s).

By: Indus Khaitan

Indus Khaitan — Tue, 29 Dec 2009 12:20:56 +0000

In my quest of selecting an MQ — there were only two major thoughts which helped me arrive at an architecture & implementation of choice:

1. Data Loss & Data type — Essentially, what kind of data is passing through the MQ. If it is okay to lose a few messages here & there, then you may not require persistence & may allow overloaded listeners. For example, implementing the MQ in a payment gateway vs. implementing an MQ for social media.

2. Throughput — How fast? Social media may require instant consumption but okay to be delayed while payment gateway messages cannot be delayed beyond acceptable timeout periods. The loads in a payment gateway can be predicted whereas in social media queues it may have bursts.

2 cents — hope that helps.

Indus