Details
-
Bug
-
Resolution: Not an Issue
-
P4
-
None
-
11.0.10, 15.0.2, 17
-
Linux study04 5.4.0-66-generic #74-Ubuntu SMP Wed Jan 27 22:54:38 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
openjdk version "17-ea" 2021-09-14
OpenJDK Runtime Environment (build 17-ea+12-906)
OpenJDK 64-Bit Server VM (build 17-ea+12-906, mixed mode, sharing)openjdk version "15.0.2" 2021-01-19
OpenJDK Runtime Environment AdoptOpenJDK (build 15.0.2+7)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 15.0.2+7, mixed mode, sharing)openjdk version "11.0.10" 2021-01-19
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.10+9)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.10+9, mixed mode)openjdk version "1.8.0_282"
OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_282-b08)
OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.282-b08, mixed mode)Linux study04 5.4.0-66-generic #74-Ubuntu SMP Wed Jan 27 22:54:38 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux openjdk version "17-ea" 2021-09-14 OpenJDK Runtime Environment (build 17-ea+12-906) OpenJDK 64-Bit Server VM (build 17-ea+12-906, mixed mode, sharing) openjdk version "15.0.2" 2021-01-19 OpenJDK Runtime Environment AdoptOpenJDK (build 15.0.2+7) OpenJDK 64-Bit Server VM AdoptOpenJDK (build 15.0.2+7, mixed mode, sharing) openjdk version "11.0.10" 2021-01-19 OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.10+9) OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.10+9, mixed mode) openjdk version "1.8.0_282" OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_282-b08) OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.282-b08, mixed mode)
-
x86_64
-
linux
Description
Under load, a call to ServerSocketChannel.accept() can return an identical SocketChannel (same protocol, client IP/port and server IP/port) to the SocketChannel returned from the previous accept() call. This should not be possible.
A test case is available at:
https://github.com/markt-asf/duplicate-socket
The steps to reproduce are:
- Start the NetworkTest java application
- From separate console windows, run at least two instance of the following: `for i in {1..50}; do /opt/wrk/wrk -t 2 -c 1000 -d 5s --latency --timeout 1s --script ./myPost.lua http://localhost:8080/post; done`
Adjust path to wrk as appropriate.
There does appear to be a timing element to this test and running more instances of the above wrk loop in additional console windows may increase the likelihood of triggering the error.
Sample output is attached.
openjdk-17-console.txt shows that two SocketChannel instances were returned and both were for the same protocol, client IP/port and server IP/port combination. The client port is 33314
openjdk-17.pcapng shows the wireshark capture of all traffic to server port 8080 during the test. Filtering for "tcp.port=33314" shows only a single network connection from that client port to the server.
openjdk-17.hprof is the heap dump generated as soon as the error was detected. It shows two SocketChannel instances (NetworkTest.currentConnection and NetworkTest.previousConnection) both with client port 33314 as expected from the console output. An examination of the heap dump shows the SocketChannel instance have sequential file descriptors. Otherwise both appear to be identical. Both SocketChannels are valid and open.
I have been able to recreate this with the latest:
- OpenJDK Java 17 EA build
- Adopt OpenJDK Java 15 release
- Adopt OpenJDK Java 11 release
- Adopt OpenJDK Java 8 release
This issue was originally observed as part of the investigation into this Spring WebFlux / Apache Tomcat issue:
https://github.com/spring-projects/spring-framework/issues/26434
A test case is available at:
https://github.com/markt-asf/duplicate-socket
The steps to reproduce are:
- Start the NetworkTest java application
- From separate console windows, run at least two instance of the following: `for i in {1..50}; do /opt/wrk/wrk -t 2 -c 1000 -d 5s --latency --timeout 1s --script ./myPost.lua http://localhost:8080/post; done`
Adjust path to wrk as appropriate.
There does appear to be a timing element to this test and running more instances of the above wrk loop in additional console windows may increase the likelihood of triggering the error.
Sample output is attached.
openjdk-17-console.txt shows that two SocketChannel instances were returned and both were for the same protocol, client IP/port and server IP/port combination. The client port is 33314
openjdk-17.pcapng shows the wireshark capture of all traffic to server port 8080 during the test. Filtering for "tcp.port=33314" shows only a single network connection from that client port to the server.
openjdk-17.hprof is the heap dump generated as soon as the error was detected. It shows two SocketChannel instances (NetworkTest.currentConnection and NetworkTest.previousConnection) both with client port 33314 as expected from the console output. An examination of the heap dump shows the SocketChannel instance have sequential file descriptors. Otherwise both appear to be identical. Both SocketChannels are valid and open.
I have been able to recreate this with the latest:
- OpenJDK Java 17 EA build
- Adopt OpenJDK Java 15 release
- Adopt OpenJDK Java 11 release
- Adopt OpenJDK Java 8 release
This issue was originally observed as part of the investigation into this Spring WebFlux / Apache Tomcat issue:
https://github.com/spring-projects/spring-framework/issues/26434