On 4 Nov 2003, at 17:08, Bruce Snyder wrote:
This one time, at band camp, James Strachan said:
JS>On 4 Nov 2003, at 16:22, Noel J. Bergman wrote:
JS>>> I'd rather explore JMX, I've been looking at JBOSS 4 and its JMX
JS>>> architecture seems to describe what I'd like to see James have.
JS>>
JS>> JMX and JMS don't serve the same purposes. JMS *might* (and I stress
JS>> that
JS>> it is only a possibility, and not one that I'm overly convinced about)
JS>> provide a spool implementation.
JS>>
JS>>> I'm certainly not convinced that JMS is really the best approach. It
JS>>> would
JS>>> be sadly ironic if we end up with James performance suffering because
JS>>> of
JS>>> JMS queue issues.
Unless there's a damn good reason for it (and it's entirely possible that
I'm missing something) I disagree that JMS should be used from intra-VM
messaging between threads.
I never said that JMS *should* be used for intra-VM messaging between threads! :)
AFAIK, the intent of JMS is inter-VM messaging for purposes of decoupling. Please correct me if my understanding is wrong.
Absolutely. This thread started with Noel saying he wanted to use JMS - with the assumption being that distribution was involved. If all you need is an in-JVM queue then use a Vector :)
JMX is another issue entirely. JMX is for managability of components. It's
got nothing to do with messaging.
Agreed.
Though there's now a remoting part to JMX. So you could use JMS underneath the covers of JMX remoting - just to muddy the waters some more :).
JS>I doubt that a decent JMS implementation would ever be slower than a
JS>hand-hacked-together communication mechanism (especially if things like
JS>flow control, auto-reconnect and so on are requirements). Though it
JS>depends what you're trying to do I guess.
JS>
JS>
JS>>> OTOH if it works I'm for it. :-)
JS>>
JS>> That is my position, as well. Considering that I used to write
JS>> real-time
JS>> embedded kernels for a living (albiet a couple of decades ago),
JS>> performance
JS>> is never far from my mind. Personally, I think that JMS is overkill,
JS>> but it
JS>> has been recommended that we look at it, so I'm asking the geronimo
JS>> team
JS>> what the status is so that we can evaluate. I've other alternatives in
JS>> mind, as well.
JS>
JS>I'd use OpenJMS or JGroups for now. There is no JMS implementation
JS>inside Geronimo yet & I can't imagine there would be one for a while.
As far as JMS is concerned, I'd like to use OpenJMS simply because I use
it now and I really like it's feature set. But I'm not sure what issues
lie in wait from the Intalio side. The other one that I'm interested in
JORAM from ObjectWeb.
JGroups is out of the question for Geronimo because of license. It's LGPL.
There's a BSD abstraction wrapper being developed right now, so soon we'll be able to use JGroups
https://jcluster.dev.java.net/
James ------- http://radio.weblogs.com/0112098/
