JDK-6984182 : Setting SO_RCVBUF/SO_SNDBUF to larger than tcp_max_buf fails on Solaris 11 if kernel params changed
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 7
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris
  • CPU: x86
  • Submitted: 2010-09-13
  • Updated: 2012-03-22
  • Resolved: 2011-03-08
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.
6u23Fixed 7 b121Fixed
Related Reports
Relates :  
Relates :  
Relates :  


fail starting jdk 7 b109. Pass b108.
seems to be solaris11-specific

EVALUATION 6989190 is tracking the first step to resolving this one. Once 6989190 is in a promoted build (probably b114) then the fallback values will correspond to the default limits (1MB for tcp, 2MB for udp) and and so the JCK failures reported should disappear. We are still left with the scenario where these parameters have been changed from their default value so I will keep this bug open to track that.

EVALUATION api/java_nio/channels/FileChannel/index.html#Methods[FileChannel0024] is a genuine failure and arises when FileChannel.transferFrom(ReadableByteChannel,long,long) is called with a FileChannel that is not readable and the file size is 0. I've separated this one out into its own bug: 6984545. The other failures are Solaris 11 specific. When setting SO_RCVBUF or SO_SNDBUF then we query the /dev/tcp driver's tcp_max_buf property to limit the size. This is done with the ND_GET command and the I_STR ioctl. This is failing on snv146 (okay in snv122, which some of our test machines have). It turns out that this interface has been removed in Solaris 11 and so we need to find another way to get the value of tcp_max_buf.