RMI Not Scalable?

More and more I am finding RMI to not be a scalable solution for me. For
example, I have a system that could have upwards of 5000 hosts. While
there is only one server in the classic sense, the other nodes have
callbacks so they are also technically RMI servers and clients.

The communication between all these hosts and the "server" use a pretty
classic model to minimize concurrent socket usage on the "server". There
are async calls that just deposit runnable object into the server's
thread queue and return and sync calls that do the same thing but also
register a listener in a local thread waiting for a callback. In this
way, for long sync tasks the socket only needs to be open long enough to
deposit the runnable, and the "server" then notifies the client who is
blocking for response on a callback object. 


C sends task (including callback) to S 
        -- the connection is done afterwards
C waits in local thread pool for the callback 
        -- requires no connection to S
S completes task an sends result to C using callback 
        -- a new connection just for the callback


The problem is that even with a few hundred C hosts, the "server" can
get an incredible number of threads for RMI Connection,
ConnectionExpiration, and RenewClean. 

So while I've designed my system to minimize the amount of long-lived
sockets (which is pretty important) I've created a new problem which is
a buttload of threads on the "server".

So my questions are this. 

1. Should I just stop using RMI? I could always use my
RMISSLSocketFactory directly and use Marshaled objects directly --
bypassing RMI completely.

2. If I know that my C Remote Listener and "server" remote interfaces
are singleton instances that live as long as the application does, is
there a way to disable (or at least minimize) the creation of RenewClean
threads?

3. Why is there a different thread for each ConnectionExpiration on the
"server"? I would think there would be just one thread for ALL endpoints
and I would only spawn a thread when I need to do something (like
expiration), otherwise there would be just one expiration thread.

My guess is that RMI is wired so tightly that there is no way for me to
change the way #2 or #3 work, so that brings me back to #1.

R.

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff RMI-USERS".  For general help, send email to
[email protected] and include in the body of the message "help".

For a list of frequently asked RMI questions please refer to:
http://java.sun.com/j2se/1.3/docs/guide/rmi/faq.html

To view past RMI-USERS postings, please see:
http://archives.java.sun.com/archives/rmi-users.html