> On 29. May 2018, at 18:26, Alan Bateman <alan.bate...@oracle.com> wrote:
>
> On 29/05/2018 15:26, Norman Maurer wrote:
>> :
>>
>>
>> Yes thats what I am saying… I think if a write fails due a connection-reset
>> a read should still be possible until we are told by the OS that we also hit
>> an error here. Honestly I think this scenario can happen quite often in
>> reality where some software writes while draining data from the socket in
>> chunks. With Java 11 this may lead to the situation where the user may never
>> see the data even when its waiting on the socket to be read which I think is
>> weird. What kind of problems this may cause in different programs is hard to
>> know, but its definitely something that surprised me. Even more after I
>> started to debug and could see the packets via tcpdump etc.
>>
>> Also as a side-note when using SocketChannel this works perfectly fine, as
>> before. I will open a bug with all the informations in this email as
>> requested. I just wanted to make sure first that my observations are correct
>> and wanted to provide as much details as possible ( + making a strong
>> argument to why I think this is a regression).
>>
> I see you've created an issue to the bugs.sun.com system - thanks! I'll move
> that to the JDK project so that it's accessible via bugs.openjdk.java.net.
Oh sorry I thought thats the right system to use. I just followed the wiki page
(I think).
>
> You are right that there is subtle behavior change, something that wasn't
> really intended. The code to manage reading beyond connection resets has
> always been problematic and only ever worked on Solaris. The SocketChannel
> implementation has never attempt to do this, it just reflects the platform
> behavior when reading after a reset.
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.
>
> -Alan.
Thanks
Norman
