On 12/28/2012 3:59 AM, Kevin McMurtrie wrote:
In article <c3WCs.31155$tG.11699@newsfe15.iad>,
Arved Sandstrom <asandstrom2@eastlink.ca> wrote:
On 12/27/2012 03:35 AM, Kevin McMurtrie wrote:
JMS services are typically very heavy weight. Memory and disk
space are
needed to buffer data to nodes that temporarily fall behind or go
offline. Configuration can take a while too.
It's funny how people can come at things from a different perspective.
In my world messaging providers like JMS providers or WMQ (and JMS and
MQ clients) are _lightweight_. I actually stopped and tried to process
your "novel" concept for a few seconds. :-)
They're almost lightweight without the high reliability options, but
those are the same options that cause people to choose JMS rather than
an in-house solution.
That may be how you use message queue solutions.
But there are other that use message queues without the
reliability options.
ActiveMQ is a resource-consuming
beast when faced with reliable delivery to clients that are lagging.
ActiveMQ also has dependencies on half the Internet so it's prone to
creating library conflicts.
????
How?
The ActiveMQ jars and the applications jars should not be
mixed at all. Either different JVM or different apps within the
same app server. Only exception I can think of is embedded
inside an SE app, which is not a common scenario.
client. The best you can do is a trial-and-error process to create