Closed CodingFabian closed 4 years ago
This could be fixed in 2.1.0. Please verify. Thanks for reporting!
thanks for working on this. Looks like you throw an exception instead of returning -1? Not sure which one is actually correct.
Javadoc of read
says:
the total number of bytes read into the buffer, or -1 if there is no more data because the end of the stream has been reached.
so as long as you differentiate premature closing (which warrants an exception) or just trying to read from the end of the stream, this looks good.
Will try the new version soon and come back.
From what I can see there's no change from 2.0.4 (which docker-java uses) to 2.1.2. AFUNIXInputStream threw an exception on streamClosed
, and still does in 2.1.2. There's still no check to return -1 if closed
in 2.1.2.
Shouldn't EndOfFileTest#clientReadEof catch this case? If not, can you repro the issue with 2.1.2, and perhaps write a test case? Cheers!
Struggling to get the tests on master to pass locally, so trying https://github.com/kohlschutter/junixsocket/pull/56.
The behavior of throwing a SocketException upon trying to read from a closed socket is identical to what happens with vanilla (TCP / java.net) Sockets.
Try copying the two methods into EndOfFileJavaTest, and see that the tests also fail without junixsocket's involvement.
If Docker indeed expects -1 despite violating the java.net API, an easy workaround would be to catch all IOExceptions upon read, checking whether the socket#isClosed, and returning -1 in this case instead.
See the CloseIgnorantInputStream.java for a potential solution that doesn't require patching junixsocket.
In https://github.com/docker-java/docker-java/pull/697 they monkey patched junixsocket in org.newsclub.net.unix.AFUNIXSocketImpl.AFUNIXInputStream.read(byte[], int, int)
I wonder if thats a valid change? I observed at a customer a thread hanging in a socket read at exactly this place:
maybe thats a potential fix?