> On 29. May 2018, at 22:49, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 29/05/2018 17:28, Norman Maurer wrote: >> : >> Oh sorry I thought thats the right system to use. I just followed the wiki >> page (I think). > bugs.sun.com or bugreport.java.com is the right place. That routes the bugs > to the JIRA, just not automatically to the right project as often issues need > to be filtered or deleted. The bug tracking is JDK-8203937 [1]. > > >> : >> Well it seems like it worked before on linux as well ? I mean with Java10 it >> seems to at least not fail on linux the same way as now. >> > The only platform that I'm aware of that will report the reset when reading > and allow reading beyond the reset is Solaris and this is only because of the > way that it reports networking errors to applications. I think the behavior > change you observe is because the reset is reported when writing and this is > impacting the reading from the java.net.Socket. This is really odd behavior > that has been there since JDK 1.4, just not noticed because it would attempt > to read until it got the reset. This is all unspecified behavior so this is > why the testing with the changes in JDK 11 didn't show up anything. I agree > we should just eliminate this so that it doesn't impact the read.
Yes exactly… I am only talking about the scenario here of have the write error directly affect the read path without even trying to read from the underlying fd. > > Would you have cycles to create a small, and standalone test, that > demonstrates the issue? This could be something we turn into a regression > test to test behavior. Let me see.. > > -Alan > > [1] https://bugs.openjdk.java.net/browse/JDK-8203937 > <https://bugs.openjdk.java.net/browse/JDK-8203937> Bye Norman
