I think Erlang and AMQP? JMS requires client to have java client sending message to JMS provider. RabbitMQ implements AMQP. AMQP is completely independent of language. Message sender could be Python app and message receiver could be C++ app.
RabbitMQ is in Erlang means built in scalability and high availability. Possibility of server crash due to memory issues will not be there i guess.
One of the reasons I'm fond of RabbitMQ is the extensibility of the system. It has a very flexible plugin system and a great ecosystem of plugins for extending functionality.
Re Erlang, I'm a bit of an Erlang fan so I'm bound to come off as biased. I think that it's a great foundation for a messaging broker due to the nature of how it works, the functional aspect of the language and the built-in distributed communication constructs.
Memory is handled like most other compiled languages, though it is functional so a bit different than a procedural or OO language. The VM has the same concerns as the Java VM with gc and the like. State for an application is passed through from function to function when using the OTP constructs in the erlang standard library. With regard to memory limits, you can tune the erlang VM just as you can the java VM and while I haven't specifically looked, I'd be surprised if there was not an option to limit the memory utilization.
From a comparison perspective, I'm not terribly deep on QPid's implementation or benefits outside of being an AMQP broker. While I know RabbitMQ internals and the ecosystem, I can not say the same for QPid and would likely make unfair comparisons
Never trust an airline that limits their passengers to one carry on iguana. Put this tiny ad in your shoe: