geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <james_strac...@yahoo.co.uk>
Subject Re: Status of JMS
Date Tue, 04 Nov 2003 18:32:56 GMT

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/


Mime
View raw message