On Fri, 22 Jan 2021 16:14:26 GMT, Mark Sheppard wrote:
> iteration N write n bytes, reads m where m < n (The underlying TCP protocol
> machine has sent m bytes and not the full n)
> iteration N +1 write n bytes, read n + (n-m) i.e. the current write + the
> residue from the write in iteration N
On Fri, 22 Jan 2021 12:32:09 GMT, Patrick Concannon
wrote:
>> Hi,
>>
>> Could someone please review my fix for JDK-8259628:
>> '`jdk/net/ExtendedSocketOption/AsynchronousSocketChannelNAPITest.java` fails
>> intermittently' ?
>>
>> `AsynchronousSocketChannelNAPITest` is failing intermittently
On Fri, 22 Jan 2021 14:41:44 GMT, Daniel Fuchs wrote:
>> Patrick Concannon has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8259628: Removed buffer check
>
> You could still do some checking if you wanted.
> If you know that you have writ
On Fri, 22 Jan 2021 12:32:09 GMT, Patrick Concannon
wrote:
>> Hi,
>>
>> Could someone please review my fix for JDK-8259628:
>> '`jdk/net/ExtendedSocketOption/AsynchronousSocketChannelNAPITest.java` fails
>> intermittently' ?
>>
>> `AsynchronousSocketChannelNAPITest` is failing intermittently
> Hi,
>
> Could someone please review my fix for JDK-8259628:
> '`jdk/net/ExtendedSocketOption/AsynchronousSocketChannelNAPITest.java` fails
> intermittently' ?
>
> `AsynchronousSocketChannelNAPITest` is failing intermittently on Linux due to
> a race condition caused by not correctly waiting
> Hi,
>
> Could someone please review my fix for JDK-8259628:
> '`jdk/net/ExtendedSocketOption/AsynchronousSocketChannelNAPITest.java` fails
> intermittently' ?
>
> `AsynchronousSocketChannelNAPITest` is failing intermittently on Linux due to
> a race condition caused by not correctly waiting
> Hi,
>
> Could someone please review my fix for JDK-8259628:
> '`jdk/net/ExtendedSocketOption/AsynchronousSocketChannelNAPITest.java` fails
> intermittently' ?
>
> `AsynchronousSocketChannelNAPITest` is failing intermittently on Linux due to
> a race condition caused by not correctly waiting
On Fri, Jan 22, 2021 at 10:18 AM Alan Bateman
wrote:
Yes, URL is really old and much of its legacy behavior cannot be changed
> for compatibility reasons. At some point I think all of its constructors
> need to be deprecated. So if you are making changes to URL then assume
> it will require a lot
On 22/01/2021 08:46, Eirik Bjørsnøs wrote:
Given that this class is @since 1.0 there is probably some resistance
to changing behaviour in this area?
Yes, URL is really old and much of its legacy behavior cannot be changed
for compatibility reasons. At some point I think all of its construct
Hello,
While looking into reducing string allocation in URL constructors, I found
the following somewhat puzzling:
// Throws MUE as expected: "no protocol: 1nvalid://resource"
// Reason: "1nvalid" is not a valid scheme (cannot start with a digit)
// See https://www.ietf.org/rfc/rfc2396.html#secti
10 matches
Mail list logo
