OpenJMS Scalability

We have a distributed java application that does a lot of scientific 
computations on a Linux cluster.  In our environment we may start a job 
that runs on 16 or 32 nodes and may run for several days before 
completing.  The decomposition is pretty simple so there typically isn't 
a lot of node to node communication required once the initialization 
gets completed.  However there are  cases where a node will query all 
the other nodes.  A simple example would be to find out their status. 

In the current implementation we use RMI to do the communications.  For 
clusters with a reasonable number of nodes (<128) everything is fine.  
However we are now starting to see clusters with 1000's of nodes and our 
current design and implementation doesn't scale that well. 

We've investigated several alternatives like;
 - Moving everything to 64 bit.  We have a lot of native code and 
dependencies which make this difficult.  This is going to happen it just 
takes time and this doesn't address the design issues it just allows for 
more resource to be available before running into problems.
 - We've looked at using MPI via one of the java wrappers.   Maybe I'm 
looking in the wrong places but there doesn't seem to be a lot of 
activity related to these implementations and there are some thread 
safety concerns.
 - We just started investigating JMS.

Has anybody used OpenJMS in this type of environment.  I've started 
looking at the examples and am going to write a few prototypes but if 
anybody has been in a similar scenario please let me know what you found 
out.
 - Can the openJMS server deal with thousands of subscribers or is the 
technology designed to deal with a smaller number of subscribers and 
deliver large numbers of messages?
 - Are there other implementations of the JMS that are optimized for 
different types of utilization patterns?
 - What kind of latency should we expect?

Thanks,
Steve








----------------------------------------------------------------------
This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient.  Any review, use, distribution, or disclosure by others is strictly prohibited.  If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php