Problem with half-closure related to connection-reset in Java 11

[Norman Maurer]

> On 29. May 2018, at 22:49, Alan Bateman <Alan.Bateman at 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20180530/5944b535/attachment.html>