JDK-4094893 : (1.x) cached connections should be freed when ServerSocket.accept/Socket create
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.rmi
  • Affected Version: 1.2.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_2.5
  • CPU: sparc
  • Submitted: 1997-11-24
  • Updated: 1999-01-28
  • Resolved: 1999-01-28
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.
Other
1.2.2 1.2.2Fixed
Related Reports
Relates :  
JDK-4161204 - multiplexed connections does not work across firewall
Description
To free up resources in dire circumstances, all cached connections (to
every remote endpoint) should be freed if a ServerSocket "accept" fails
or a Socket creation fails. Either of these operations may fail if the
process has run out of file descriptors, so the transport should reap
any cached resources that may be contributing to the problem.
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.2.2 generic FIXED IN: 1.2.2 INTEGRATED IN: 1.2.2
14-06-2004
PUBLIC COMMENTS RMI should flush (or at least purge) its cache of connections when an I/O error occurs and there's a chance that the error is because the VM's open- socket resource (all right, file descriptors) is depleted.
10-06-2004
EVALUATION adrian.colley@east 1998-01-16 I believe that dropping all connections would thrash badly under saturation. A scheme to close perhaps the 50% of connections which have been idle longest would be more graceful and less fraught with danger. The danger comes from the risk of closing a connection which has just become active after being idle. Because RMI does not yet facilitate deterministic exactly-once execution semantics, closing a server-side connection could very easily cause a perfectly good invocation to fail without possibility of retry. Of course, idle client-side connections are fair game. I suspect, however, that the servers will be the bottlenecks in this game. There is, as yet, no direct support in RMI for closing idle server-side connections, and I'm hesitant to add it, in case things start breaking. If we can somehow inject a magic token into the protocol which distinguishes a dying server from one that is actively shedding connections, then I'm all for it. The above grouchy rantings notwithstanding, I'm only going to implement shedding of client-side connections under heavy load. adrian.colley@east 1998-01-19 Done with changes to TCPChannel and TCPTransport, under branch "shedfd". Awaiting code review. Can't think of a good way to test this. adrian.colley@east 1998-05-04 I have a test now. This code has been sitting idle yet functional since January!
04-05-1998