JDK-6799574 : (so) SocketChannel.setOption throws IOException "Invalid argument"
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 6
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: solaris_10
  • CPU: x86
  • Submitted: 2009-01-30
  • Updated: 2018-03-03
  • Resolved: 2018-03-01
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
The referenced RFE 6850464 doesn't seem to be related to this, are you sure that's correct?
01-03-2018

This is a Solaris issue, nothing we can do in the JDK unless there is way to change the OS behavior.
01-03-2018

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

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
11-06-2009

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)
03-02-2009