JDK-4420157 : (perf) heavy loads yield connection refused
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.rmi
  • Affected Version: 1.3.0
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: generic
  • CPU: generic
  • Submitted: 2001-02-28
  • Updated: 2013-04-12
Related Reports
Duplicate :  
Relates :  
Description
Name: boT120536			Date: 02/28/2001


java version "1.2.2"
Java HotSpot(TM) Server VM (2.0fcs, mixed mode, build E)
& 1.3 (which i don't have on the box i'm writing this post on)

C:\>

In sun.rmi.transport.tcp.TCPTransport, right after the ‘accept’, the code goes
on a time consuming operation of creating and starting a new Thread.

When clients connect on a (not very big mass), they out run this code and fill
up the ServerSocket's "waiting for accept" socket queue, which causes further
connection to be refused.

relevant snip from sun.rmi.transport.tcp.TCPTransport:

while (true) {
  ServerSocket myServer = server;
  if (myServer == null)
    // the server socket will be null if another thread
    // attempted to retry creating the server socket
    // and failed.
    return;

  Throwable acceptFailure = null;
  final Socket socket;
	    
  try {
    socket = myServer.accept();
		
    /*
     * Find client host name (or "0.0.0.0" if from behind firewall)
     */
    InetAddress clientAddr = socket.getInetAddress();
    String clientHost = (clientAddr != null ?clientAddr.getHostAddress(): "0.0.0.0");
		
    /*
     * Spawn non-system thread to handle the connection
     */
    Thread t = (Thread) java.security.AccessController.doPrivileged (
        new RMIThreadAction(new ConnectionHandler(socket, clientHost),
            "TCP Connection(" + ++ threadNum + ")-" + clientHost, true, true));
    t.start();
		
  } catch (IOException e) {}
...
}



IMO, this is a very naive implementation. Right after 'accept', the newly
created socket should be put on a queue, and let other thread/s take care of
it, while letting the thread that listens on the ServerSocket to immediately go
back to 'accept'.
(Review ID: 116777) 
======================================================================

Comments
WORK AROUND Name: boT120536 Date: 02/28/2001 A (rather ugly) workaround is to use a custom RMISocketFactory, which creates ServerSockets with a larger backlog value. IMO, The right thing to do is to fix that (not too efficient) code, which can be done in no time, instead of this workaround which requires additional deployment tuning. ======================================================================
11-06-2004

EVALUATION See evaluation for 4447092. peter.c.jones@east 2001-05-03 These issues will be investigated further for Mantis. ###@###.### 2002-07-16 See also 4976198. ###@###.### 2004-01-09
03-05-2001