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

2018-05-30 Thread Norman Maurer


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

Bye
Norman




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

2018-05-30 Thread Norman Maurer


> On 30. May 2018, at 09:14, Norman Maurer  wrote:
> 
> 
> 
>> On 29. May 2018, at 22:49, Alan Bateman > > 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..

I added a reproducer which not uses any netty classes to the PR that for now 
ignores test-failures caused by this when running on Java11+:

https://github.com/netty/netty/pull/7984#issuecomment-393071386 


Hopefully this is useful to you.

This one fails when running on Linux with Java11 but pass with Java10 and 
earlier.


> 
> 
>> 
>> -Alan
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8203937 
>> 
> 
> Bye
> Norman

Bye
Norman