JDK-8208479 : Content of Socket's InputStream inaccessible after write when closing
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 8,11
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • OS: windows_7
  • CPU: x86_64
  • Submitted: 2018-07-29
  • Updated: 2022-02-14
  • Resolved: 2022-02-14
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
tbdResolved
Description
ADDITIONAL SYSTEM INFORMATION :
Could reproduce on:
Windows 7 jdk1.8.0_091, jdk1.8.0_111 and jdk1.8.0_172

Could not reproduce on:
Debian 9.3 open-jdk1.8.0_171
ArchLinux open-jdk1.8.0_172

A DESCRIPTION OF THE PROBLEM :
Unread content of Socket's InputStream should be readable even after the close of the socket. This is the case but when writing something in the output stream before reading, it interferes and makes a read error when trying to read the remaining bit of information. The problem occurs everytime I run the code, it is pretty consistent.

REGRESSION : Last worked in version 8u162

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the specified test case

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
1
2

The writing error may or may not appear, the important part is that 2 should be read.
ACTUAL -
1
java.net.SocketException: Software caused connection abort: recv failed
	at java.net.SocketInputStream.socketRead0(Native Method)
	at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
	at java.net.SocketInputStream.read(SocketInputStream.java:171)
	at java.net.SocketInputStream.read(SocketInputStream.java:141)
	at java.net.SocketInputStream.read(SocketInputStream.java:224)
	at SocketTTest.lambda$main$0(SocketTTest.java:45)
	at java.lang.Thread.run(Thread.java:748)
Error reading


---------- BEGIN SOURCE ----------
public static void main(String[] args) throws Throwable
	{
		new Thread(() -> {
			try
			{
				ServerSocket serverSocket = new ServerSocket(5555);

				while(true)
				{

					//keep listening
					Socket socket = serverSocket.accept();

					InputStream in = socket.getInputStream();

					System.out.println(in.read());

					Thread.sleep(2000);

					try
					{
						socket.getOutputStream().write(3);
					}
					catch(Throwable ex)
					{
						System.out.println("Error writing");
						ex.printStackTrace();
					}

					System.out.println(in.read());

					in.close();
					socket.close();
					System.exit(0);
				}
			}
			catch(Throwable ex)
			{
				System.out.println("Error reading");
				ex.printStackTrace();
			}
		}).start();

		Thread.sleep(100);
		Socket socket = new Socket("localhost", 5555);
		OutputStream out = socket.getOutputStream();
		out.write(1);
		out.write(2);
		out.close();
		socket.close();

		Object object = new Object();

		synchronized(object)
		{
			object.wait();
		}
	}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Didn't find one, would love to have one

FREQUENCY : always



Comments
That behavior is by design. What happens here is that the client sends some data, then closes the connection. The server reads some of the data, then sends a response. When the response reaches the client host, that host generates a RST packet, because the client application is no longer interested in any data on that socket. When the server host receives the RST packet, it closes the socket, discarding all buffered data. The presented reproducer may succeed if the server manages to read the buffered data before it receives the RST packet.
14-02-2022

Seems like the description contradicts itself? " Could reproduce on: Windows 7 jdk1.8.0_091, jdk1.8.0_111 and jdk1.8.0_172 ... REGRESSION : Last worked in version 8u162" So it reproduces on Windows 7 with jdk1.8.0_111, then works/passes with 8u162, then fails again with jdk1.8.0_172 . Could this flip-flop behaviour really be the case?
13-08-2018

To reproduce , run the attached test case: JDK 8u181 - Fail JDK 11-ea+22 - Fail Output: 1 Error reading java.net.SocketException: Software caused connection abort: recv failed at java.base/java.net.SocketInputStream.socketRead0(Native Method) at java.base/java.net.SocketInputStream.socketRead(SocketInputStream.java:115) at java.base/java.net.SocketInputStream.read(SocketInputStream.java:168) at java.base/java.net.SocketInputStream.read(SocketInputStream.java:140) at java.base/java.net.SocketInputStream.read(SocketInputStream.java:200) at JI9056328.lambda$main$0(JI9056328.java:38) at java.base/java.lang.Thread.run(Thread.java:834)
30-07-2018