In my personal experience, very few embed. With that said, there are valid use cases for embedding.
My general advise when using ActiveMQ in most applications is to run it stand-alone. That fits the "separation of concerns" best-practice. Here are some guidelines that may help when choosing: - How complex is the messaging use case? Embedding ActiveMQ with other software increases the overall complexity of the software running in the single JVM. If the messaging is complex (e.g. many destinations, many producers and consumers with complex interactions, etc), then the solution is starting high in complexity and only going higher with embedding. - How much memory will ActiveMQ and the application both use and need? It's important that ActiveMQ not be starved for memory - not only for performance, but also for stability. - Diagnosing the root cause of many problems, such as out-of-memory exceptions, becomes more complicated when ActiveMQ is embedded. - I've been told, by very reliable sources, that ActiveMQ does perform very well for in-JVM queueing; therefore, embedding AMQ strictly for in-JVM queueing is a viable use-case. The desire to simplify AMQ startup doesn't sound compelling to me as a reason to switch to an embedded broker setup. With that said, if the broker is "embedded" by itself in a JVM (i.e. use the java interface to configure and startup the broker and bypass the shell scripts), then the concerns are notably reduced (I generally don't think of this as embedding even though it uses similar techniques to get a broker running). Then my biggest consideration would be supportability. Anyone coming in fresh to understand the broker configuration would need time to learn the custom approach. Hope this helps. -- View this message in context: http://activemq.2283324.n4.nabble.com/To-embed-or-not-to-embed-tp4693381p4693386.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
