JDK-8029073 : (corba) New connection reclaimed when number of connection is greater than highwatermark
  • Type: Bug
  • Component: other-libs
  • Sub-Component: corba
  • Affected Version: 6u45
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2013-11-25
  • Updated: 2014-10-15
  • Resolved: 2014-04-04
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 JDK 7 JDK 8 JDK 9
6u81Fixed 7u76Fixed 8u20Fixed 9 b08Fixed
Description
Logs show that the reclaim procedure chooses the new connections to close.
Comments
From the debug analysis, it appears that the default values for ORBHighWaterMark, ORBLowWaterMark, and ORBNumberToReclaim (240, 100, 5). If this issue has occurred in the context of a scalable server, it may be work investigating alternative higher values for these ORB properties (com.sun.CORBA.connection.{ORBHighWaterMark, ORBLowWaterMark, ORBNumberToReclaim} )
25-11-2013
as per the prosed fix in the bug db report, it may be necessary to set the timestamp on the new connection within the CorbaConnectionCacheBase.put() operation otherwise there would appear to be the possibility of a concurrent reclaim executing between the cache put and the setting of the timestamp on the new connection within the SocketOrChannelAcceptorImpl.accept() consider the following as an alternative: public void put(Acceptor acceptor, Connection connection) { if (orb.transportDebugFlag) { dprint(".put: " + acceptor + " " + connection); } synchronized (backingStore()) { connectionCache.add(connection); connection.setConnectionCache(this); this.stampTime(connection);. dprintStatistics(); } }
25-11-2013