United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6799574 : (so) SocketChannel.setOption throws IOException "Invalid argument"

Details
Type:
Bug
Submit Date:
2009-01-30
Status:
Open
Updated Date:
2013-04-11
Project Name:
JDK
Resolved Date:
Component:
core-libs
OS:
solaris_10
Sub-Component:
java.nio
CPU:
x86
Priority:
P4
Resolution:
Unresolved
Affected Versions:
6
Targeted Versions:
tbd_minor

Related Reports
Relates:
Relates:

Sub Tasks

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

                                    
                                
(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

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
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

We need support from Solaris to disable the current behavior, see RFE 6850464.
                                     
2012-01-07
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
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

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



Hardware and Software, Engineered to Work Together