Re: [9] Review request : JDK-6933879: URISyntaxException when non-alphanumeric characters are present in scope_id

[Chris Hegarty]

On 21.01.2015 16:06, Konstantin Shefov wrote:

Hi, Chris

I have done a pre-integration testing for this fix on Linux, Windows,
Mac and Solaris x64 and sparc. I have run all regression tests for
core libraries, and no new failures appeared.

Can I push this change now or should I wait for an approve by one more
person?


You have a Reviewer, and I see no objections. So you are good to push.

-Chris.


Thanks
-Konstantin

On 16.01.2015 17:02, Chris Hegarty wrote:

On 16/01/15 12:50, Konstantin Shefov wrote:

Hi Chris, Alan, thank you for reviewing.

I have made a new webrev
http://cr.openjdk.java.net/~kshefov/6933879/webrev.01
I have removed ":" and added a test case.


This looks ok to me.

-Chris.


-Konstantin

16.01.2015 14:42, Chris Hegarty пишет:

On 16/01/15 11:29, Alan Bateman wrote:

On 16/01/2015 10:49, Chris Hegarty wrote:

:

I don't see any reason to update the spec here, given that the
set of
allowable character is not clearly defined in the relevant RFC's.


I think we need to create a bug to look into this more. Inet6Address
allows the scope of be any String but URI puts restrictions on
what is
legal. The proposed change updates the list of allowed characters
but I
assume it will need to re-visited again as systems with more exotic
interface names are encountered.


Yes that is possible, but to date this is the first time I've seen
this come up.

Given the lack of clear specification in the relevant RFC's (relating
to scope ids ), I don't think we should be making too many
specification changes in this area. But I agree with your comment, URI
has a restriction that it not clearly specified in the Java spec.

-Chris.

Re: [9] Review request : JDK-6933879: URISyntaxException when non-alphanumeric characters are present in scope_id

[Alan Bateman]

On 23/01/2015 10:28, Chris Hegarty wrote:

On 21.01.2015 16:06, Konstantin Shefov wrote:

Hi, Chris

I have done a pre-integration testing for this fix on Linux, Windows,
Mac and Solaris x64 and sparc. I have run all regression tests for
core libraries, and no new failures appeared.

Can I push this change now or should I wait for an approve by one more
person?


You have a Reviewer, and I see no objections. So you are good to push.

Can you make sure to link this to a new issue to look at the spec issue 
that this exposes?


-Alan

[8u-dev] Request for approval: JDK-6933879: URISyntaxException when non-alphanumeric characters are present in scope_id

[Konstantin Shefov]

Hello,

Please approve the direct backport of the bug fix to 8u-dev

Patch applies cleanly to JDK 8u.

The bug:https://bugs.openjdk.java.net/browse/JDK-6933879
The webrev: http://cr.openjdk.java.net/~kshefov/6933879/webrev.01/

JDK 9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/801eb37fc6c4
Review thread: 
http://mail.openjdk.java.net/pipermail/net-dev/2015-January/008834.html


Thanks
-Konstantin

RFR 8071424: JCK test api/java_net/Socket/descriptions.html#Bind crashes on Windows

[Chris Hegarty]

This is a fix for a minor oversight when refactoring the initializing of 
Inet[4|6]Address IDs, used in many places in the networking native code.


It would appear that there is an initInetAddressIDs() call missing from 
the Windows Dual Stacks Socket implementation, 
Java_java_net_DualStackPlainSocketImpl_initIDs.  An existing test has 
been amended to cover this.


http://cr.openjdk.java.net/~chegar/8071424/webrev.00/webrev/

-Chris.

Re: [8u-dev] Request for approval: JDK-6933879: URISyntaxException when non-alphanumeric characters are present in scope_id

[Seán Coffey]

Konstantin,

can you hold off pushing this fix to jdk8u for the moment ? It's a P4 
and could have behavioural consequences (something we try and avoid in 
update releases). I see JDK-8071458 was logged to track IPv6 scope 
specifications. Let's see how this soaks into JDK 9 over coming days and 
let's see how JDK-8071458 progresses.


regards,
Sean.

On 23/01/15 12:56, Konstantin Shefov wrote:

Hello,

Please approve the direct backport of the bug fix to 8u-dev

Patch applies cleanly to JDK 8u.

The bug:https://bugs.openjdk.java.net/browse/JDK-6933879
The webrev: http://cr.openjdk.java.net/~kshefov/6933879/webrev.01/

JDK 9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/801eb37fc6c4
Review thread: 
http://mail.openjdk.java.net/pipermail/net-dev/2015-January/008834.html


Thanks
-Konstantin

Re: Backporting the TCP loopback fast path (Windows) improvement to OpenJDK v7

[Seán Coffey]

Valeriy,

I didn't see a follow up on this. I've modified the patch so that we 
cater for a possible WSAEINVAL error to be returned from the 
NET_EnableFastTcpLoopback call. Latest webrev :

http://cr.openjdk.java.net/~coffeys/webrev.8060170.7u.v2/webrev/

changes only in 
http://cr.openjdk.java.net/~coffeys/webrev.8060170.7u.v2/webrev/src/windows/native/sun/nio/ch/Net.c.cdiff.html


Good to push ? I'll try and get this into 7u80 but can't guarantee that 
now given that we've entered the rampdown/stabilization phase.


regards,
Sean.

On 15/01/15 12:09, Seán Coffey wrote:

Valeriy,

I used the jdk7u patch that was attached to the mail request. It 
applied cleanly. I've posted webrev here for reference (patch there 
also):

http://cr.openjdk.java.net/~coffeys/webrev.8060170.7u/webrev/

The new WSAIoctl call would appear to be failing with WSAEINVAL. The 
NET_EnableFastTcpLoopback call already tests for WSAEOPNOTSUPP - maybe 
we should test for WSAEINVAL also and perhaps return silently if 
windows don't support the option. Or maybe - we state this as desired 
behaviour - i.e this option is suitable for modern windows kernels - 
your note below would contradict what I'm seeing though.


The test passes for me on Windows 7 and fails on Windows XP.

regards,
Sean.

On 15/01/2015 11:15, Valery Kopylov (Akvelon) wrote:

Hi Sean,

Our TCP loopback implementation should process the option correctly 
on older windows kernels. I tried to reproduce the issue, but it 
works fine on my side. So I have an assumption that part of the code 
present on jdk9 patch has been lost and this causes such errors.
Did you use the patch for jdk7 sent by Martin or perform the 
backporting from jdk8 or 9 by yourself?

Could you please send me output of "hg diff" command in jdk folder?


Best regards,
Valeriy Kopylov

-Original Message-
From: Seán Coffey [mailto:sean.cof...@oracle.com]
Sent: Tuesday, January 13, 2015 22:31
To: Martin Sawicki (MS OPEN TECH); jdk7u-...@openjdk.java.net
Cc: Valery Kopylov (Akvelon); Kirk Shoop (MS OPEN TECH); Alan Bateman
Subject: Re: Backporting the TCP loopback fast path (Windows) 
improvement to OpenJDK v7


Hi Martin,

I've run into a problem in backporting this to JDK 7u. The test fails 
on our build/test systems. (windows XP) -

reason: User specified action: run main/othervm
-Djdk.net.useFastTcpLoopback StressLoopback elapsed time (seconds):
0.64
STDOUT:
STDERR:
java.net.SocketException: Invalid argument: fastLoopback
at sun.nio.ch.Net.socket0(Native Method)
at sun.nio.ch.Net.serverSocket(Net.java:445)
at 
sun.nio.ch.AsynchronousServerSocketChannelImpl.(AsynchronousServerSocketChannelImpl.java:71)
at 
sun.nio.ch.WindowsAsynchronousServerSocketChannelImpl.(WindowsAsynchronousServerSocketChannelImpl.java:69)
at 
sun.nio.ch.WindowsAsynchronousChannelProvider.openAsynchronousServerSocketChannel(WindowsAsynchronousChannelProvider.java:83)
at 
java.nio.channels.AsynchronousServerSocketChannel.open(AsynchronousServerSocketChannel.java:140)
at 
java.nio.channels.AsynchronousServerSocketChannel.open(AsynchronousServerSocketChannel.java:161)

at StressLoopback.main(StressLoopback.java:42)
This seems to be from the fact that the new SIO_LOOPBACK_FAST_PATH 
IOCTL code is only supported on more modern windows systems. I'm 
wondering if we should change the src code to not attempt to use this 
option on older windows kernels or if I should just modify the 
testcase to not run the test on older windows systems ?


regards,
Sean.



On 09/01/2015 16:25, Martin Sawicki (MS OPEN TECH) wrote:

Sean, thank you for the update and your assistance. Looking forward.

-Original Message-
From: Seán Coffey [mailto:sean.cof...@oracle.com]
Sent: Friday, January 09, 2015 8:24 AM
To: Martin Sawicki (MS OPEN TECH); jdk7u-...@openjdk.java.net
Cc: Valery Kopylov (Akvelon); Kirk Shoop (MS OPEN TECH)
Subject: Re: Backporting the TCP loopback fast path (Windows)
improvement to OpenJDK v7

Hey Martin,

I can help in getting this enhancement ported to jdk7u-dev. I'm just 
waiting on approval for use of new system property in jdk7u release.

Once I have that, I can get this in.

regards,
Sean.

On 08/01/15 20:01, Martin Sawicki (MS OPEN TECH) wrote:

Hello again,
We'd like to propose to back-port our TCP loopback fast path 
performance improvement for Windows that was recently accepted into 
OpenJDK v9 and v8 into v7.
Just for reference, the original OpenJDK v9 fix just for reference 
can be found here: 
http://hg.openjdk.java.net/jdk9/dev/jdk/rev/26e6402772c8.


Our suggested webrev patch file for OpenJDK *v7* is attached to 
this message, based on our understanding of the back-porting steps.


Your review and acceptance of this contribution would be appreciated.

Best regards,
Martin Sawicki (and Kirk Shoop, and Valeriy Kopylov) Microsoft Open
Technologies, Inc.
A subsidiary of Microsoft Corp.

Re: RFR 8071424: JCK test api/java_net/Socket/descriptions.html#Bind crashes on Windows

[Alan Bateman]

On 23/01/2015 13:51, Chris Hegarty wrote:
This is a fix for a minor oversight when refactoring the initializing 
of Inet[4|6]Address IDs, used in many places in the networking native 
code.


It would appear that there is an initInetAddressIDs() call missing 
from the Windows Dual Stacks Socket implementation, 
Java_java_net_DualStackPlainSocketImpl_initIDs.  An existing test has 
been amended to cover this.


http://cr.openjdk.java.net/~chegar/8071424/webrev.00/webrev/

-Chris.
This looks okay to me. So has this always been missing or did it get 
deleted by something else?


-Alan

Re: RFR 8071424: JCK test api/java_net/Socket/descriptions.html#Bind crashes on Windows

[Chris Hegarty]

On 23/01/15 14:05, Alan Bateman wrote:

On 23/01/2015 13:51, Chris Hegarty wrote:

This is a fix for a minor oversight when refactoring the initializing
of Inet[4|6]Address IDs, used in many places in the networking native
code.

It would appear that there is an initInetAddressIDs() call missing
from the Windows Dual Stacks Socket implementation,
Java_java_net_DualStackPlainSocketImpl_initIDs.  An existing test has
been amended to cover this.

http://cr.openjdk.java.net/~chegar/8071424/webrev.00/webrev/

-Chris.

This looks okay to me. So has this always been missing or did it get
deleted by something else?


It has been missing from the original refactoring :-( just unnoticed as 
other code typically cause the initialization. Good news is that we now 
have better test coverage to catch this.


-Chris.

Re: RFR: 8065994: HTTP Tunnel connection to NTLM proxy reauthenticates instead of using keep-alive

[Chris Hegarty]

Looks good to me Sean.

Good to see additional logging in this area.

-Chris.

On 22/01/15 15:21, Seán Coffey wrote:

Looking for a review around this issue that came in as a reported
performance regression in NTLM proxy authentication. It turned out that
HttpsClients were being discarded after Proxy SocketAddress equality
tests failed. Lack of caching is expensive in terms for performance for
TLS and needless handshakes. The 2nd round of NTLM authentication was
passing in a Proxy which had a resolved SocketAddress. The previous
Proxy creation for the same connection (via DefaultProxySelector)
constructs Proxy using unresolved socketAddress.  Proposed fix is to
compare like with like and have Proxy construct with unresolved Address.

I captured more details in bug report. I'm also using this opportunity
to adding some extra logging to the HttpsClient class and to correct a
bad null versus NO_PROXY test that existed (line 339)

bug report : https://bugs.openjdk.java.net/browse/JDK-8065994
webrev : http://cr.openjdk.java.net/~coffeys/webrev.8065994/webrev/

regards,
Sean.

RE: Backporting the TCP loopback fast path (Windows) improvement to OpenJDK v7

[Martin Sawicki (MS OPEN TECH)]

Sorry about the delay. Valeryi has prepared a patch - he'll be responding soon.

From: Seán Coffey [mailto:sean.cof...@oracle.com]
Sent: Friday, January 23, 2015 5:55 AM
To: Valery Kopylov (Akvelon); Martin Sawicki (MS OPEN TECH); 
jdk7u-...@openjdk.java.net
Cc: Kirk Shoop (MS OPEN TECH); OpenJDK Network Dev list
Subject: Re: Backporting the TCP loopback fast path (Windows) improvement to 
OpenJDK v7

Valeriy,

I didn't see a follow up on this. I've modified the patch so that we cater for 
a possible WSAEINVAL error to be returned from the NET_EnableFastTcpLoopback 
call. Latest webrev :
http://cr.openjdk.java.net/~coffeys/webrev.8060170.7u.v2/webrev/

changes only in 
http://cr.openjdk.java.net/~coffeys/webrev.8060170.7u.v2/webrev/src/windows/native/sun/nio/ch/Net.c.cdiff.html

Good to push ? I'll try and get this into 7u80 but can't guarantee that now 
given that we've entered the rampdown/stabilization phase.

regards,
Sean.
On 15/01/15 12:09, Seán Coffey wrote:
Valeriy,

I used the jdk7u patch that was attached to the mail request. It applied 
cleanly. I've posted webrev here for reference (patch there also):
http://cr.openjdk.java.net/~coffeys/webrev.8060170.7u/webrev/

The new WSAIoctl call would appear to be failing with WSAEINVAL. The 
NET_EnableFastTcpLoopback call already tests for WSAEOPNOTSUPP - maybe we 
should test for WSAEINVAL also and perhaps return silently if windows don't 
support the option. Or maybe - we state this as desired behaviour - i.e this 
option is suitable for modern windows kernels - your note below would 
contradict what I'm seeing though.

The test passes for me on Windows 7 and fails on Windows XP.

regards,
Sean.

On 15/01/2015 11:15, Valery Kopylov (Akvelon) wrote:

Hi Sean,

Our TCP loopback implementation should process the option correctly on older 
windows kernels. I tried to reproduce the issue, but it works fine on my side. 
So I have an assumption that part of the code present on jdk9 patch has been 
lost and this causes such errors.
Did you use the patch for jdk7 sent by Martin or perform the backporting from 
jdk8 or 9 by yourself?
Could you please send me output of "hg diff" command in jdk folder?


Best regards,
Valeriy Kopylov

-Original Message-
From: Seán Coffey [mailto:sean.cof...@oracle.com]
Sent: Tuesday, January 13, 2015 22:31
To: Martin Sawicki (MS OPEN TECH); 
jdk7u-...@openjdk.java.net
Cc: Valery Kopylov (Akvelon); Kirk Shoop (MS OPEN TECH); Alan Bateman
Subject: Re: Backporting the TCP loopback fast path (Windows) improvement to 
OpenJDK v7

Hi Martin,

I've run into a problem in backporting this to JDK 7u. The test fails on our 
build/test systems. (windows XP) -

reason: User specified action: run main/othervm
-Djdk.net.useFastTcpLoopback StressLoopback elapsed time (seconds):
0.64
STDOUT:
STDERR:
java.net.SocketException: Invalid argument: fastLoopback
at sun.nio.ch.Net.socket0(Native Method)
at sun.nio.ch.Net.serverSocket(Net.java:445)
at 
sun.nio.ch.AsynchronousServerSocketChannelImpl.(AsynchronousServerSocketChannelImpl.java:71)
at 
sun.nio.ch.WindowsAsynchronousServerSocketChannelImpl.(WindowsAsynchronousServerSocketChannelImpl.java:69)
at 
sun.nio.ch.WindowsAsynchronousChannelProvider.openAsynchronousServerSocketChannel(WindowsAsynchronousChannelProvider.java:83)
at 
java.nio.channels.AsynchronousServerSocketChannel.open(AsynchronousServerSocketChannel.java:140)
at 
java.nio.channels.AsynchronousServerSocketChannel.open(AsynchronousServerSocketChannel.java:161)
at StressLoopback.main(StressLoopback.java:42)
This seems to be from the fact that the new SIO_LOOPBACK_FAST_PATH IOCTL code 
is only supported on more modern windows systems. I'm wondering if we should 
change the src code to not attempt to use this option on older windows kernels 
or if I should just modify the testcase to not run the test on older windows 
systems ?

regards,
Sean.



On 09/01/2015 16:25, Martin Sawicki (MS OPEN TECH) wrote:

Sean, thank you for the update and your assistance. Looking forward.

-Original Message-
From: Seán Coffey [mailto:sean.cof...@oracle.com]
Sent: Friday, January 09, 2015 8:24 AM
To: Martin Sawicki (MS OPEN TECH); 
jdk7u-...@openjdk.java.net
Cc: Valery Kopylov (Akvelon); Kirk Shoop (MS OPEN TECH)
Subject: Re: Backporting the TCP loopback fast path (Windows)
improvement to OpenJDK v7

Hey Martin,

I can help in getting this enhancement ported to jdk7u-dev. I'm just waiting on 
approval for use of new system property in jdk7u release.
Once I have that, I can get this in.

regards,
Sean.

On 08/01/15 20:01, Martin Sawicki (MS OPEN TECH) wrote:

Hello again,
We'd like to propose to back-port our TCP loopback fast path performance 
improvement for Windows that was recently accepted into OpenJDK v9 and v8 into 
v7.
Just for reference, the original OpenJDK v9 fix just for reference can be found 
here: http://hg.openjdk.java.net/jdk9/