JDK-4976198 : (perf) Improve RMI Connection Handling Mechanism
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.rmi
  • Affected Version: 1.3.1
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2004-01-09
  • Updated: 2005-09-20
  • Resolved: 2005-09-20
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6 betaFixed
Related Reports
Relates :  
JDK-4420157 - (perf) heavy loads yield connection refused
Relates :  
JDK-4447092 - Relieve the server-side bottleneck in TCPTransport.run.
Relates :  
JDK-5059346 - (perf) reduce thread creation for scheduling delayed tasks
Description
Name: dk106046			Date: 01/09/2004

Current Implementation of the RMI Mechanism creates a thread(ConnectionHandler) at
TCPTransport layer for every RMI connection. If the application is RMI intensive,
the Thread creation process is an overhead.

IBM JDK has implemented thread pooling in the sun.rmi.transport.tcp.TCPTransport class.  This is not enabled by default. This can be enabled by making the following setting: 
-Dsun.rmi.transport.tcp.connectionPool=true (or any non-null value)

In this implementation of the connection Pool, the RMI connectionHandlers get added to a pool and never get removed.  Since currently there's no fine tuning to control the number of the threads in the pool, enabling the thread pooling is not recommended for applications that have RMI usage only for a brief time during its cycle.  Such applications will have to live with these threads during the off-peak hours as well. 

Applications which are mostly RMI intensive can benefit by enabling the thread poiling as the connection handlers will be reused and there's no overhead of creating these threads for every RMI call.

[This bug is being submitted as a courtesy, in order to maintain uniformity between Sun & IBM JDKs.  It has been fixed in IBM JDKs.  
Please contact ###@###.### if you have questions.]
======================================================================
Comments
EVALUATION Fixed to use a thread pool (java.util.concurrent.ThreadPoolExecutor) for server-side connection handler threads (which are also used to dispatch remote invocations). By default, the maximum number of these threads is unlimited (thus maintaining previous behavior, although perhaps this should be reconsidered in the future) and idle thread keep-alive timeout is one minute (both of these attributes can be varied by setting implementation-specific system properties).
19-09-2005
EVALUATION Yes, using a thread pool for RMI connection handling is desirable-- along with this, it would seem desirable to support (implementation-specific) tuning parameters related to scalability. See also 4420157. ###@###.### 2004-01-09
09-01-2004