JDK-6799574 : (so) SocketChannel.setOption throws IOException "Invalid argument"
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 6
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: solaris_10
  • CPU: x86
  • Submitted: 2009-01-30
  • Updated: 2013-04-11
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
tbd_minorUnresolved
Related Reports
Relates :  
Description
(as discussed with Alan, filling an issue) This happens on jdk 5/6/7

Grizzly is suffering performance degradation when setSoLinger and setReuseAddess starts throwing the following exception:

[#|2009-01-26T00:33:56.325-0800|WARNING|sun-appserver9.1|javax.enterprise.system.container.web|_ThreadID=17;_ThreadName=SelectorReaderThread-8084;_RequestID=11ae0030-c392-4217-8408-cfa7efe0a879;|setSoLinger exception
java.net.SocketException: Invalid argument
       at sun.nio.ch.Net.setIntOption0(Native Method)
       at sun.nio.ch.Net.setSocketOption(Net.java:261)
       at sun.nio.ch.SocketChannelImpl.setOption(SocketChannelImpl.java:166)
       at sun.nio.ch.SocketAdaptor.setIntOption(SocketAdaptor.java:296)
       at sun.nio.ch.SocketAdaptor.setSoLinger(SocketAdaptor.java:331)
       at com.sun.enterprise.web.connector.grizzly.SelectorThread.setSocketOptions(SelectorThread.java:1893)
       at com.sun.enterprise.web.connector.grizzly.SelectorReadThread.registerNewChannels(SelectorReadThread.java:93)
       at com.sun.enterprise.web.connector.grizzly.SelectorReadThread.startEndpoint(SelectorReadThread.java:121)
       at com.sun.enterprise.web.connector.grizzly.SelectorThread.run(SelectorThread.java:1223)
|#]

[#|2009-01-26T00:33:56.327-0800|WARNING|sun-appserver9.1|javax.enterprise.system.container.web|_ThreadID=17;_ThreadName=SelectorReaderThread-8084;_RequestID=11ae0030-c392-4217-8408-cfa7efe0a879;|setReuseAddress exception
java.net.SocketException: Invalid argument
       at sun.nio.ch.Net.setIntOption0(Native Method)
       at sun.nio.ch.Net.setSocketOption(Net.java:261)
       at sun.nio.ch.SocketChannelImpl.setOption(SocketChannelImpl.java:166)
       at sun.nio.ch.SocketAdaptor.setBooleanOption(SocketAdaptor.java:286)
       at sun.nio.ch.SocketAdaptor.setReuseAddress(SocketAdaptor.java:399)
       at com.sun.enterprise.web.connector.grizzly.SelectorThread.setSocketOptions(SelectorThread.java:1910)
       at com.sun.enterprise.web.connector.grizzly.SelectorReadThread.registerNewChannels(SelectorReadThread.java:93)
       at com.sun.enterprise.web.connector.grizzly.SelectorReadThread.startEndpoint(SelectorReadThread.java:121)
       at com.sun.enterprise.web.connector.grizzly.SelectorThread.run(SelectorThread.java:1223)
|#] 

This has been discussed here:

https://glassfish.dev.java.net/servlets/ReadMsg?listName=users&msgNo=26597

One user reported: ..that these errors are harmless, however, as you can see below, the throughput of my application was reduced by 50% in the minutes surrounding the spurt of errors:

minute requests  setSoLinger/setReuseAddress exceptions
-----   -----    -
14:23    7620    0
14:24   10063    0
14:25    9714    0
14:26    8847    0
14:28    7370    0
14:29    9787    0
14:30    9104    0
14:31    8171    0
14:32    4066    15 errors in two groups:  8 @ 14:32:33 and 7 @ 14:32:58
14:33    6908    0
14:34   10463    0
14:35    9870    0
14:36    8236    0
14:37    8685    0
14:38    8098    0

My application constantly serves 200-350 requests per second - and has been doing so for 1 week now.  This is the only incident that any errors have been thrown since the application began operation.

FYI.  For every incoming HTTP request, the application makes a UPD call to a backend export control application.  And makes a few socket connections to an external memory cache utilizing the Memcached software.

Is it possible that the UDP service or the memcached server were slow and they caused the errors and the reduction in throughput?

p

Comments
EVALUATION We need support from Solaris to disable the current behavior, see RFE 6850464.
2012-01-07

WORK AROUND An unsupported/undocumented workaround is to set xnet_skip_checks to 1 in /etc/system. Alternatively, in a live system it can be changed via mdb using: # echo "xnet_skip_checks/W 1" | mdb -kw
2009-06-11

EVALUATION setsockopt on Solaris returns -1/EINVAL for cases that might be relevant here: 1. After the connection has been shutdown for write (shutdownOutput method) 2. Connection has been reset (by the peer)
2009-02-03