Re: RMI Not Scalable?

Thanks Peter, this is helpful information. 

-----Original Message-----
From: Peter Jones - JavaSoft East [mailto:[email protected]] 
Sent: Monday, June 27, 2005 9:46 PM
To: Robert DiFalco
Cc: [email protected]
Subject: Re: RMI Not Scalable?

> 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.

The first two kinds only while there are corresponding connections open
(inbound and outbound, respectively)?

The number of "RenewClean" threads is the subject of this RFE:

        http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5053529

And the number of "ConnectionExpiration" threads is part of the subject
of this RFE:

        http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5059346

> 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?

With the J2SE RMI API or its current implementation, not directly
(independent of the number of live remote references to distinct
endpoints in the VM).  One workaround would be to store each callback
remote reference in S only in marshalled form (or pass it to S in
marshalled form), only unmarshalling it when it is needed to make the
result callback.

(Note that JERI supports exporting remote objects that do not
participate in DGC and thus do not incur its overhead.)

> 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.

Yes, that is the point of 5059346.

Note that with the current implementation, a "ConnectionExpiration"
thread only runs while there are idle outbound connections to the
associated endpoint.  The timeout for closing such idle connections can
be controlled with the "sun.rmi.transport.connectionTimeout"
system property, which has a default value of 15000 (15 seconds).
Setting this property in S to a lower value (but not 0...) may reduce
the typical number of simultaneous "ConnectionExpiration" threads.

-- Peter

===========================================================================
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