(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
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
- relates to
-
JDK-7014244 (so) setTcpNoDelay fails with "Invalid argument" on Windows Vista
-
- Closed
-