From julia.boes at oracle.com  Thu Jun  4 16:24:47 2020
From: julia.boes at oracle.com (Julia Boes)
Date: Thu, 4 Jun 2020 17:24:47 +0100
Subject: RFR: 8246431: java/net/httpclient/PathSubscriber tests fail due to
 missing FilePermission
Message-ID: <8bc047d1-b8e9-9c28-c4b3-4832ed589b69@oracle.com>

Hi,

The tests in java/net/httpclient/PathSubscriber don't grant certain file 
permissions to test library classes. The tests succeed by chance when 
the compiled library classes are placed under ${test.classes}, but 
occasionally they fail, depending on which test target compiles the 
library first. This fix adds a FilePermission to the test/lib code base 
to cover all cases.

Bug: https://bugs.openjdk.java.net/browse/JDK-8246431

Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8246431/webrev.00/

Cheers,

Julia


From patrick.concannon at oracle.com  Thu Jun  4 16:55:23 2020
From: patrick.concannon at oracle.com (Patrick Concannon)
Date: Thu, 4 Jun 2020 17:55:23 +0100
Subject: RFR[8246132]: 'AsynchronousSocketChannelNAPITest failing with a
 NotYetConnectedException'
Message-ID: <221346A7-80CF-409D-BD1B-B633DE9D1195@oracle.com>

Hi,

Could someone please review my patch for JDK-8246132 - 'AsynchronousSocketChannelNAPITest failing with a NotYetConnectedException' ?

AsynchronousSocketChannelNAPITest sometimes fails with a NotYetConnectedException while trying to read data after connecting. This is fix changes the connect method to use a CompletionHandler to wait for the connection to be made before reading.

issue: https://bugs.openjdk.java.net/browse/JDK-8246132 <https://bugs.openjdk.java.net/browse/JDK-8246132>
webrev: http://cr.openjdk.java.net/~pconcannon/8246132/webrevs/webrev.00/ <http://cr.openjdk.java.net/~pconcannon/8246132/webrevs/webrev.00/>


Kind regards,
Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200604/7e27ee65/attachment.htm>

From daniel.fuchs at oracle.com  Thu Jun  4 21:01:34 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 4 Jun 2020 22:01:34 +0100
Subject: RFR: 8246431: java/net/httpclient/PathSubscriber tests fail due
 to missing FilePermission
In-Reply-To: <8bc047d1-b8e9-9c28-c4b3-4832ed589b69@oracle.com>
References: <8bc047d1-b8e9-9c28-c4b3-4832ed589b69@oracle.com>
Message-ID: <6dd4f936-5831-da40-aadf-c50e3be3f712@oracle.com>

Hi Julia,

Thanks for taking care of this.

Your propose changes look good to me.

best regards,

-- daniel

On 04/06/2020 17:24, Julia Boes wrote:
> Hi,
> 
> The tests in java/net/httpclient/PathSubscriber don't grant certain file 
> permissions to test library classes. The tests succeed by chance when 
> the compiled library classes are placed under ${test.classes}, but 
> occasionally they fail, depending on which test target compiles the 
> library first. This fix adds a FilePermission to the test/lib code base 
> to cover all cases.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8246431
> 
> Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8246431/webrev.00/
> 
> Cheers,
> 
> Julia
> 


From daniel.fuchs at oracle.com  Thu Jun  4 21:08:56 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 4 Jun 2020 22:08:56 +0100
Subject: RFR[8246132]: 'AsynchronousSocketChannelNAPITest failing with a
 NotYetConnectedException'
In-Reply-To: <221346A7-80CF-409D-BD1B-B633DE9D1195@oracle.com>
References: <221346A7-80CF-409D-BD1B-B633DE9D1195@oracle.com>
Message-ID: <da51fd24-c308-47ab-f980-eb05409a614a@oracle.com>

Hi Patrick,

Looks good, but for one thing.

Throwing in the failed() callback will probably accomplish
nothing since that is likely be called asynchronously in some
background thread. So if the connect doesn't succeed immediately
but fail instead at a later time, the test will block forever
waiting on the CountDownLatch until it gets interrupted by
the jtreg timeout.

Instead of using a CountDownLatch, I'd suggest using a
CompletableFuture<Boolean> which will allow to rethrow
the exception from the main thread.

best regards,

-- daniel


On 04/06/2020 17:55, Patrick Concannon wrote:
> Hi,
> 
> Could someone please review my patch for?JDK-8246132?- 
> *'AsynchronousSocketChannelNAPITest failing with a 
> NotYetConnectedException'*??
> 
> AsynchronousSocketChannelNAPITest sometimes fails with a 
> NotYetConnectedException while trying to read data after connecting. 
> This is fix changes the connect method to use a CompletionHandler to 
> wait for the?connection to be made before reading.
> 
> issue: https://bugs.openjdk.java.net/browse/JDK-8246132
> webrev: http://cr.openjdk.java.net/~pconcannon/8246132/webrevs/webrev.00/
> 
> 
> Kind regards,
> Patrick


From Alan.Bateman at oracle.com  Fri Jun  5 05:33:08 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 5 Jun 2020 06:33:08 +0100
Subject: RFR[8246132]: 'AsynchronousSocketChannelNAPITest failing with a
 NotYetConnectedException'
In-Reply-To: <da51fd24-c308-47ab-f980-eb05409a614a@oracle.com>
References: <221346A7-80CF-409D-BD1B-B633DE9D1195@oracle.com>
 <da51fd24-c308-47ab-f980-eb05409a614a@oracle.com>
Message-ID: <94e15b6d-d33e-a4fc-3c03-c1fd2f3ebf5b@oracle.com>



On 04/06/2020 22:08, Daniel Fuchs wrote:
> Hi Patrick,
>
> Looks good, but for one thing.
>
> Throwing in the failed() callback will probably accomplish
> nothing since that is likely be called asynchronously in some
> background thread. So if the connect doesn't succeed immediately
> but fail instead at a later time, the test will block forever
> waiting on the CountDownLatch until it gets interrupted by
> the jtreg timeout.
>
> Instead of using a CountDownLatch, I'd suggest using a
> CompletableFuture<Boolean> which will allow to rethrow
> the exception from the main thread.
Might be simpler to just change it to c.connect(remote).get(); to that 
it blocks until the connect is established (or it fails), no need to use 
the 3-arg connect method here.

-Alan

From chris.hegarty at oracle.com  Fri Jun  5 09:00:45 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 5 Jun 2020 10:00:45 +0100
Subject: RFR: 8246431: java/net/httpclient/PathSubscriber tests fail due
 to missing FilePermission
In-Reply-To: <8bc047d1-b8e9-9c28-c4b3-4832ed589b69@oracle.com>
References: <8bc047d1-b8e9-9c28-c4b3-4832ed589b69@oracle.com>
Message-ID: <D43661BE-779C-41FC-8E0B-B1FA690DC553@oracle.com>

Julia,

> On 4 Jun 2020, at 17:24, Julia Boes <julia.boes at oracle.com> wrote:
> 
> Hi,
> 
> The tests in java/net/httpclient/PathSubscriber don't grant certain file permissions to test library classes. The tests succeed by chance when the compiled library classes are placed under ${test.classes}, but occasionally they fail, depending on which test target compiles the library first. This fix adds a FilePermission to the test/lib code base to cover all cases.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8246431
> 
> Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8246431/webrev.00/

I think this looks fine as is. Optionally...

1) The preceding line ( to that of the new permission grant ) would appear to no longer be needed, since the new permission grant is to ALL-FILES, but its presence should be benign.

2) The comment "// for JTwork/classes/0/test/lib/jdk/test/lib/net/SimpleSSLContext.class?, could be generalised, since the codebase and permissions are for several library classes, not just SimpleSSLConext.

-Chris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200605/fd5ba08f/attachment.htm>

From patrick.concannon at oracle.com  Fri Jun  5 11:29:11 2020
From: patrick.concannon at oracle.com (Patrick Concannon)
Date: Fri, 5 Jun 2020 12:29:11 +0100
Subject: =?utf-8?Q?RFR=5B8243999=5D=3A_=E2=80=99DatagramSocket_and_Multica?=
 =?utf-8?Q?stSocket_constructors_don=27t_specify_how_a_null_InetAddress_is?=
 =?utf-8?Q?_handled=27?=
Message-ID: <569C5D4C-A3C1-4710-A8F6-66DC8D04A777@oracle.com>

Hi,

Could someone please review my patch and CSR for JDK-8243999 - ?DatagramSocket and MulticastSocket constructors don't specify how a null InetAddress is handled??

Currently, several constructors from DatagramSocket and MulticastSocket don't specify that the socket will be bound to the wildcard address if a null InetAddress is supplied, or that an unbound socket will be created if a null value is passed as a SocketAddress parameter. This fix provides clarification on this behaviour.

issue: https://bugs.openjdk.java.net/browse/JDK-8243999 <https://bugs.openjdk.java.net/browse/JDK-8243999>
CSR: https://bugs.openjdk.java.net/browse/JDK-8246663 <https://bugs.openjdk.java.net/browse/JDK-8246663>
webrev: http://cr.openjdk.java.net/~pconcannon/8245984/webrevs/webrev.00 <http://cr.openjdk.java.net/~pconcannon/8245984/webrevs/webrev.00>


Kind regards,
Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200605/d7d0f61a/attachment-0001.htm>

From patrick.concannon at oracle.com  Fri Jun  5 11:36:38 2020
From: patrick.concannon at oracle.com (Patrick Concannon)
Date: Fri, 5 Jun 2020 12:36:38 +0100
Subject: RFR[8246132]: 'AsynchronousSocketChannelNAPITest failing with a
 NotYetConnectedException'
In-Reply-To: <94e15b6d-d33e-a4fc-3c03-c1fd2f3ebf5b@oracle.com>
References: <221346A7-80CF-409D-BD1B-B633DE9D1195@oracle.com>
 <da51fd24-c308-47ab-f980-eb05409a614a@oracle.com>
 <94e15b6d-d33e-a4fc-3c03-c1fd2f3ebf5b@oracle.com>
Message-ID: <7AFC645B-84AB-4E55-A8FE-E3D52FB31705@oracle.com>

Hi Alan,

That?s much more concise. Thanks for the tip!

I?ve incorporated it into the updated webrev below.

http://cr.openjdk.java.net/~pconcannon/8246132/webrevs/webrev.01/ <http://cr.openjdk.java.net/~pconcannon/8246132/webrevs/webrev.01/>

Kind regards,
Patrick

> On 5 Jun 2020, at 06:33, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> 
> 
> On 04/06/2020 22:08, Daniel Fuchs wrote:
>> Hi Patrick,
>> 
>> Looks good, but for one thing.
>> 
>> Throwing in the failed() callback will probably accomplish
>> nothing since that is likely be called asynchronously in some
>> background thread. So if the connect doesn't succeed immediately
>> but fail instead at a later time, the test will block forever
>> waiting on the CountDownLatch until it gets interrupted by
>> the jtreg timeout.
>> 
>> Instead of using a CountDownLatch, I'd suggest using a
>> CompletableFuture<Boolean> which will allow to rethrow
>> the exception from the main thread.
> Might be simpler to just change it to c.connect(remote).get(); to that it blocks until the connect is established (or it fails), no need to use the 3-arg connect method here.
> 
> -Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200605/70ee41df/attachment.htm>

From daniel.fuchs at oracle.com  Fri Jun  5 11:54:03 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 5 Jun 2020 12:54:03 +0100
Subject: RFR[8246132]: 'AsynchronousSocketChannelNAPITest failing with a
 NotYetConnectedException'
In-Reply-To: <7AFC645B-84AB-4E55-A8FE-E3D52FB31705@oracle.com>
References: <221346A7-80CF-409D-BD1B-B633DE9D1195@oracle.com>
 <da51fd24-c308-47ab-f980-eb05409a614a@oracle.com>
 <94e15b6d-d33e-a4fc-3c03-c1fd2f3ebf5b@oracle.com>
 <7AFC645B-84AB-4E55-A8FE-E3D52FB31705@oracle.com>
Message-ID: <b4f9e34e-dfa8-5b80-789f-8d4b314969af@oracle.com>

Yes! Looks good to me Patrick.

Just remove 8246132 from the @bug list.
You don't list the bug number when the bug is in the test itself.
That's why the bug has a noreg-self keyword.
No need for a new webrev.

best regards,

-- daniel


On 05/06/2020 12:36, Patrick Concannon wrote:
> Hi Alan,
> 
> That?s much more concise. Thanks for the tip!
> 
> I?ve incorporated it into the updated webrev below.
> 
> http://cr.openjdk.java.net/~pconcannon/8246132/webrevs/webrev.01/
> 
> Kind regards,
> Patrick
> 


From daniel.fuchs at oracle.com  Fri Jun  5 12:00:55 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 5 Jun 2020 13:00:55 +0100
Subject: =?UTF-8?Q?Re=3a_RFR=5b8243999=5d=3a_=e2=80=99DatagramSocket_and_Mul?=
 =?UTF-8?Q?ticastSocket_constructors_don=27t_specify_how_a_null_InetAddress_?=
 =?UTF-8?Q?is_handled=27?=
In-Reply-To: <569C5D4C-A3C1-4710-A8F6-66DC8D04A777@oracle.com>
References: <569C5D4C-A3C1-4710-A8F6-66DC8D04A777@oracle.com>
Message-ID: <d3db4841-2dd4-6f39-5f7f-759269f338cf@oracle.com>

Hi Patrick,

MulticastSocket.java:

  195      * @throws    IllegalArgumentException  if port is <a 
href="#PortRange">
  196      *            out of range.</a>

I believe this should be:

  195      * @throws    IllegalArgumentException  if port is <a 
href="DatagramSocket.html#PortRange">
  196      *            out of range.</a>

Could you please make the change and regenerate the doc and double
check that the link in the generated doc is working?

best regards,

-- daniel

On 05/06/2020 12:29, Patrick Concannon wrote:
> Hi,
> 
> Could someone please review my patch and CSR 
> for?JDK-8243999?-??DatagramSocket and MulticastSocket constructors don't 
> specify how a null InetAddress is handled??
> 
> Currently, several constructors from DatagramSocket and MulticastSocket 
> don't specify that the socket will be bound to the wildcard address if a 
> null InetAddress is supplied, or that an unbound socket will be created 
> if a null value is passed as a SocketAddress parameter. This 
> fix?provides clarification on this behaviour.
> 
> issue: https://bugs.openjdk.java.net/browse/JDK-8243999
> CSR: https://bugs.openjdk.java.net/browse/JDK-8246663
> webrev: http://cr.openjdk.java.net/~pconcannon/8245984/webrevs/webrev.00
> 
> 
> Kind regards,
> Patrick


From julia.boes at oracle.com  Mon Jun  8 10:23:07 2020
From: julia.boes at oracle.com (Julia Boes)
Date: Mon, 8 Jun 2020 11:23:07 +0100
Subject: RFR: 8246431: java/net/httpclient/PathSubscriber tests fail due
 to missing FilePermission
In-Reply-To: <D43661BE-779C-41FC-8E0B-B1FA690DC553@oracle.com>
References: <8bc047d1-b8e9-9c28-c4b3-4832ed589b69@oracle.com>
 <D43661BE-779C-41FC-8E0B-B1FA690DC553@oracle.com>
Message-ID: <1904edfb-d514-0625-5ec0-0e964a18fb68@oracle.com>

Hi,

Chris and I reviewed the build configuration that leads to the changing 
location of the library classes. The @library tag, which builds classes 
implicitly in the test class directory, has been supplemented with 
explicit @build tags for the required library classes. This way, these 
classes are always placed in the shared JTWork//classes directory. The 
policy file has been adjusted accordingly to grant minimal permissions.

Updated webrev: http://cr.openjdk.java.net/~jboes/webrevs/8246431/webrev.01/

Cheers,

Julia


From chris.hegarty at oracle.com  Mon Jun  8 10:35:46 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 8 Jun 2020 11:35:46 +0100
Subject: RFR: 8246431: java/net/httpclient/PathSubscriber tests fail due
 to missing FilePermission
In-Reply-To: <1904edfb-d514-0625-5ec0-0e964a18fb68@oracle.com>
References: <8bc047d1-b8e9-9c28-c4b3-4832ed589b69@oracle.com>
 <D43661BE-779C-41FC-8E0B-B1FA690DC553@oracle.com>
 <1904edfb-d514-0625-5ec0-0e964a18fb68@oracle.com>
Message-ID: <33C32851-EB74-41A4-B6AF-70A8C48F1829@oracle.com>



> On 8 Jun 2020, at 11:23, Julia Boes <julia.boes at oracle.com> wrote:
> 
> ..
> 
> Updated webrev: http://cr.openjdk.java.net/~jboes/webrevs/8246431/webrev.01/

LGTM.

-Chris.

From patrick.concannon at oracle.com  Mon Jun  8 11:53:53 2020
From: patrick.concannon at oracle.com (Patrick Concannon)
Date: Mon, 8 Jun 2020 12:53:53 +0100
Subject: =?utf-8?Q?Re=3A_RFR=5B8243999=5D=3A_=E2=80=99DatagramSocket_and_M?=
 =?utf-8?Q?ulticastSocket_constructors_don=27t_specify_how_a_null_InetAddr?=
 =?utf-8?Q?ess_is_handled=27?=
In-Reply-To: <d3db4841-2dd4-6f39-5f7f-759269f338cf@oracle.com>
References: <569C5D4C-A3C1-4710-A8F6-66DC8D04A777@oracle.com>
 <d3db4841-2dd4-6f39-5f7f-759269f338cf@oracle.com>
Message-ID: <71A2B963-CB4D-467E-9BEA-0BF61684F1C6@oracle.com>

Hi Daniel,

Thanks for your feedback.

I?ve made the change, and included the new webrev below.

http://cr.openjdk.java.net/~pconcannon/8243999/webrevs/webrev.01/ <http://cr.openjdk.java.net/~pconcannon/8243999/webrevs/webrev.01/>

Kind regards,
Patrick


> On 5 Jun 2020, at 13:00, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi Patrick,
> 
> MulticastSocket.java:
> 
> 195      * @throws    IllegalArgumentException  if port is <a href="#PortRange">
> 196      *            out of range.</a>
> 
> I believe this should be:
> 
> 195      * @throws    IllegalArgumentException  if port is <a href="DatagramSocket.html#PortRange">
> 196      *            out of range.</a>
> 
> Could you please make the change and regenerate the doc and double
> check that the link in the generated doc is working?
> 
> best regards,
> 
> -- daniel
> 
> On 05/06/2020 12:29, Patrick Concannon wrote:
>> Hi,
>> Could someone please review my patch and CSR for JDK-8243999 - ?DatagramSocket and MulticastSocket constructors don't specify how a null InetAddress is handled??
>> Currently, several constructors from DatagramSocket and MulticastSocket don't specify that the socket will be bound to the wildcard address if a null InetAddress is supplied, or that an unbound socket will be created if a null value is passed as a SocketAddress parameter. This fix provides clarification on this behaviour.
>> issue: https://bugs.openjdk.java.net/browse/JDK-8243999
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8246663
>> webrev: http://cr.openjdk.java.net/~pconcannon/8245984/webrevs/webrev.00
>> Kind regards,
>> Patrick
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200608/7cbe96ec/attachment.htm>

From daniel.fuchs at oracle.com  Mon Jun  8 14:01:16 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 8 Jun 2020 15:01:16 +0100
Subject: =?UTF-8?Q?Re=3a_RFR=5b8243999=5d=3a_=e2=80=99DatagramSocket_and_Mul?=
 =?UTF-8?Q?ticastSocket_constructors_don=27t_specify_how_a_null_InetAddress_?=
 =?UTF-8?Q?is_handled=27?=
In-Reply-To: <71A2B963-CB4D-467E-9BEA-0BF61684F1C6@oracle.com>
References: <569C5D4C-A3C1-4710-A8F6-66DC8D04A777@oracle.com>
 <d3db4841-2dd4-6f39-5f7f-759269f338cf@oracle.com>
 <71A2B963-CB4D-467E-9BEA-0BF61684F1C6@oracle.com>
Message-ID: <d04d7150-916b-6d80-9ada-760e327eee96@oracle.com>

Hi Patrick,

Your last patch looks good to me. I have added myself as a reviewer to
the CSR as well.
https://bugs.openjdk.java.net/browse/JDK-8246663

best regards,

-- daniel

On 08/06/2020 12:53, Patrick Concannon wrote:
> Hi Daniel,
> 
> Thanks for your feedback.
> 
> I?ve made the change, and included the new webrev below.
> 
> http://cr.openjdk.java.net/~pconcannon/8243999/webrevs/webrev.01/
> 
> Kind regards,
> Patrick
> 
> 
>> On 5 Jun 2020, at 13:00, Daniel Fuchs <daniel.fuchs at oracle.com 
>> <mailto:daniel.fuchs at oracle.com>> wrote:
>>


From daniel.fuchs at oracle.com  Mon Jun  8 15:37:30 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 8 Jun 2020 16:37:30 +0100
Subject: RFR: 8246431: java/net/httpclient/PathSubscriber tests fail due
 to missing FilePermission
In-Reply-To: <1904edfb-d514-0625-5ec0-0e964a18fb68@oracle.com>
References: <8bc047d1-b8e9-9c28-c4b3-4832ed589b69@oracle.com>
 <D43661BE-779C-41FC-8E0B-B1FA690DC553@oracle.com>
 <1904edfb-d514-0625-5ec0-0e964a18fb68@oracle.com>
Message-ID: <5fdefa72-1e0b-bae7-b5ac-8dbd672405f0@oracle.com>

Hi Julia,

Looks good to me too!

best regards,

-- daniel

On 08/06/2020 11:23, Julia Boes wrote:
> Hi,
> 
> Chris and I reviewed the build configuration that leads to the changing 
> location of the library classes. The @library tag, which builds classes 
> implicitly in the test class directory, has been supplemented with 
> explicit @build tags for the required library classes. This way, these 
> classes are always placed in the shared JTWork//classes directory. The 
> policy file has been adjusted accordingly to grant minimal permissions.
> 
> Updated webrev: 
> http://cr.openjdk.java.net/~jboes/webrevs/8246431/webrev.01/
> 
> Cheers,
> 
> Julia
> 


From patrick.concannon at oracle.com  Mon Jun  8 18:53:59 2020
From: patrick.concannon at oracle.com (Patrick Concannon)
Date: Mon, 8 Jun 2020 19:53:59 +0100
Subject: =?utf-8?Q?RFR=5B8245828=5D=3A_=27Remove_unnecessary_NetworkPermis?=
 =?utf-8?Q?sion_checks_from_jdk/net/ExtendedSocketOptions=2Ejava=E2=80=99_?=
Message-ID: <2EF6BF7A-6E93-466F-AB3F-F7B3F0C39906@oracle.com>

Hi,

Could someone please review my fix for JDK-8245828 - ?Remove unnecessary NetworkPermission checks from jdk/net/ExtendedSocketOptions.java? ?

With the removal of socket option SO_FLOW_SLA the NetworkPermission checks in jdk/net/ExtendedSocketOptions are no longer required. This fix removes these checks. 

issue: https://bugs.openjdk.java.net/browse/JDK-8245828 <https://bugs.openjdk.java.net/browse/JDK-8245828>
webrev: http://cr.openjdk.java.net/~pconcannon/8245828/webrevs/webrev.00/ <http://cr.openjdk.java.net/~pconcannon/8245828/webrevs/webrev.00/>

Kind regards,
Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200608/bd803537/attachment.htm>

From Alan.Bateman at oracle.com  Tue Jun  9 06:13:04 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 9 Jun 2020 07:13:04 +0100
Subject: =?UTF-8?Q?Re=3a_RFR=5b8245828=5d=3a_=27Remove_unnecessary_NetworkPe?=
 =?UTF-8?Q?rmission_checks_from_jdk/net/ExtendedSocketOptions=2ejava?=
 =?UTF-8?B?4oCZ?=
In-Reply-To: <2EF6BF7A-6E93-466F-AB3F-F7B3F0C39906@oracle.com>
References: <2EF6BF7A-6E93-466F-AB3F-F7B3F0C39906@oracle.com>
Message-ID: <1bc65b6c-82a3-85fa-247f-c98886afc07b@oracle.com>



On 08/06/2020 19:53, Patrick Concannon wrote:
> Hi,
>
> Could someone please review my fix for JDK-8245828 - ?Remove 
> unnecessary NetworkPermission checks from 
> jdk/net/ExtendedSocketOptions.java? ?
>
> With the removal of socket option SO_FLOW_SLA?the NetworkPermission 
> checks in jdk/net/ExtendedSocketOptions are no longer?required. This 
> fix removes these checks.
>
> issue: https://bugs.openjdk.java.net/browse/JDK-8245828
> webrev: http://cr.openjdk.java.net/~pconcannon/8245828/webrevs/webrev.00/
The remove of the permission check looks good but I'm curious why the 
security policy needs accessDeclaredMembers - is it because of the 
getServerSocketTrafficClass method in the test? Just wondering if you've 
tried changing that to getMethod (rather than getDeclaredMethod) as its 
a public method.

-Alan

From patrick.concannon at oracle.com  Tue Jun  9 09:24:52 2020
From: patrick.concannon at oracle.com (Patrick Concannon)
Date: Tue, 9 Jun 2020 10:24:52 +0100
Subject: =?utf-8?Q?Re=3A_RFR=5B8245828=5D=3A_=27Remove_unnecessary_Network?=
 =?utf-8?Q?Permission_checks_from_jdk/net/ExtendedSocketOptions=2Ejava?=
 =?utf-8?Q?=E2=80=99_?=
In-Reply-To: <1bc65b6c-82a3-85fa-247f-c98886afc07b@oracle.com>
References: <2EF6BF7A-6E93-466F-AB3F-F7B3F0C39906@oracle.com>
 <1bc65b6c-82a3-85fa-247f-c98886afc07b@oracle.com>
Message-ID: <0466B2F5-8915-4B1C-AA27-6D1F69B45808@oracle.com>

Hi Alan,

Thanks for spotting this.

I?ve included the change in the updated webrev below.
http://cr.openjdk.java.net/~pconcannon/8245828/webrevs/webrev.01/ <http://cr.openjdk.java.net/~pconcannon/8245828/webrevs/webrev.01/>


Kind regards,
Patrick

> On 9 Jun 2020, at 07:13, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> 
> 
> On 08/06/2020 19:53, Patrick Concannon wrote:
>> Hi,
>> 
>> Could someone please review my fix for JDK-8245828 - ?Remove unnecessary NetworkPermission checks from jdk/net/ExtendedSocketOptions.java? ?
>> 
>> With the removal of socket option SO_FLOW_SLA the NetworkPermission checks in jdk/net/ExtendedSocketOptions are no longer required. This fix removes these checks.
>> 
>> issue: https://bugs.openjdk.java.net/browse/JDK-8245828
>> webrev: http://cr.openjdk.java.net/~pconcannon/8245828/webrevs/webrev.00/
> The remove of the permission check looks good but I'm curious why the security policy needs accessDeclaredMembers - is it because of the getServerSocketTrafficClass method in the test? Just wondering if you've tried changing that to getMethod (rather than getDeclaredMethod) as its a public method.
> 
> -Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200609/c4487ac9/attachment.htm>

From Alan.Bateman at oracle.com  Tue Jun  9 11:49:43 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 9 Jun 2020 12:49:43 +0100
Subject: =?UTF-8?Q?Re=3a_RFR=5b8245828=5d=3a_=27Remove_unnecessary_NetworkPe?=
 =?UTF-8?Q?rmission_checks_from_jdk/net/ExtendedSocketOptions=2ejava?=
 =?UTF-8?B?4oCZ?=
In-Reply-To: <0466B2F5-8915-4B1C-AA27-6D1F69B45808@oracle.com>
References: <2EF6BF7A-6E93-466F-AB3F-F7B3F0C39906@oracle.com>
 <1bc65b6c-82a3-85fa-247f-c98886afc07b@oracle.com>
 <0466B2F5-8915-4B1C-AA27-6D1F69B45808@oracle.com>
Message-ID: <d2ce9788-f742-f3e6-db8d-379e7846dd48@oracle.com>



On 09/06/2020 10:24, Patrick Concannon wrote:
> Hi Alan,
>
> Thanks for spotting this.
>
> I?ve included the change in the updated webrev below.
> http://cr.openjdk.java.net/~pconcannon/8245828/webrevs/webrev.01/
>
Looks good.

-Alan

From patrick.concannon at oracle.com  Tue Jun  9 14:42:11 2020
From: patrick.concannon at oracle.com (Patrick Concannon)
Date: Tue, 9 Jun 2020 15:42:11 +0100
Subject: =?utf-8?Q?RFR=5B8244933=5D=3A_=E2=80=98DatagramSocket=2Econnect_d?=
 =?utf-8?Q?oes_not_specify_that_it_may_cause_datagrams_in_the_socket_recei?=
 =?utf-8?Q?ve_buffer_to_be_discarded=E2=80=99_?=
Message-ID: <095E4FB8-DA2F-4A0A-ABE9-003308F62E9B@oracle.com>

Hi,

Could someone please review my fix for JDK-8244933 - ?DatagramSocket.connect does not specify that it may cause datagrams in the socket receive buffer to be discarded? ?

Currently, the javadoc for `DatagramSocket.connect` doesn't specify that it may cause datagrams in the socket receive buffer to be discarded if not previously received via a call to `DatagramSocket.receive`. This fix updates the javadoc to inform the user of this behaviour. 

issue: https://bugs.openjdk.java.net/browse/JDK-8244933 <https://bugs.openjdk.java.net/browse/JDK-8244933>
webrev: http://cr.openjdk.java.net/~pconcannon/8244933/webrevs/webrev.00/ <http://cr.openjdk.java.net/~pconcannon/8244933/webrevs/webrev.00/>
csr: https://bugs.openjdk.java.net/browse/JDK-8247181 <https://bugs.openjdk.java.net/browse/JDK-8247181>


Kind regards,
Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200609/c0412843/attachment.htm>

From Alan.Bateman at oracle.com  Tue Jun  9 14:47:57 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 9 Jun 2020 15:47:57 +0100
Subject: =?UTF-8?B?UmU6IFJGUls4MjQ0OTMzXTog4oCYRGF0YWdyYW1Tb2NrZXQuY29ubmVj?=
 =?UTF-8?Q?t_does_not_specify_that_it_may_cause_datagrams_in_the_socket_rece?=
 =?UTF-8?Q?ive_buffer_to_be_discarded=e2=80=99?=
In-Reply-To: <095E4FB8-DA2F-4A0A-ABE9-003308F62E9B@oracle.com>
References: <095E4FB8-DA2F-4A0A-ABE9-003308F62E9B@oracle.com>
Message-ID: <bfe3e2dc-2968-ccb2-fc41-277f3e2f22f1@oracle.com>



On 09/06/2020 15:42, Patrick Concannon wrote:
> Hi,
>
> Could someone please review my fix for?JDK-8244933?- 
> ?DatagramSocket.connect does not?specify that it may cause datagrams 
> in?the socket receive buffer to be discarded? ?
>
> Currently, the javadoc for `DatagramSocket.connect` doesn't specify 
> that it may cause?datagrams in the?socket receive buffer to be 
> discarded if not previously received via a call 
> to?`DatagramSocket.receive`. This fix updates the javadoc to inform 
> the user of this behaviour.
>
> issue: https://bugs.openjdk.java.net/browse/JDK-8244933
> webrev: http://cr.openjdk.java.net/~pconcannon/8244933/webrevs/webrev.00/
> csr: https://bugs.openjdk.java.net/browse/JDK-8247181
>
This looks good (and makes it consistent with DatagramChannel).

-Alan

From daniel.fuchs at oracle.com  Tue Jun  9 16:41:52 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 9 Jun 2020 17:41:52 +0100
Subject: =?UTF-8?B?UmU6IFJGUls4MjQ0OTMzXTog4oCYRGF0YWdyYW1Tb2NrZXQuY29ubmVj?=
 =?UTF-8?Q?t_does_not_specify_that_it_may_cause_datagrams_in_the_socket_rece?=
 =?UTF-8?Q?ive_buffer_to_be_discarded=e2=80=99?=
In-Reply-To: <095E4FB8-DA2F-4A0A-ABE9-003308F62E9B@oracle.com>
References: <095E4FB8-DA2F-4A0A-ABE9-003308F62E9B@oracle.com>
Message-ID: <fb31abab-3c64-abad-6c89-0647431eb74f@oracle.com>

Looks good to me Patrick.

I have reviewed the CSR too.

best regards,

-- daniel

On 09/06/2020 15:42, Patrick Concannon wrote:
> Hi,
> 
> Could someone please review my fix for?JDK-8244933?- 
> ?DatagramSocket.connect does not?specify that it may cause datagrams 
> in?the socket receive buffer to be discarded? ?
> 
> Currently, the javadoc for `DatagramSocket.connect` doesn't specify that 
> it may cause?datagrams in the?socket receive buffer to be discarded if 
> not previously received via a call to?`DatagramSocket.receive`. This fix 
> updates the javadoc to inform the user of this behaviour.
> 
> issue: https://bugs.openjdk.java.net/browse/JDK-8244933
> webrev: http://cr.openjdk.java.net/~pconcannon/8244933/webrevs/webrev.00/
> csr: https://bugs.openjdk.java.net/browse/JDK-8247181
> 
> 
> Kind regards,
> Patrick


From akashche at redhat.com  Wed Jun 10 14:52:32 2020
From: akashche at redhat.com (Alex Kashchenko)
Date: Wed, 10 Jun 2020 15:52:32 +0100
Subject: RFC: 8132359: JarURLConnection.getJarFile() resource leak when
 file is not found
In-Reply-To: <cb539b05-58c4-c9d4-65fc-99e6e610821f@redhat.com>
References: <3a6b3928-8c8e-7fb8-aecd-5ace6ae18ab7@redhat.com>
 <5e148c2e-c708-aaf7-08b0-fd090ede1741@oracle.com>
 <DBBPR09MB301443A91F9B7379199D1888DFC90@DBBPR09MB3014.eurprd09.prod.outlook.com>
 <DBBPR09MB301417FAA2627B08F2D1F696DFC90@DBBPR09MB3014.eurprd09.prod.outlook.com>
 <32930d6b-0a68-832f-e8aa-69dc1b4c7c61@redhat.com>
 <3796528b-bb1e-2bb9-2c7f-f8e5ed6e378d@oracle.com>
 <25db137a-206a-4164-9ec0-0aeacb212ce7@redhat.com>
 <db10bd42-17dd-867f-9602-66f59e6bcbd2@oracle.com>
 <4a479a47-6b2b-bf12-264f-b3dd7fd9877d@oracle.com>
 <6276446d-8677-84e5-1cbb-da336f81901b@redhat.com>
 <76c99b21-6f9c-d2f8-9513-e4f3acd37e27@oracle.com>
 <DBBPR09MB3014FBFDD1D16D25EE3DA96FDFA10@DBBPR09MB3014.eurprd09.prod.outlook.com>
 <cb539b05-58c4-c9d4-65fc-99e6e610821f@redhat.com>
Message-ID: <f1ab6561-96a6-e30c-5234-960c4abee7b6@redhat.com>

Hi,

On 05/12/2020 12:20 AM, Alex Kashchenko wrote:
> CSR: https://bugs.openjdk.java.net/browse/JDK-8244650

A question about this CSR: after this new issue was found in the same area:

JDK-8246714: URLClassLoader/JAR protocol handler poisons the global 
JarFile cache under concurrent load

would it be appropriate to postpone the activity on the CSR (and 
possibly eventually cancel it)?

It looks like both possible solutions to 8244650:

  - short term: disable caching for JAR protocol

  - long term: rework JAR protocol handler

make this CSR redundant.

I am happy to work on some minor bugfixes in this area if necessary.

> 
> [...]
>
-- 
-Alex


From akashche at redhat.com  Wed Jun 10 14:55:29 2020
From: akashche at redhat.com (Alex Kashchenko)
Date: Wed, 10 Jun 2020 15:55:29 +0100
Subject: RFC: 8132359: JarURLConnection.getJarFile() resource leak when
 file is not found
In-Reply-To: <f1ab6561-96a6-e30c-5234-960c4abee7b6@redhat.com>
References: <3a6b3928-8c8e-7fb8-aecd-5ace6ae18ab7@redhat.com>
 <5e148c2e-c708-aaf7-08b0-fd090ede1741@oracle.com>
 <DBBPR09MB301443A91F9B7379199D1888DFC90@DBBPR09MB3014.eurprd09.prod.outlook.com>
 <DBBPR09MB301417FAA2627B08F2D1F696DFC90@DBBPR09MB3014.eurprd09.prod.outlook.com>
 <32930d6b-0a68-832f-e8aa-69dc1b4c7c61@redhat.com>
 <3796528b-bb1e-2bb9-2c7f-f8e5ed6e378d@oracle.com>
 <25db137a-206a-4164-9ec0-0aeacb212ce7@redhat.com>
 <db10bd42-17dd-867f-9602-66f59e6bcbd2@oracle.com>
 <4a479a47-6b2b-bf12-264f-b3dd7fd9877d@oracle.com>
 <6276446d-8677-84e5-1cbb-da336f81901b@redhat.com>
 <76c99b21-6f9c-d2f8-9513-e4f3acd37e27@oracle.com>
 <DBBPR09MB3014FBFDD1D16D25EE3DA96FDFA10@DBBPR09MB3014.eurprd09.prod.outlook.com>
 <cb539b05-58c4-c9d4-65fc-99e6e610821f@redhat.com>
 <f1ab6561-96a6-e30c-5234-960c4abee7b6@redhat.com>
Message-ID: <46fe5deb-ab5b-cd79-a6e3-557736eb6113@redhat.com>

On 06/10/2020 03:52 PM, Alex Kashchenko wrote:
> Hi,
> 
> On 05/12/2020 12:20 AM, Alex Kashchenko wrote:
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8244650
> 
> A question about this CSR: after this new issue was found in the same area:
> 
> JDK-8246714: URLClassLoader/JAR protocol handler poisons the global 
> JarFile cache under concurrent load
> 
> would it be appropriate to postpone the activity on the CSR (and 
> possibly eventually cancel it)?
> 
> It looks like both possible solutions to 8244650:

Correction to issue number: "both possible solutions to new issue 
JDK-8246714"

> 
>  ?- short term: disable caching for JAR protocol
> 
>  ?- long term: rework JAR protocol handler
> 
> make this CSR redundant.
> 
> I am happy to work on some minor bugfixes in this area if necessary.
> 
>>
>> [...]
>>


-- 
-Alex


From conor.cleary at oracle.com  Thu Jun 11 09:35:22 2020
From: conor.cleary at oracle.com (Conor Cleary)
Date: Thu, 11 Jun 2020 10:35:22 +0100
Subject: RFR[8246143]: 'UnreferencedXXX tests fail when run with
 --illegal-access=deny'
Message-ID: <c7aa67fb-c20d-64e7-aa30-f634c2b87af5@oracle.com>

Hi,

Could someone please take a look at my webrev for JDK-8246143: 
'UnreferencedXXX tests fail when run with --illegal-access=deny'?

This patch addresses test failures with 
test/jdk/java/net/DatagramSocket/UnreferencedDatagramSockets.java and
test/jdk/java/net/MulticastSocket/UnreferencedMulticastSockets.java when 
run with --illegal-access=deny.

This revision addresses this failure in both tests by adding 
java.base/sun.nio.ch:+open to the modules tag. An additional test run is 
also with the --illegal-access=deny configuration set.

bug: https://bugs.openjdk.java.net/browse/JDK-8246143
webrev: 
http://cr.openjdk.java.net/~pconcannon/ccleary/8246143/webrevs/webrev.00/


Regards,
Conor


From daniel.fuchs at oracle.com  Thu Jun 11 09:41:20 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 11 Jun 2020 10:41:20 +0100
Subject: RFR[8246143]: 'UnreferencedXXX tests fail when run with
 --illegal-access=deny'
In-Reply-To: <c7aa67fb-c20d-64e7-aa30-f634c2b87af5@oracle.com>
References: <c7aa67fb-c20d-64e7-aa30-f634c2b87af5@oracle.com>
Message-ID: <86c69257-a96c-9454-db6f-4576d8c45071@oracle.com>

Looks good to me Conor!

best regards,

-- daniel

On 11/06/2020 10:35, Conor Cleary wrote:
> Hi,
> 
> Could someone please take a look at my webrev for JDK-8246143: 
> 'UnreferencedXXX tests fail when run with --illegal-access=deny'?
> 
> This patch addresses test failures with 
> test/jdk/java/net/DatagramSocket/UnreferencedDatagramSockets.java and
> test/jdk/java/net/MulticastSocket/UnreferencedMulticastSockets.java when 
> run with --illegal-access=deny.
> 
> This revision addresses this failure in both tests by adding 
> java.base/sun.nio.ch:+open to the modules tag. An additional test run is 
> also with the --illegal-access=deny configuration set.
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8246143
> webrev: 
> http://cr.openjdk.java.net/~pconcannon/ccleary/8246143/webrevs/webrev.00/
> 
> 
> Regards,
> Conor
> 


From Alan.Bateman at oracle.com  Thu Jun 11 09:52:08 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 11 Jun 2020 10:52:08 +0100
Subject: RFR[8246143]: 'UnreferencedXXX tests fail when run with
 --illegal-access=deny'
In-Reply-To: <c7aa67fb-c20d-64e7-aa30-f634c2b87af5@oracle.com>
References: <c7aa67fb-c20d-64e7-aa30-f634c2b87af5@oracle.com>
Message-ID: <8497bc61-0b8d-8e68-d11e-58a986a9d1ee@oracle.com>

On 11/06/2020 10:35, Conor Cleary wrote:
> Hi,
>
> Could someone please take a look at my webrev for JDK-8246143: 
> 'UnreferencedXXX tests fail when run with --illegal-access=deny'?
>
> This patch addresses test failures with 
> test/jdk/java/net/DatagramSocket/UnreferencedDatagramSockets.java and
> test/jdk/java/net/MulticastSocket/UnreferencedMulticastSockets.java 
> when run with --illegal-access=deny.
>
> This revision addresses this failure in both tests by adding 
> java.base/sun.nio.ch:+open to the modules tag. An additional test run 
> is also with the --illegal-access=deny configuration set.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8246143
> webrev: 
> http://cr.openjdk.java.net/~pconcannon/ccleary/8246143/webrevs/webrev.00/
Thanks for taking this one. No need for the additional run with 
--illegal-access=deny as that will be the default (we've changed many 
other tests in preparation for this change btw).

-Alan.

From jai.forums2013 at gmail.com  Thu Jun 11 13:31:55 2020
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Thu, 11 Jun 2020 19:01:55 +0530
Subject: java.net.BindException doesn't include host info even when
 jdk.includeInExceptions is set to hostInfo
Message-ID: <4df34505-cdc7-e829-a294-c82c987f3be7@gmail.com>

The security.properties file in Java 11 (and later) have a new
configuration:

# The categories are:
#
#? hostInfo - IOExceptions thrown by java.net.Socket and the socket
types in the
#???????????? java.nio.channels package will contain enhanced exception
#???????????? message information
#
# The property setting in this file can be overridden by a system
property of
# the same name, with the same syntax and possible values.
#
#jdk.includeInExceptions=hostInfo

As noted for that property, if hostInfo is set as a value for this
jdk.includeInExceptions then IOException thrown by java.net.Socket will
container additional information. Is this expected to work for all kinds
of connection issues related to Socket types? For example, I have a Java
program which creates a ServerSocket and (intentionally) binds it to
port which is already in use. I (as expected) keep seeing this exception:


Exception in thread "main" java.net.BindException: Address already in
use (Bind failed)
??? at java.base/java.net.PlainSocketImpl.socketBind(Native Method)
??? at
java.base/java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:436)
??? at java.base/java.net.ServerSocket.bind(ServerSocket.java:381)
??? at java.base/java.net.ServerSocket.bind(ServerSocket.java:335)
??? at Bind.main(Bind.java:7)


However, even after setting the jdk.includeInExceptions=hostInfo, I
haven't been able to generate the host name and port against which this
BindException occurs. Is this part of the code, in the JDK, expected to
include this additional info for this exception?

P.S: Tried with both Java 11 and Java 14.

-Jaikiran



From Alan.Bateman at oracle.com  Thu Jun 11 13:48:21 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 11 Jun 2020 14:48:21 +0100
Subject: java.net.BindException doesn't include host info even when
 jdk.includeInExceptions is set to hostInfo
In-Reply-To: <4df34505-cdc7-e829-a294-c82c987f3be7@gmail.com>
References: <4df34505-cdc7-e829-a294-c82c987f3be7@gmail.com>
Message-ID: <9672bf89-292b-4fed-ade8-bbd9b5655f96@oracle.com>

On 11/06/2020 14:31, Jaikiran Pai wrote:
> The security.properties file in Java 11 (and later) have a new
> configuration:
>
> # The categories are:
> #
> #? hostInfo - IOExceptions thrown by java.net.Socket and the socket
> types in the
> #???????????? java.nio.channels package will contain enhanced exception
> #???????????? message information
> #
> # The property setting in this file can be overridden by a system
> property of
> # the same name, with the same syntax and possible values.
> #
> #jdk.includeInExceptions=hostInfo
>
> As noted for that property, if hostInfo is set as a value for this
> jdk.includeInExceptions then IOException thrown by java.net.Socket will
> container additional information. Is this expected to work for all kinds
> of connection issues related to Socket types? For example, I have a Java
> program which creates a ServerSocket and (intentionally) binds it to
> port which is already in use. I (as expected) keep seeing this exception:
>
It's only used when when when connecting a stream-oriented socket fails. 
It could be extended of course although I would expect most servers have 
some form of log so the information on the local address/port might be 
there already.!

-Alan.

From jai.forums2013 at gmail.com  Thu Jun 11 13:59:48 2020
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Thu, 11 Jun 2020 19:29:48 +0530
Subject: java.net.BindException doesn't include host info even when
 jdk.includeInExceptions is set to hostInfo
In-Reply-To: <9672bf89-292b-4fed-ade8-bbd9b5655f96@oracle.com>
References: <4df34505-cdc7-e829-a294-c82c987f3be7@gmail.com>
 <9672bf89-292b-4fed-ade8-bbd9b5655f96@oracle.com>
Message-ID: <0c36cbbb-00a5-887e-e7dc-f2603c86a8d1@gmail.com>

Hello Alan,

On 11/06/20 7:18 pm, Alan Bateman wrote:
> On 11/06/2020 14:31, Jaikiran Pai wrote:
>> The security.properties file in Java 11 (and later) have a new
>> configuration:
>>
>> # The categories are:
>> #
>> #? hostInfo - IOExceptions thrown by java.net.Socket and the socket
>> types in the
>> #???????????? java.nio.channels package will contain enhanced exception
>> #???????????? message information
>> #
>> # The property setting in this file can be overridden by a system
>> property of
>> # the same name, with the same syntax and possible values.
>> #
>> #jdk.includeInExceptions=hostInfo
>>
>> As noted for that property, if hostInfo is set as a value for this
>> jdk.includeInExceptions then IOException thrown by java.net.Socket will
>> container additional information. Is this expected to work for all kinds
>> of connection issues related to Socket types? For example, I have a Java
>> program which creates a ServerSocket and (intentionally) binds it to
>> port which is already in use. I (as expected) keep seeing this
>> exception:
>>
> It's only used when when when connecting a stream-oriented socket
> fails. It could be extended of course although I would expect most
> servers have some form of log so the information on the local
> address/port might be there already.!
>
Having the host and port propagated as part of the exception message
right from the JDK (instead of the server code), I think, will help in
cases like the one reported here[1], where a ServerSocket is being
created with a port of 0. In this case, the library which is creating
that ServerSocket, itself won't know what port gets allocated.

Is this a valid use case to have this part of the JDK code enhanced to
include the additional host/port information (of course when that
security property is enabled)?

[1] https://github.com/quarkusio/quarkus/issues/9889

-Jaikiran



From Alan.Bateman at oracle.com  Thu Jun 11 14:10:49 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 11 Jun 2020 15:10:49 +0100
Subject: java.net.BindException doesn't include host info even when
 jdk.includeInExceptions is set to hostInfo
In-Reply-To: <0c36cbbb-00a5-887e-e7dc-f2603c86a8d1@gmail.com>
References: <4df34505-cdc7-e829-a294-c82c987f3be7@gmail.com>
 <9672bf89-292b-4fed-ade8-bbd9b5655f96@oracle.com>
 <0c36cbbb-00a5-887e-e7dc-f2603c86a8d1@gmail.com>
Message-ID: <075a2bd9-e571-75e7-6d03-5ddba247b7e6@oracle.com>

On 11/06/2020 14:59, Jaikiran Pai wrote:
> :
> Is this a valid use case to have this part of the JDK code enhanced to
> include the additional host/port information (of course when that
> security property is enabled)?
>
Yes but there there are always security concerns with including too much 
information in exceptions so this is why we would not be included by 
default.

-Alan

From jai.forums2013 at gmail.com  Thu Jun 11 14:17:19 2020
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Thu, 11 Jun 2020 19:47:19 +0530
Subject: java.net.BindException doesn't include host info even when
 jdk.includeInExceptions is set to hostInfo
In-Reply-To: <075a2bd9-e571-75e7-6d03-5ddba247b7e6@oracle.com>
References: <4df34505-cdc7-e829-a294-c82c987f3be7@gmail.com>
 <9672bf89-292b-4fed-ade8-bbd9b5655f96@oracle.com>
 <0c36cbbb-00a5-887e-e7dc-f2603c86a8d1@gmail.com>
 <075a2bd9-e571-75e7-6d03-5ddba247b7e6@oracle.com>
Message-ID: <1621724d-bcd6-c6f6-ac3c-bf8b98f14776@gmail.com>


On 11/06/20 7:40 pm, Alan Bateman wrote:
> On 11/06/2020 14:59, Jaikiran Pai wrote:
>> :
>> Is this a valid use case to have this part of the JDK code enhanced to
>> include the additional host/port information (of course when that
>> security property is enabled)?
>>
> Yes but there there are always security concerns with including too
> much information in exceptions so this is why we would not be included
> by default.
>
Agreed and I understand the reasoning behind not including any of these
details by default.

I'll open a JBS enhancement in a short while to have this part enhanced
to report the additional details only when the specific security
property is enabled.

-Jaikiran


From jai.forums2013 at gmail.com  Thu Jun 11 14:30:35 2020
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Thu, 11 Jun 2020 20:00:35 +0530
Subject: java.net.BindException doesn't include host info even when
 jdk.includeInExceptions is set to hostInfo
In-Reply-To: <1621724d-bcd6-c6f6-ac3c-bf8b98f14776@gmail.com>
References: <4df34505-cdc7-e829-a294-c82c987f3be7@gmail.com>
 <9672bf89-292b-4fed-ade8-bbd9b5655f96@oracle.com>
 <0c36cbbb-00a5-887e-e7dc-f2603c86a8d1@gmail.com>
 <075a2bd9-e571-75e7-6d03-5ddba247b7e6@oracle.com>
 <1621724d-bcd6-c6f6-ac3c-bf8b98f14776@gmail.com>
Message-ID: <8fd7968d-511d-a2b3-b975-1aa5db811901@gmail.com>


On 11/06/20 7:47 pm, Jaikiran Pai wrote:
>
> I'll open a JBS enhancement in a short while to have this part enhanced
> to report the additional details only when the specific security
> property is enabled.

I've created https://bugs.openjdk.java.net/browse/JDK-8247413 to track this.

-Jaikiran



From rahul.r.yadav at ORACLE.COM  Fri Jun 12 14:11:33 2020
From: rahul.r.yadav at ORACLE.COM (Rahul)
Date: Fri, 12 Jun 2020 15:11:33 +0100
Subject: RFR 8245307 : Update ExchangeImpl to use thread safe DateTimeFormatter
In-Reply-To: <85FAFDBA-4071-465D-9DED-112435059C18@oracle.com>
References: <07cc1080-7201-8303-b4b8-6912a4a71ac3@oracle.com>
 <122633f8-c54f-ebe5-9742-6f4803369139@oracle.com>
 <85FAFDBA-4071-465D-9DED-112435059C18@oracle.com>
Message-ID: <E681A1A1-ECFD-4972-AA58-2FD1CDF377B5@oracle.com>

Hello,

 

Request to have my fix reviewed for the issue:

 

JDK-8245307 : Update ExchangeImpl to use thread safe DateTimeFormatter.

 

The fix updates sun.net.httpserver.ExchangeImpl to use thread safe 

DateTimeFormatter for response headers, this replaces DateFormat

that was using ThreadLocal to be thread safe.

 

Issue:?? ???https://bugs.openjdk.java.net/browse/JDK-8245307

webrev:? http://cr.openjdk.java.net/~ryadav/webrev_8245307/index.html

 

- rahul

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200612/41867cc7/attachment.htm>

From rahul.r.yadav at oracle.com  Fri Jun 12 14:56:47 2020
From: rahul.r.yadav at oracle.com (Rahul)
Date: Fri, 12 Jun 2020 15:56:47 +0100
Subject: RFR 8245307 : Update ExchangeImpl to use thread safe DateTimeFormatter
Message-ID: <0EEA206E-48F8-41E4-AB24-8C6A48C7ED26@oracle.com>

Hello,

 

Request to have my fix reviewed for the issue:

 

JDK-8245307 : Update ExchangeImpl to use thread safe DateTimeFormatter.

 

The fix updates sun.net.httpserver.ExchangeImpl to use thread safe 

DateTimeFormatter for response headers, this replaces DateFormat

that was using ThreadLocal to be thread safe.

 

Issue:      https://bugs.openjdk.java.net/browse/JDK-8245307

webrev:  http://cr.openjdk.java.net/~ryadav/webrev_8245307/index.html

 

- rahul

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200612/50427df3/attachment.htm>

From Alan.Bateman at oracle.com  Fri Jun 12 15:57:05 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 12 Jun 2020 16:57:05 +0100
Subject: RFR 8245307 : Update ExchangeImpl to use thread safe
 DateTimeFormatter
In-Reply-To: <0EEA206E-48F8-41E4-AB24-8C6A48C7ED26@oracle.com>
References: <0EEA206E-48F8-41E4-AB24-8C6A48C7ED26@oracle.com>
Message-ID: <941e46fc-ff16-afb9-ea4d-c0ad9b65418b@oracle.com>



On 12/06/2020 15:56, Rahul wrote:
>
> Hello,
>
> Request to have my fix reviewed for the issue:
>
> JDK-8245307 : Update ExchangeImpl to use thread safe DateTimeFormatter.
>
> The fix updates sun.net.httpserver.ExchangeImpl to use thread safe
>
> DateTimeFormatter for response headers, this replaces DateFormat
>
> that was using ThreadLocal to be thread safe.
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8245307
>
> webrev: http://cr.openjdk.java.net/~ryadav/webrev_8245307/index.html
>
>
Thanks for taking this one. Implementation change is fine. The test 
seems to be quite good but I have small comments:

1. @modules lists several internal packages that don't seem to be used, 
maybe copied from another test?

2. It might be easier for reviewers to move the @AfterTest to after the 
@BeforeTest so that the setup/tear-down are close together.

3. Are you re-order the declarations so that the instance fields are 
together (the static and instance fields are mixed up so slow to read).

4. Minor nit is that you are missing a space in several "if(" and "try(" 
usages, maybe an old habit?

-Alan




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200612/9cca3633/attachment.htm>

From rahul.r.yadav at oracle.com  Fri Jun 12 16:55:08 2020
From: rahul.r.yadav at oracle.com (Rahul Yadav)
Date: Fri, 12 Jun 2020 17:55:08 +0100
Subject: RFR 8245307 : Update ExchangeImpl to use thread safe
 DateTimeFormatter
In-Reply-To: <941e46fc-ff16-afb9-ea4d-c0ad9b65418b@oracle.com>
References: <0EEA206E-48F8-41E4-AB24-8C6A48C7ED26@oracle.com>
 <941e46fc-ff16-afb9-ea4d-c0ad9b65418b@oracle.com>
Message-ID: <03f95f8d-0dac-4496-94ce-a9d418da67a3@oracle.com>

Hi Alan,

Thank you for the feedback.
I have updated the webrev.

 ?http://cr.openjdk.java.net/~ryadav/webrev_8245307/index.html

- rahul

On 12/06/2020 16:57, Alan Bateman wrote:
>
>
> On 12/06/2020 15:56, Rahul wrote:
>>
>> Hello,
>>
>> Request to have my fix reviewed for the issue:
>>
>> JDK-8245307 : Update ExchangeImpl to use thread safe DateTimeFormatter.
>>
>> The fix updates sun.net.httpserver.ExchangeImpl to use thread safe
>>
>> DateTimeFormatter for response headers, this replaces DateFormat
>>
>> that was using ThreadLocal to be thread safe.
>>
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8245307
>>
>> webrev: http://cr.openjdk.java.net/~ryadav/webrev_8245307/index.html
>>
>>
> Thanks for taking this one. Implementation change is fine. The test 
> seems to be quite good but I have small comments:
>
> 1. @modules lists several internal packages that don't seem to be 
> used, maybe copied from another test?
>
> 2. It might be easier for reviewers to move the @AfterTest to after 
> the @BeforeTest so that the setup/tear-down are close together.
>
> 3. Are you re-order the declarations so that the instance fields are 
> together (the static and instance fields are mixed up so slow to read).
>
> 4. Minor nit is that you are missing a space in several "if(" and 
> "try(" usages, maybe an old habit?
>
> -Alan
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200612/38c5d838/attachment-0001.htm>

From Alan.Bateman at oracle.com  Fri Jun 12 17:41:11 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 12 Jun 2020 18:41:11 +0100
Subject: RFR 8245307 : Update ExchangeImpl to use thread safe
 DateTimeFormatter
In-Reply-To: <03f95f8d-0dac-4496-94ce-a9d418da67a3@oracle.com>
References: <0EEA206E-48F8-41E4-AB24-8C6A48C7ED26@oracle.com>
 <941e46fc-ff16-afb9-ea4d-c0ad9b65418b@oracle.com>
 <03f95f8d-0dac-4496-94ce-a9d418da67a3@oracle.com>
Message-ID: <91efd046-4406-9bf1-9f3d-1ff3774dc685@oracle.com>

On 12/06/2020 17:55, Rahul Yadav wrote:
> Hi Alan,
>
> Thank you for the feedback.
> I have updated the webrev.
>
> http://cr.openjdk.java.net/~ryadav/webrev_8245307/index.html
Thank for the update, this looks good. Minor nit is that we typically 
use order the modifiers so that it's "static final" rather than "final 
static"? but it's no big deal.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200612/67436711/attachment.htm>

From macanaoire at hotmail.com  Sat Jun 13 21:49:09 2020
From: macanaoire at hotmail.com (mark sheppard)
Date: Sat, 13 Jun 2020 21:49:09 +0000
Subject: RFC: 8132359: JarURLConnection.getJarFile() resource leak when
 file is not found
In-Reply-To: <f1ab6561-96a6-e30c-5234-960c4abee7b6@redhat.com>
References: <3a6b3928-8c8e-7fb8-aecd-5ace6ae18ab7@redhat.com>
 <5e148c2e-c708-aaf7-08b0-fd090ede1741@oracle.com>
 <DBBPR09MB301443A91F9B7379199D1888DFC90@DBBPR09MB3014.eurprd09.prod.outlook.com>
 <DBBPR09MB301417FAA2627B08F2D1F696DFC90@DBBPR09MB3014.eurprd09.prod.outlook.com>
 <32930d6b-0a68-832f-e8aa-69dc1b4c7c61@redhat.com>
 <3796528b-bb1e-2bb9-2c7f-f8e5ed6e378d@oracle.com>
 <25db137a-206a-4164-9ec0-0aeacb212ce7@redhat.com>
 <db10bd42-17dd-867f-9602-66f59e6bcbd2@oracle.com>
 <4a479a47-6b2b-bf12-264f-b3dd7fd9877d@oracle.com>
 <6276446d-8677-84e5-1cbb-da336f81901b@redhat.com>
 <76c99b21-6f9c-d2f8-9513-e4f3acd37e27@oracle.com>
 <DBBPR09MB3014FBFDD1D16D25EE3DA96FDFA10@DBBPR09MB3014.eurprd09.prod.outlook.com>
 <cb539b05-58c4-c9d4-65fc-99e6e610821f@redhat.com>,
 <f1ab6561-96a6-e30c-5234-960c4abee7b6@redhat.com>
Message-ID: <DBBPR09MB3014AAA136623AF8518F9367DF9E0@DBBPR09MB3014.eurprd09.prod.outlook.com>

Hi,
   For JDK-8132359 it now addresses the issue:

Amend JarURLConnection::getJarFile() to return JarFile object reference for nonexistent JAR file entry URL

The scenario addressed is that a JarURLConnection is constructed encapsulating a reference to an non existent entry in an extant JarFile, then the  getJarFile  is reasonably expected to return a reference to the associated JarFile, rather than propagating the IOException thrown by the implicit JarURLConnection::connect invocation  in getJarFile.

The original test case demonstrates other cross platform issues in this context. But by returning the JarFile reference, ( rather than propagating the exception,)  it is then possible to invoke close on the JarFile, and allow the explicit delete of the JarFile. Thus, mitigating a perceived problem on Windows.

As such, this is an issue in its own right, and as such it would appear that there is merit in this fix.

regards
Mark



________________________________
From: net-dev <net-dev-bounces at openjdk.java.net> on behalf of Alex Kashchenko <akashche at redhat.com>
Sent: Wednesday 10 June 2020 14:52
To: OpenJDK Network Dev list <net-dev at openjdk.java.net>
Subject: Re: RFC: 8132359: JarURLConnection.getJarFile() resource leak when file is not found

Hi,

On 05/12/2020 12:20 AM, Alex Kashchenko wrote:
> CSR: https://bugs.openjdk.java.net/browse/JDK-8244650

A question about this CSR: after this new issue was found in the same area:

JDK-8246714: URLClassLoader/JAR protocol handler poisons the global
JarFile cache under concurrent load

would it be appropriate to postpone the activity on the CSR (and
possibly eventually cancel it)?

It looks like both possible solutions to 8244650:

  - short term: disable caching for JAR protocol

  - long term: rework JAR protocol handler

make this CSR redundant.

I am happy to work on some minor bugfixes in this area if necessary.

>
> [...]
>
--
-Alex

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200613/762a5588/attachment.htm>

From chris.hegarty at oracle.com  Mon Jun 15 08:52:32 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 15 Jun 2020 09:52:32 +0100
Subject: RFR 8245307 : Update ExchangeImpl to use thread safe
 DateTimeFormatter
In-Reply-To: <03f95f8d-0dac-4496-94ce-a9d418da67a3@oracle.com>
References: <0EEA206E-48F8-41E4-AB24-8C6A48C7ED26@oracle.com>
 <941e46fc-ff16-afb9-ea4d-c0ad9b65418b@oracle.com>
 <03f95f8d-0dac-4496-94ce-a9d418da67a3@oracle.com>
Message-ID: <F0D64F7F-C92E-46BE-BFBF-4F33442E9E0A@oracle.com>


> On 12 Jun 2020, at 17:55, Rahul Yadav <rahul.r.yadav at oracle.com> wrote:
> 
> ...
> 
>  http://cr.openjdk.java.net/~ryadav/webrev_8245307/index.html <http://cr.openjdk.java.net/~ryadav/webrev_8245307/index.html>

This looks v. good Rahul.

A few, mostly pedantic, comments on the test:

1) In recent times, we?ve been binding our test servers explicitly to:
     InetSocketAddress(InetAddress.getLoopbackAddress(), 0);

2) While not wrong, I don?t think that the @library tag is needed, or at least I cannot see why.

3) L109 "byte [] bytes = is.readAllBytes();? - please remove the space between `byte` and the square brackets

Overall this is a nice change.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200615/a5f2ab44/attachment.htm>

From daniel.fuchs at oracle.com  Mon Jun 15 09:28:47 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 15 Jun 2020 10:28:47 +0100
Subject: RFR 8245307 : Update ExchangeImpl to use thread safe
 DateTimeFormatter
In-Reply-To: <F0D64F7F-C92E-46BE-BFBF-4F33442E9E0A@oracle.com>
References: <0EEA206E-48F8-41E4-AB24-8C6A48C7ED26@oracle.com>
 <941e46fc-ff16-afb9-ea4d-c0ad9b65418b@oracle.com>
 <03f95f8d-0dac-4496-94ce-a9d418da67a3@oracle.com>
 <F0D64F7F-C92E-46BE-BFBF-4F33442E9E0A@oracle.com>
Message-ID: <b3be72be-7c72-8f6e-fe1a-7cc910137c40@oracle.com>

Hi Rahul,

On 15/06/2020 09:52, Chris Hegarty wrote:
> 
>> On 12 Jun 2020, at 17:55, Rahul Yadav <rahul.r.yadav at oracle.com 
>> <mailto:rahul.r.yadav at oracle.com>> wrote:
>>
>> ...
>>
>> http://cr.openjdk.java.net/~ryadav/webrev_8245307/index.html
> 
> 2) While not wrong, I don?t think that the @library tag is needed, or at 
> least I cannot see why.

I believe it would be better to avoid the reverse lookup from
the server address - as that can depend on local host configuration.

I would therefore advise to use the URIBuilder from the test library
to build the URI, so the @library tag will be needed after all :-)

Also, the test should have an
@module java.net.http
since it's using the new http client. Or Alternatively, you could
add java.net.http to the test property file for the httpserver - we
might want to use the new http client more often in the httpserver
tests:

test/jdk/com/sun/net/httpserver/TEST.properties

Otherwise looks very good to me too!

best regards,

-- daniel

From akashche at redhat.com  Mon Jun 15 10:35:19 2020
From: akashche at redhat.com (Alex Kashchenko)
Date: Mon, 15 Jun 2020 11:35:19 +0100
Subject: RFC: 8132359: JarURLConnection.getJarFile() resource leak when
 file is not found
In-Reply-To: <DBBPR09MB3014AAA136623AF8518F9367DF9E0@DBBPR09MB3014.eurprd09.prod.outlook.com>
References: <3a6b3928-8c8e-7fb8-aecd-5ace6ae18ab7@redhat.com>
 <5e148c2e-c708-aaf7-08b0-fd090ede1741@oracle.com>
 <DBBPR09MB301443A91F9B7379199D1888DFC90@DBBPR09MB3014.eurprd09.prod.outlook.com>
 <DBBPR09MB301417FAA2627B08F2D1F696DFC90@DBBPR09MB3014.eurprd09.prod.outlook.com>
 <32930d6b-0a68-832f-e8aa-69dc1b4c7c61@redhat.com>
 <3796528b-bb1e-2bb9-2c7f-f8e5ed6e378d@oracle.com>
 <25db137a-206a-4164-9ec0-0aeacb212ce7@redhat.com>
 <db10bd42-17dd-867f-9602-66f59e6bcbd2@oracle.com>
 <4a479a47-6b2b-bf12-264f-b3dd7fd9877d@oracle.com>
 <6276446d-8677-84e5-1cbb-da336f81901b@redhat.com>
 <76c99b21-6f9c-d2f8-9513-e4f3acd37e27@oracle.com>
 <DBBPR09MB3014FBFDD1D16D25EE3DA96FDFA10@DBBPR09MB3014.eurprd09.prod.outlook.com>
 <cb539b05-58c4-c9d4-65fc-99e6e610821f@redhat.com>
 <f1ab6561-96a6-e30c-5234-960c4abee7b6@redhat.com>
 <DBBPR09MB3014AAA136623AF8518F9367DF9E0@DBBPR09MB3014.eurprd09.prod.outlook.com>
Message-ID: <914d98e6-7360-375c-b34c-7a4f410e99ea@redhat.com>

Hi,

CSR: https://bugs.openjdk.java.net/browse/JDK-8244650

On 06/13/2020 10:49 PM, mark sheppard wrote:
> Hi,
>     For JDK-8132359 it now addresses the issue:
> 
> Amend JarURLConnection::getJarFile() to return JarFile object reference for nonexistent JAR file entry URL
> 
> The scenario addressed is that a JarURLConnection is constructed encapsulating a reference to an non existent entry in an extant JarFile, then the  getJarFile  is reasonably expected to return a reference to the associated JarFile, rather than propagating the IOException thrown by the implicit JarURLConnection::connect invocation  in getJarFile.
> 
> The original test case demonstrates other cross platform issues in this context. But by returning the JarFile reference, ( rather than propagating the exception,)  it is then possible to invoke close on the JarFile, and allow the explicit delete of the JarFile. Thus, mitigating a perceived problem on Windows.
> 
> As such, this is an issue in its own right, and as such it would appear that there is merit in this fix.

Thanks for your comments! Would it be appropriate to move the CSR to 
"Proposed" [1] at this point?

> 
> [...]
>

[1] https://wiki.openjdk.java.net/display/csr/Main#Main-CSRWorkflows

-- 
-Alex


From rahul.r.yadav at oracle.com  Mon Jun 15 10:41:28 2020
From: rahul.r.yadav at oracle.com (Rahul Yadav)
Date: Mon, 15 Jun 2020 11:41:28 +0100
Subject: RFR 8245307 : Update ExchangeImpl to use thread safe
 DateTimeFormatter
In-Reply-To: <b3be72be-7c72-8f6e-fe1a-7cc910137c40@oracle.com>
References: <0EEA206E-48F8-41E4-AB24-8C6A48C7ED26@oracle.com>
 <941e46fc-ff16-afb9-ea4d-c0ad9b65418b@oracle.com>
 <03f95f8d-0dac-4496-94ce-a9d418da67a3@oracle.com>
 <F0D64F7F-C92E-46BE-BFBF-4F33442E9E0A@oracle.com>
 <b3be72be-7c72-8f6e-fe1a-7cc910137c40@oracle.com>
Message-ID: <515a9e89-23a0-3e20-d382-34d529a81e42@oracle.com>

Hi Chris, Daniel

Thank you for the comments.
I have included the feedback and updated webrev.

http://cr.openjdk.java.net/~ryadav/webrev_8245307/index.html

- rahul

On 15/06/2020 10:28, Daniel Fuchs wrote:
> Hi Rahul,
>
> On 15/06/2020 09:52, Chris Hegarty wrote:
>>
>>> On 12 Jun 2020, at 17:55, Rahul Yadav <rahul.r.yadav at oracle.com 
>>> <mailto:rahul.r.yadav at oracle.com>> wrote:
>>>
>>> ...
>>>
>>> http://cr.openjdk.java.net/~ryadav/webrev_8245307/index.html
>>
>> 2) While not wrong, I don?t think that the @library tag is needed, or 
>> at least I cannot see why.
>
> I believe it would be better to avoid the reverse lookup from
> the server address - as that can depend on local host configuration.
>
> I would therefore advise to use the URIBuilder from the test library
> to build the URI, so the @library tag will be needed after all :-)
>
> Also, the test should have an
> @module java.net.http
> since it's using the new http client. Or Alternatively, you could
> add java.net.http to the test property file for the httpserver - we
> might want to use the new http client more often in the httpserver
> tests:
>
> test/jdk/com/sun/net/httpserver/TEST.properties
>
> Otherwise looks very good to me too!
>
> best regards,
>
> -- daniel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200615/122a972d/attachment.htm>

From chris.hegarty at oracle.com  Mon Jun 15 10:50:28 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 15 Jun 2020 11:50:28 +0100
Subject: RFR 8245307 : Update ExchangeImpl to use thread safe
 DateTimeFormatter
In-Reply-To: <515a9e89-23a0-3e20-d382-34d529a81e42@oracle.com>
References: <0EEA206E-48F8-41E4-AB24-8C6A48C7ED26@oracle.com>
 <941e46fc-ff16-afb9-ea4d-c0ad9b65418b@oracle.com>
 <03f95f8d-0dac-4496-94ce-a9d418da67a3@oracle.com>
 <F0D64F7F-C92E-46BE-BFBF-4F33442E9E0A@oracle.com>
 <b3be72be-7c72-8f6e-fe1a-7cc910137c40@oracle.com>
 <515a9e89-23a0-3e20-d382-34d529a81e42@oracle.com>
Message-ID: <EB9335CF-BE07-4BED-A2B5-D200E88A746F@oracle.com>



> On 15 Jun 2020, at 11:41, Rahul Yadav <rahul.r.yadav at oracle.com> wrote:
> 
> Hi Chris, Daniel
> 
> Thank you for the comments.
> I have included the feedback and updated webrev.
> 
> http://cr.openjdk.java.net/~ryadav/webrev_8245307/index.html <http://cr.openjdk.java.net/~ryadav/webrev_8245307/index.html>
> 
LGTM. Ship it!

-Chris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200615/57959453/attachment-0001.htm>

From daniel.fuchs at oracle.com  Mon Jun 15 11:57:35 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 15 Jun 2020 12:57:35 +0100
Subject: RFR 8245307 : Update ExchangeImpl to use thread safe
 DateTimeFormatter
In-Reply-To: <515a9e89-23a0-3e20-d382-34d529a81e42@oracle.com>
References: <0EEA206E-48F8-41E4-AB24-8C6A48C7ED26@oracle.com>
 <941e46fc-ff16-afb9-ea4d-c0ad9b65418b@oracle.com>
 <03f95f8d-0dac-4496-94ce-a9d418da67a3@oracle.com>
 <F0D64F7F-C92E-46BE-BFBF-4F33442E9E0A@oracle.com>
 <b3be72be-7c72-8f6e-fe1a-7cc910137c40@oracle.com>
 <515a9e89-23a0-3e20-d382-34d529a81e42@oracle.com>
Message-ID: <15986717-7701-ea7f-70ee-22f4956692c7@oracle.com>

Thanks Rahul!

Looks good to me too :-)

best regards,

-- daniel

On 15/06/2020 11:41, Rahul Yadav wrote:
> Hi Chris, Daniel
> 
> Thank you for the comments.
> I have included the feedback and updated webrev.
> 
> http://cr.openjdk.java.net/~ryadav/webrev_8245307/index.html
> 
> - rahul
> 



From macanaoire at hotmail.com  Mon Jun 15 12:05:42 2020
From: macanaoire at hotmail.com (mark sheppard)
Date: Mon, 15 Jun 2020 12:05:42 +0000
Subject: RFC: 8132359: JarURLConnection.getJarFile() resource leak when
 file is not found
In-Reply-To: <914d98e6-7360-375c-b34c-7a4f410e99ea@redhat.com>
References: <3a6b3928-8c8e-7fb8-aecd-5ace6ae18ab7@redhat.com>
 <5e148c2e-c708-aaf7-08b0-fd090ede1741@oracle.com>
 <DBBPR09MB301443A91F9B7379199D1888DFC90@DBBPR09MB3014.eurprd09.prod.outlook.com>
 <DBBPR09MB301417FAA2627B08F2D1F696DFC90@DBBPR09MB3014.eurprd09.prod.outlook.com>
 <32930d6b-0a68-832f-e8aa-69dc1b4c7c61@redhat.com>
 <3796528b-bb1e-2bb9-2c7f-f8e5ed6e378d@oracle.com>
 <25db137a-206a-4164-9ec0-0aeacb212ce7@redhat.com>
 <db10bd42-17dd-867f-9602-66f59e6bcbd2@oracle.com>
 <4a479a47-6b2b-bf12-264f-b3dd7fd9877d@oracle.com>
 <6276446d-8677-84e5-1cbb-da336f81901b@redhat.com>
 <76c99b21-6f9c-d2f8-9513-e4f3acd37e27@oracle.com>
 <DBBPR09MB3014FBFDD1D16D25EE3DA96FDFA10@DBBPR09MB3014.eurprd09.prod.outlook.com>
 <cb539b05-58c4-c9d4-65fc-99e6e610821f@redhat.com>
 <f1ab6561-96a6-e30c-5234-960c4abee7b6@redhat.com>
 <DBBPR09MB3014AAA136623AF8518F9367DF9E0@DBBPR09MB3014.eurprd09.prod.outlook.com>,
 <914d98e6-7360-375c-b34c-7a4f410e99ea@redhat.com>
Message-ID: <DBBPR09MB3014E4EC0035DCA4EF2C76B0DF9C0@DBBPR09MB3014.eurprd09.prod.outlook.com>

Hi Alex,
   I think there is some other work planned in this area,
so it may be best to place this item on hold for a bit.
There should be an update on this shortly.

regards
Mark

________________________________
From: Alex Kashchenko <akashche at redhat.com>
Sent: Monday 15 June 2020 10:35
To: mark sheppard <macanaoire at hotmail.com>; OpenJDK Network Dev list <net-dev at openjdk.java.net>
Cc: Mark Sheppard <mark.sheppard at oracle.com>
Subject: Re: RFC: 8132359: JarURLConnection.getJarFile() resource leak when file is not found

Hi,

CSR: https://bugs.openjdk.java.net/browse/JDK-8244650

On 06/13/2020 10:49 PM, mark sheppard wrote:
> Hi,
>     For JDK-8132359 it now addresses the issue:
>
> Amend JarURLConnection::getJarFile() to return JarFile object reference for nonexistent JAR file entry URL
>
> The scenario addressed is that a JarURLConnection is constructed encapsulating a reference to an non existent entry in an extant JarFile, then the  getJarFile  is reasonably expected to return a reference to the associated JarFile, rather than propagating the IOException thrown by the implicit JarURLConnection::connect invocation  in getJarFile.
>
> The original test case demonstrates other cross platform issues in this context. But by returning the JarFile reference, ( rather than propagating the exception,)  it is then possible to invoke close on the JarFile, and allow the explicit delete of the JarFile. Thus, mitigating a perceived problem on Windows.
>
> As such, this is an issue in its own right, and as such it would appear that there is merit in this fix.

Thanks for your comments! Would it be appropriate to move the CSR to
"Proposed" [1] at this point?

>
> [...]
>

[1] https://wiki.openjdk.java.net/display/csr/Main#Main-CSRWorkflows

--
-Alex

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200615/7a1909c7/attachment.htm>

From chris.hegarty at oracle.com  Mon Jun 15 12:46:03 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 15 Jun 2020 13:46:03 +0100
Subject: RFC: 8132359: JarURLConnection.getJarFile() resource leak when
 file is not found
In-Reply-To: <DBBPR09MB3014E4EC0035DCA4EF2C76B0DF9C0@DBBPR09MB3014.eurprd09.prod.outlook.com>
References: <3a6b3928-8c8e-7fb8-aecd-5ace6ae18ab7@redhat.com>
 <5e148c2e-c708-aaf7-08b0-fd090ede1741@oracle.com>
 <DBBPR09MB301443A91F9B7379199D1888DFC90@DBBPR09MB3014.eurprd09.prod.outlook.com>
 <DBBPR09MB301417FAA2627B08F2D1F696DFC90@DBBPR09MB3014.eurprd09.prod.outlook.com>
 <32930d6b-0a68-832f-e8aa-69dc1b4c7c61@redhat.com>
 <3796528b-bb1e-2bb9-2c7f-f8e5ed6e378d@oracle.com>
 <25db137a-206a-4164-9ec0-0aeacb212ce7@redhat.com>
 <db10bd42-17dd-867f-9602-66f59e6bcbd2@oracle.com>
 <4a479a47-6b2b-bf12-264f-b3dd7fd9877d@oracle.com>
 <6276446d-8677-84e5-1cbb-da336f81901b@redhat.com>
 <76c99b21-6f9c-d2f8-9513-e4f3acd37e27@oracle.com>
 <DBBPR09MB3014FBFDD1D16D25EE3DA96FDFA10@DBBPR09MB3014.eurprd09.prod.outlook.com>
 <cb539b05-58c4-c9d4-65fc-99e6e610821f@redhat.com>
 <f1ab6561-96a6-e30c-5234-960c4abee7b6@redhat.com>
 <DBBPR09MB3014AAA136623AF8518F9367DF9E0@DBBPR09MB3014.eurprd09.prod.outlook.com>
 <914d98e6-7360-375c-b34c-7a4f410e99ea@redhat.com>
 <DBBPR09MB3014E4EC0035DCA4EF2C76B0DF9C0@DBBPR09MB3014.eurprd09.prod.outlook.com>
Message-ID: <9D7DAE86-A1F3-4861-85D0-8777F6B7BF1B@oracle.com>

Hi Alex, Mark,

While I think that change for this issue is good, I would like to request that we please put it on hold temporarily.

I will experiment with possible solutions for 8246714 - the URLClassLoader issue. It may result in no overlap with this issue, 8132359, but it seems prudent to allow that experimentation to happen first.

Sorry to be asking that this issue wait, I don?t do this lightly or often, but it seems like the right thing to do.

-Chris.

> On 15 Jun 2020, at 13:05, mark sheppard <macanaoire at hotmail.com> wrote:
> 
> Hi Alex,
>    I think there is some other work planned in this area,
> so it may be best to place this item on hold for a bit.
> There should be an update on this shortly.
> 
> regards
> Mark
> 
> From: Alex Kashchenko <akashche at redhat.com>
> Sent: Monday 15 June 2020 10:35
> To: mark sheppard <macanaoire at hotmail.com>; OpenJDK Network Dev list <net-dev at openjdk.java.net>
> Cc: Mark Sheppard <mark.sheppard at oracle.com>
> Subject: Re: RFC: 8132359: JarURLConnection.getJarFile() resource leak when file is not found
>  
> Hi,
> 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8244650 <https://bugs.openjdk.java.net/browse/JDK-8244650>
> 
> On 06/13/2020 10:49 PM, mark sheppard wrote:
> > Hi,
> >     For JDK-8132359 it now addresses the issue:
> > 
> > Amend JarURLConnection::getJarFile() to return JarFile object reference for nonexistent JAR file entry URL
> > 
> > The scenario addressed is that a JarURLConnection is constructed encapsulating a reference to an non existent entry in an extant JarFile, then the  getJarFile  is reasonably expected to return a reference to the associated JarFile, rather than propagating the IOException thrown by the implicit JarURLConnection::connect invocation  in getJarFile.
> > 
> > The original test case demonstrates other cross platform issues in this context. But by returning the JarFile reference, ( rather than propagating the exception,)  it is then possible to invoke close on the JarFile, and allow the explicit delete of the JarFile. Thus, mitigating a perceived problem on Windows.
> > 
> > As such, this is an issue in its own right, and as such it would appear that there is merit in this fix.
> 
> Thanks for your comments! Would it be appropriate to move the CSR to 
> "Proposed" [1] at this point?
> 
> > 
> > [...]
> >
> 
> [1] https://wiki.openjdk.java.net/display/csr/Main#Main-CSRWorkflows <https://wiki.openjdk.java.net/display/csr/Main#Main-CSRWorkflows>
> 
> -- 
> -Alex

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200615/4ace4856/attachment-0001.htm>

From daniel.fuchs at oracle.com  Mon Jun 15 15:23:42 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 15 Jun 2020 16:23:42 +0100
Subject: RFR 8245307 : Update ExchangeImpl to use thread safe
 DateTimeFormatter
In-Reply-To: <515a9e89-23a0-3e20-d382-34d529a81e42@oracle.com>
References: <0EEA206E-48F8-41E4-AB24-8C6A48C7ED26@oracle.com>
 <941e46fc-ff16-afb9-ea4d-c0ad9b65418b@oracle.com>
 <03f95f8d-0dac-4496-94ce-a9d418da67a3@oracle.com>
 <F0D64F7F-C92E-46BE-BFBF-4F33442E9E0A@oracle.com>
 <b3be72be-7c72-8f6e-fe1a-7cc910137c40@oracle.com>
 <515a9e89-23a0-3e20-d382-34d529a81e42@oracle.com>
Message-ID: <4a3795f7-1b92-d354-ea23-30f7a16138e8@oracle.com>

Hi Rahul,

Sorry I didn't catch that earlier, but your test has the
wrong copyright notice. We do not have the "Classpath"
exception in tests.

best regards,

-- daniel

On 15/06/2020 11:41, Rahul Yadav wrote:
> Hi Chris, Daniel
> 
> Thank you for the comments.
> I have included the feedback and updated webrev.
> 
> http://cr.openjdk.java.net/~ryadav/webrev_8245307/index.html
> 
> - rahul
> 


From rahul.r.yadav at oracle.com  Mon Jun 15 15:50:27 2020
From: rahul.r.yadav at oracle.com (Rahul Yadav)
Date: Mon, 15 Jun 2020 16:50:27 +0100
Subject: RFR 8245307 : Update ExchangeImpl to use thread safe
 DateTimeFormatter
In-Reply-To: <4a3795f7-1b92-d354-ea23-30f7a16138e8@oracle.com>
References: <0EEA206E-48F8-41E4-AB24-8C6A48C7ED26@oracle.com>
 <941e46fc-ff16-afb9-ea4d-c0ad9b65418b@oracle.com>
 <03f95f8d-0dac-4496-94ce-a9d418da67a3@oracle.com>
 <F0D64F7F-C92E-46BE-BFBF-4F33442E9E0A@oracle.com>
 <b3be72be-7c72-8f6e-fe1a-7cc910137c40@oracle.com>
 <515a9e89-23a0-3e20-d382-34d529a81e42@oracle.com>
 <4a3795f7-1b92-d354-ea23-30f7a16138e8@oracle.com>
Message-ID: <11c0d00e-49dd-d156-3369-95d1c45e2b7e@oracle.com>

Hi Daniel,

I have updated the copyright notice.

On 15/06/2020 16:23, Daniel Fuchs wrote:
> Hi Rahul,
>
> Sorry I didn't catch that earlier, but your test has the
> wrong copyright notice. We do not have the "Classpath"
> exception in tests.
>
> best regards,
>
> -- daniel
>
> On 15/06/2020 11:41, Rahul Yadav wrote:
>> Hi Chris, Daniel
>>
>> Thank you for the comments.
>> I have included the feedback and updated webrev.
>>
>> http://cr.openjdk.java.net/~ryadav/webrev_8245307/index.html
>>
>> - rahul
>>
>


From mark.sheppard at oracle.com  Mon Jun 15 18:25:26 2020
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Mon, 15 Jun 2020 11:25:26 -0700 (PDT)
Subject: RFC: 8132359: JarURLConnection.getJarFile() resource leak when
 file is not found
Message-ID: <18b4d5dd-083c-4138-9a7d-2b8d013d276a@default>

Hi Chris, 
sounds good .... thanks for the update 


regards 
Mark 



----- Original Message ----- 
From: chris.hegarty at oracle.com 
To: akashche at redhat.com, net-dev at openjdk.java.net, mark.sheppard at oracle.com 
Sent: Monday, 15 June, 2020 1:46:06 PM GMT +00:00 GMT Britain, Ireland, Portugal 
Subject: Re: RFC: 8132359: JarURLConnection.getJarFile() resource leak when file is not found 


Hi Alex, Mark, 


While I think that change for this issue is good, I would like to request that we please put it on hold temporarily. 


I will experiment with possible solutions for 8246714 - the URLClassLoader issue. It may result in no overlap with this issue, 8132359, but it seems prudent to allow that experimentation to happen first. 


Sorry to be asking that this issue wait, I don?t do this lightly or often, but it seems like the right thing to do. 


-Chris. 





On 15 Jun 2020, at 13:05, mark sheppard < macanaoire at hotmail.com > wrote: 


Hi Alex, 
I think there is some other work planned in this area, 
so it may be best to place this item on hold for a bit. 
There should be an update on this shortly. 


regards 
Mark 





From: Alex Kashchenko < akashche at redhat.com > 
Sent: Monday 15 June 2020 10:35 
To: mark sheppard < macanaoire at hotmail.com >; OpenJDK Network Dev list < net-dev at openjdk.java.net > 
Cc: Mark Sheppard < mark.sheppard at oracle.com > 
Subject: Re: RFC: 8132359: JarURLConnection.getJarFile() resource leak when file is not found 


Hi, 

CSR: https://bugs.openjdk.java.net/browse/JDK-8244650 

On 06/13/2020 10:49 PM, mark sheppard wrote: 
> Hi, 
> For JDK-8132359 it now addresses the issue: 
> 
> Amend JarURLConnection::getJarFile() to return JarFile object reference for nonexistent JAR file entry URL 
> 
> The scenario addressed is that a JarURLConnection is constructed encapsulating a reference to an non existent entry in an extant JarFile, then the getJarFile is reasonably expected to return a reference to the associated JarFile, rather than propagating the IOException thrown by the implicit JarURLConnection::connect invocation in getJarFile. 
> 
> The original test case demonstrates other cross platform issues in this context. But by returning the JarFile reference, ( rather than propagating the exception,) it is then possible to invoke close on the JarFile, and allow the explicit delete of the JarFile. Thus, mitigating a perceived problem on Windows. 
> 
> As such, this is an issue in its own right, and as such it would appear that there is merit in this fix. 

Thanks for your comments! Would it be appropriate to move the CSR to 
"Proposed" [1] at this point? 

> 
> [...] 
> 

[1] https://wiki.openjdk.java.net/display/csr/Main#Main-CSRWorkflows 

-- 
-Alex 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200615/ef833e5c/attachment.htm>

From rahul.r.yadav at oracle.com  Tue Jun 16 10:37:50 2020
From: rahul.r.yadav at oracle.com (Rahul Yadav)
Date: Tue, 16 Jun 2020 11:37:50 +0100
Subject: RFR 8247675 : Update DateFormatterTest Copyright
In-Reply-To: <95dbd82d-42cc-1f29-f1e7-0c913ae9cd59@oracle.com>
References: <95dbd82d-42cc-1f29-f1e7-0c913ae9cd59@oracle.com>
Message-ID: <0c605db8-b008-a5a0-f23a-2c348cd558ab@oracle.com>

Hello,

Request to have my fix reviewed for issue:

JDK-8247675 :? Update DateFormatterTest Copyright

The fix updates the test DateFormatterTest, adds the missing
comma(,) to the copyright year.

Issue:??? https://bugs.openjdk.java.net/browse/JDK-8247675
webrev: http://cr.openjdk.java.net/~ryadav/webrev_8247675/index.html

- rahul

From chris.hegarty at oracle.com  Tue Jun 16 10:59:01 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 16 Jun 2020 11:59:01 +0100
Subject: RFR 8247675 : Update DateFormatterTest Copyright
In-Reply-To: <0c605db8-b008-a5a0-f23a-2c348cd558ab@oracle.com>
References: <95dbd82d-42cc-1f29-f1e7-0c913ae9cd59@oracle.com>
 <0c605db8-b008-a5a0-f23a-2c348cd558ab@oracle.com>
Message-ID: <2F94EAD8-2429-41CF-B52B-0F37458F4D5D@oracle.com>



> On 16 Jun 2020, at 11:37, Rahul Yadav <rahul.r.yadav at oracle.com> wrote:
> 
> Hello,
> 
> Request to have my fix reviewed for issue:
> 
> JDK-8247675 :  Update DateFormatterTest Copyright
> 
> The fix updates the test DateFormatterTest, adds the missing
> comma(,) to the copyright year.
> 
> Issue:    https://bugs.openjdk.java.net/browse/JDK-8247675
> webrev: http://cr.openjdk.java.net/~ryadav/webrev_8247675/index.html
> 
LGTM.

-Chris.

From daniel.fuchs at oracle.com  Tue Jun 16 11:00:50 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 16 Jun 2020 12:00:50 +0100
Subject: RFR 8247675 : Update DateFormatterTest Copyright
In-Reply-To: <0c605db8-b008-a5a0-f23a-2c348cd558ab@oracle.com>
References: <95dbd82d-42cc-1f29-f1e7-0c913ae9cd59@oracle.com>
 <0c605db8-b008-a5a0-f23a-2c348cd558ab@oracle.com>
Message-ID: <a49b5eda-edba-4566-93b7-ed22c20cefcd@oracle.com>

Looks good Rahul,

Please regenerate the changeset with the appropriate comment
and list me as reviewer and I'll push it for you.

best regards,

-- daniel

On 16/06/2020 11:37, Rahul Yadav wrote:
> Hello,
> 
> Request to have my fix reviewed for issue:
> 
> JDK-8247675 :? Update DateFormatterTest Copyright
> 
> The fix updates the test DateFormatterTest, adds the missing
> comma(,) to the copyright year.
> 
> Issue:??? https://bugs.openjdk.java.net/browse/JDK-8247675
> webrev: http://cr.openjdk.java.net/~ryadav/webrev_8247675/index.html
> 
> - rahul


From vyommani at gmail.com  Wed Jun 17 10:04:20 2020
From: vyommani at gmail.com (Vyom Tiwari)
Date: Wed, 17 Jun 2020 15:34:20 +0530
Subject: RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR
 incorrectly
In-Reply-To: <242fe9b7-b9bc-03b9-0f5e-b0d01775fb64@oracle.com>
References: <eb820990-538f-6462-83f1-00db9c5addb9@oracle.com>
 <643c705c-7ff9-c06e-81d6-b568fb2f9464@oracle.com>
 <315dfbdb-b27a-4e9c-067a-81718ef0645f@oracle.com>
 <OFE61C7987.C97DF629-ON00258519.004BEA69-00258519.005B3C41@notes.na.collabserv.com>
 <OF56E349E5.3746C443-ON00258527.005A4210-00258527.005CC3C4@notes.na.collabserv.com>
 <OFAA5282CA.C667B8FA-ON00258528.001143A6-00258528.0011D91A@notes.na.collabserv.com>
 <OF5EC3FD65.03E16FA0-ON00258528.002A5E98-00258528.002CC5FB@notes.na.collabserv.com>
 <de408110-7b0d-d630-1783-5e48e034d1f7@oracle.com>
 <DB7PR03MB439343CCC0E3DB80F5976F89FFFC0@DB7PR03MB4393.eurprd03.prod.outlook.com>
 <CAKysZ8yw=7kbG+THEKEi3DY3RoeS55tt=-zP0PfZXqeg4inz8w@mail.gmail.com>
 <242fe9b7-b9bc-03b9-0f5e-b0d01775fb64@oracle.com>
Message-ID: <CAKysZ8z725FrYLcfrj5muD-AfAPda6nyksyXMVJrMM4475MzHw@mail.gmail.com>

Hi Alan,

Please find the  latest webrev(
http://cr.openjdk.java.net/~vtewari/8237858/webrev0.3/index.html). I tried
to incorporate the suggestion given by you.I created the NativeThread class
which  has  functions that send signals to threads.

Note: I am facing some compilation issue when i am trying to build my
native code using JDK builds scripts, i am hoping someone will help to
resolve this issue. I manually build the native library and copy in the
required folder before running my tests.

Thanks,
Vyom

On Tue, Mar 17, 2020 at 12:33 PM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

>
>
> On 17/03/2020 05:21, Vyom Tiwari wrote:
> > Hi Daniel/Michael,
> >
> > Please find the latest
> > webrev(http://cr.openjdk.java.net/~vtewari/8237858/webrev0.2/index.html),
>
> > where i put a test case as well.
> >
> Can you look at make/test/JtregNativeJdk.gmk? That should give you ideas
> on how to develop tests that use JNI code. You should just need two
> native methods, one to call pthread_self, the other call pthread_kill.
> It could potentially use sun.nio.ch.NativeThread but we'll see how far
> you get first. Once you have the primitives it should be easy to create
> a test that signals a thread blocked in read, write or accept.
>
> -Alan
>


-- 
Thanks,
Vyom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200617/be6cb358/attachment.htm>

From vyommani at gmail.com  Thu Jun 18 08:02:26 2020
From: vyommani at gmail.com (Vyom Tiwari)
Date: Thu, 18 Jun 2020 13:32:26 +0530
Subject: RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR
 incorrectly
In-Reply-To: <CAKysZ8z725FrYLcfrj5muD-AfAPda6nyksyXMVJrMM4475MzHw@mail.gmail.com>
References: <eb820990-538f-6462-83f1-00db9c5addb9@oracle.com>
 <643c705c-7ff9-c06e-81d6-b568fb2f9464@oracle.com>
 <315dfbdb-b27a-4e9c-067a-81718ef0645f@oracle.com>
 <OFE61C7987.C97DF629-ON00258519.004BEA69-00258519.005B3C41@notes.na.collabserv.com>
 <OF56E349E5.3746C443-ON00258527.005A4210-00258527.005CC3C4@notes.na.collabserv.com>
 <OFAA5282CA.C667B8FA-ON00258528.001143A6-00258528.0011D91A@notes.na.collabserv.com>
 <OF5EC3FD65.03E16FA0-ON00258528.002A5E98-00258528.002CC5FB@notes.na.collabserv.com>
 <de408110-7b0d-d630-1783-5e48e034d1f7@oracle.com>
 <DB7PR03MB439343CCC0E3DB80F5976F89FFFC0@DB7PR03MB4393.eurprd03.prod.outlook.com>
 <CAKysZ8yw=7kbG+THEKEi3DY3RoeS55tt=-zP0PfZXqeg4inz8w@mail.gmail.com>
 <242fe9b7-b9bc-03b9-0f5e-b0d01775fb64@oracle.com>
 <CAKysZ8z725FrYLcfrj5muD-AfAPda6nyksyXMVJrMM4475MzHw@mail.gmail.com>
Message-ID: <CAKysZ8zX44bGfHqXUXX4GXTr04-oA-BPSU5gwmKU_x=t7-=Dow@mail.gmail.com>

Hi,
Please find the latest webrev(
http://cr.openjdk.java.net/~vtewari/8237858/webrev0.4/index.html) where i
fix the build issue as well.

Thanks,
Vyom

On Wed, Jun 17, 2020 at 3:34 PM Vyom Tiwari <vyommani at gmail.com> wrote:

> Hi Alan,
>
> Please find the  latest webrev(
> http://cr.openjdk.java.net/~vtewari/8237858/webrev0.3/index.html). I
> tried to incorporate the suggestion given by you.I created the NativeThread
> class which  has  functions that send signals to threads.
>
> Note: I am facing some compilation issue when i am trying to build my
> native code using JDK builds scripts, i am hoping someone will help to
> resolve this issue. I manually build the native library and copy in the
> required folder before running my tests.
>
> Thanks,
> Vyom
>
> On Tue, Mar 17, 2020 at 12:33 PM Alan Bateman <Alan.Bateman at oracle.com>
> wrote:
>
>>
>>
>> On 17/03/2020 05:21, Vyom Tiwari wrote:
>> > Hi Daniel/Michael,
>> >
>> > Please find the latest
>> > webrev(http://cr.openjdk.java.net/~vtewari/8237858/webrev0.2/index.html),
>>
>> > where i put a test case as well.
>> >
>> Can you look at make/test/JtregNativeJdk.gmk? That should give you ideas
>> on how to develop tests that use JNI code. You should just need two
>> native methods, one to call pthread_self, the other call pthread_kill.
>> It could potentially use sun.nio.ch.NativeThread but we'll see how far
>> you get first. Once you have the primitives it should be easy to create
>> a test that signals a thread blocked in read, write or accept.
>>
>> -Alan
>>
>
>
> --
> Thanks,
> Vyom
>


-- 
Thanks,
Vyom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200618/cde6e04d/attachment.htm>

From Alan.Bateman at oracle.com  Tue Jun 23 12:07:29 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 23 Jun 2020 13:07:29 +0100
Subject: RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR
 incorrectly
In-Reply-To: <CAKysZ8zX44bGfHqXUXX4GXTr04-oA-BPSU5gwmKU_x=t7-=Dow@mail.gmail.com>
References: <eb820990-538f-6462-83f1-00db9c5addb9@oracle.com>
 <643c705c-7ff9-c06e-81d6-b568fb2f9464@oracle.com>
 <315dfbdb-b27a-4e9c-067a-81718ef0645f@oracle.com>
 <OFE61C7987.C97DF629-ON00258519.004BEA69-00258519.005B3C41@notes.na.collabserv.com>
 <OF56E349E5.3746C443-ON00258527.005A4210-00258527.005CC3C4@notes.na.collabserv.com>
 <OFAA5282CA.C667B8FA-ON00258528.001143A6-00258528.0011D91A@notes.na.collabserv.com>
 <OF5EC3FD65.03E16FA0-ON00258528.002A5E98-00258528.002CC5FB@notes.na.collabserv.com>
 <de408110-7b0d-d630-1783-5e48e034d1f7@oracle.com>
 <DB7PR03MB439343CCC0E3DB80F5976F89FFFC0@DB7PR03MB4393.eurprd03.prod.outlook.com>
 <CAKysZ8yw=7kbG+THEKEi3DY3RoeS55tt=-zP0PfZXqeg4inz8w@mail.gmail.com>
 <242fe9b7-b9bc-03b9-0f5e-b0d01775fb64@oracle.com>
 <CAKysZ8z725FrYLcfrj5muD-AfAPda6nyksyXMVJrMM4475MzHw@mail.gmail.com>
 <CAKysZ8zX44bGfHqXUXX4GXTr04-oA-BPSU5gwmKU_x=t7-=Dow@mail.gmail.com>
Message-ID: <cc1740b0-8f40-9586-cc94-311fcc47dc4f@oracle.com>

On 18/06/2020 09:02, Vyom Tiwari wrote:
> Hi,
> Please find the latest 
> webrev(http://cr.openjdk.java.net/~vtewari/8237858/webrev0.4/index.html) 
> where i fix the build issue as well.
>
The update to linux_close.c and bsd_close.c look okay but please use "if 
(timeout > 0) {" to keep the code consistent.

I think the test needs a bit of work. The setup of the signal handler 
NativeThread_init doesn't look right - why is the test doing this? Also 
what is the reason for the signal handle trying to terminate the thread. 
It might be better to start again on the test and just have a thread 
asynchronously signalling another thread while it does timed and untimed 
blocking operations.

-Alan.



From daniel.fuchs at oracle.com  Tue Jun 23 12:14:50 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 23 Jun 2020 13:14:50 +0100
Subject: RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR
 incorrectly
In-Reply-To: <CAKysZ8zX44bGfHqXUXX4GXTr04-oA-BPSU5gwmKU_x=t7-=Dow@mail.gmail.com>
References: <eb820990-538f-6462-83f1-00db9c5addb9@oracle.com>
 <643c705c-7ff9-c06e-81d6-b568fb2f9464@oracle.com>
 <315dfbdb-b27a-4e9c-067a-81718ef0645f@oracle.com>
 <OFE61C7987.C97DF629-ON00258519.004BEA69-00258519.005B3C41@notes.na.collabserv.com>
 <OF56E349E5.3746C443-ON00258527.005A4210-00258527.005CC3C4@notes.na.collabserv.com>
 <OFAA5282CA.C667B8FA-ON00258528.001143A6-00258528.0011D91A@notes.na.collabserv.com>
 <OF5EC3FD65.03E16FA0-ON00258528.002A5E98-00258528.002CC5FB@notes.na.collabserv.com>
 <de408110-7b0d-d630-1783-5e48e034d1f7@oracle.com>
 <DB7PR03MB439343CCC0E3DB80F5976F89FFFC0@DB7PR03MB4393.eurprd03.prod.outlook.com>
 <CAKysZ8yw=7kbG+THEKEi3DY3RoeS55tt=-zP0PfZXqeg4inz8w@mail.gmail.com>
 <242fe9b7-b9bc-03b9-0f5e-b0d01775fb64@oracle.com>
 <CAKysZ8z725FrYLcfrj5muD-AfAPda6nyksyXMVJrMM4475MzHw@mail.gmail.com>
 <CAKysZ8zX44bGfHqXUXX4GXTr04-oA-BPSU5gwmKU_x=t7-=Dow@mail.gmail.com>
Message-ID: <655d84a0-648a-8217-99da-df87b16b7251@oracle.com>

Hi Vyom,

Just to let you know that the new SocketAcceptInterruptTest test
seems to have some stability issues. Patrick imported your test
and ran it on our test system.

We got one crash (SIGSEV) on macOS with the first @run that uses
the old impl, and a timeout with the second @run that uses the new
impl.

I see that your test installs a signal handler that calls
pthread_exit((void *)0); Is that really necessary?
I am suspecting that this might be at the root cause of the crash.

 From the test output:

run main/othervm/native -Djdk.net.usePlainSocketImpl=true 
SocketAcceptInterruptTest
----------System.out:(20/1144)----------
Sending SIGPIPE to ServerSocket thread.
Sending close Signal to server thread...
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x000000010399ac75, pid=30406, tid=12803
#
# JRE version: Java(TM) SE Runtime Environment (16.0) (build 
16-internal+0-2020-06-22-1056440.patrick.concannon.openJDK)
# Java VM: Java HotSpot(TM) 64-Bit Server VM 
(16-internal+0-2020-06-22-1056440.patrick.concannon.openJDK, mixed mode, 
sharing, tiered, compressed oops, g1 gc, bsd-amd64)
# Problematic frame:
# V  [libjvm.dylib+0x39ac75] 
_ZNK5frame28sender_for_interpreter_frameEP11RegisterMap+0x15
#

and in the hs_err file:

---------------  T H R E A D  ---------------

Current thread (0x00007fe72b523270):  GCTaskThread "GC Thread#0" [stack: 
0x0000700006bc8000,0x0000700006cc8000] [id=12803]

Stack: [0x0000700006bc8000,0x0000700006cc8000],  sp=0x0000700006cc6a60, 
free space=1018k
Native frames: (J=compiled Java code, A=aot compiled Java code, 
j=interpreted, Vv=VM code, C=native code)
V  [libjvm.dylib+0x39ac75] 
_ZNK5frame28sender_for_interpreter_frameEP11RegisterMap+0x15
V  [libjvm.dylib+0x39a99d]  _ZNK5frame6senderEP11RegisterMap+0x4d
V  [libjvm.dylib+0x997f4e] 
_ZN10JavaThread11nmethods_doEP15CodeBlobClosure+0x9e
V  [libjvm.dylib+0x99973c] 
_ZN7Threads28possibly_parallel_threads_doEbP13ThreadClosure+0x8c
V  [libjvm.dylib+0x8b5c59]  _ZN21ParallelSPCleanupTask4workEj+0x29
V  [libjvm.dylib+0xa3cc1d]  _ZN10GangWorker4loopEv+0x4d
V  [libjvm.dylib+0x992ad1]  _ZN6Thread8call_runEv+0x71
V  [libjvm.dylib+0x825177]  _ZL19thread_native_entryP6Thread+0x197
C  [libsystem_pthread.dylib+0x3661]  _pthread_body+0x154
C  [libsystem_pthread.dylib+0x350d]  _pthread_body+0x0
C  [libsystem_pthread.dylib+0x2bf9]  thread_start+0xd


siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 
0x0000700007dfa720

=======================================================================

For the second @run - the test failed in timeout:

run main/othervm/native SocketAcceptInterruptTest
----------System.out:(3/107)----------
Sending SIGPIPE to ServerSocket thread.
Sending close Signal to server thread...
Timeout refired 480 times

best regards,

-- daniel

On 18/06/2020 09:02, Vyom Tiwari wrote:
> Hi,
> Please find the latest 
> webrev(http://cr.openjdk.java.net/~vtewari/8237858/webrev0.4/index.html) 
> where i fix the build issue as well.
> 
> Thanks,
> Vyom
> 


From daniel.fuchs at oracle.com  Tue Jun 23 17:47:51 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 23 Jun 2020 18:47:51 +0100
Subject: 8245462: HttpClient send throws InterruptedException when interrupted
 but does not cancel request
Message-ID: <14613d53-0105-cc57-b082-7c2691a8be6e@oracle.com>

Hi,

Please find below a fix for:
8245462: HttpClient send throws InterruptedException when
          interrupted but does not cancel request
https://bugs.openjdk.java.net/browse/JDK-8245462

webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8245462/webrev.00/index.html

The fix goes beyond fixing the problem described in the issue and
provides a way for cancelling asynchronous requests too.

Indeed, up to now the HttpClient didn't provide an easy way to
stop/cancel an ongoing HTTP request.
Up to now the only possible way of doing that would have been
to provide your own BodyPublisher/BodyHandler/BodySubsriber so
that you could stop sending the request body (by invoking onError
on the HttpClient subscriber) or stop the reception of the response
body (by cancelling the subsription you were given). However there
would be no way to stop the request outside of these limits.
If the request body was already sent, you would have to wait for
the response headers to have been received before you could
actually attempt to interrupt the exchange.
This is a bit of a shame since the HTTP/2 protocol does allow
for resetting streams if the client is no longer interested
in receiving a response.

This fix proposes to arrange for the HTTP exchange to be
stopped/cancelled if `cancel(true)` is invoked on the
CompletableFuture<> objects the default implementation
of the HttpClient returns, or on completable futures derived
from them. This makes it possible for the HttpClient implementation
to take note of the cancellation request asynchronously and then
stop the exchange as soon as it can.

The synchronous HttpClient::send also makes use of this new mechanism
to attempt to stop/cancel the exchange if the thread is interrupted
while it waits for the completable future to be completed.

best regards,

-- daniel

From vyommani at gmail.com  Wed Jun 24 04:53:52 2020
From: vyommani at gmail.com (Vyom Tiwari)
Date: Wed, 24 Jun 2020 10:23:52 +0530
Subject: RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR
 incorrectly
In-Reply-To: <655d84a0-648a-8217-99da-df87b16b7251@oracle.com>
References: <eb820990-538f-6462-83f1-00db9c5addb9@oracle.com>
 <643c705c-7ff9-c06e-81d6-b568fb2f9464@oracle.com>
 <315dfbdb-b27a-4e9c-067a-81718ef0645f@oracle.com>
 <OFE61C7987.C97DF629-ON00258519.004BEA69-00258519.005B3C41@notes.na.collabserv.com>
 <OF56E349E5.3746C443-ON00258527.005A4210-00258527.005CC3C4@notes.na.collabserv.com>
 <OFAA5282CA.C667B8FA-ON00258528.001143A6-00258528.0011D91A@notes.na.collabserv.com>
 <OF5EC3FD65.03E16FA0-ON00258528.002A5E98-00258528.002CC5FB@notes.na.collabserv.com>
 <de408110-7b0d-d630-1783-5e48e034d1f7@oracle.com>
 <DB7PR03MB439343CCC0E3DB80F5976F89FFFC0@DB7PR03MB4393.eurprd03.prod.outlook.com>
 <CAKysZ8yw=7kbG+THEKEi3DY3RoeS55tt=-zP0PfZXqeg4inz8w@mail.gmail.com>
 <242fe9b7-b9bc-03b9-0f5e-b0d01775fb64@oracle.com>
 <CAKysZ8z725FrYLcfrj5muD-AfAPda6nyksyXMVJrMM4475MzHw@mail.gmail.com>
 <CAKysZ8zX44bGfHqXUXX4GXTr04-oA-BPSU5gwmKU_x=t7-=Dow@mail.gmail.com>
 <655d84a0-648a-8217-99da-df87b16b7251@oracle.com>
Message-ID: <CAKysZ8xeEAi60JN6hq+yO0==cfPvwDrPmi=+45h8VeaVS82rKA@mail.gmail.com>

Hi Daniel/Alan,

Thanks for the review , I was not sure how JVM/JDK handles the signals
that's why I installed my own signal handler. As you both pointed out, I
removed the custom signal handler in NativeThread.

Please find the latest webrev(
http://cr.openjdk.java.net/~vtewari/8237858/webrev0.5/index.html) where i
have incorporated most of the review comments.

Thanks,
Vyom

On Tue, Jun 23, 2020 at 5:47 PM Daniel Fuchs <daniel.fuchs at oracle.com>
wrote:

> Hi Vyom,
>
> Just to let you know that the new SocketAcceptInterruptTest test
> seems to have some stability issues. Patrick imported your test
> and ran it on our test system.
>
> We got one crash (SIGSEV) on macOS with the first @run that uses
> the old impl, and a timeout with the second @run that uses the new
> impl.
>
> I see that your test installs a signal handler that calls
> pthread_exit((void *)0); Is that really necessary?
> I am suspecting that this might be at the root cause of the crash.
>
>  From the test output:
>
> run main/othervm/native -Djdk.net.usePlainSocketImpl=true
> SocketAcceptInterruptTest
> ----------System.out:(20/1144)----------
> Sending SIGPIPE to ServerSocket thread.
> Sending close Signal to server thread...
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x000000010399ac75, pid=30406, tid=12803
> #
> # JRE version: Java(TM) SE Runtime Environment (16.0) (build
> 16-internal+0-2020-06-22-1056440.patrick.concannon.openJDK)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM
> (16-internal+0-2020-06-22-1056440.patrick.concannon.openJDK, mixed mode,
> sharing, tiered, compressed oops, g1 gc, bsd-amd64)
> # Problematic frame:
> # V  [libjvm.dylib+0x39ac75]
> _ZNK5frame28sender_for_interpreter_frameEP11RegisterMap+0x15
> #
>
> and in the hs_err file:
>
> ---------------  T H R E A D  ---------------
>
> Current thread (0x00007fe72b523270):  GCTaskThread "GC Thread#0" [stack:
> 0x0000700006bc8000,0x0000700006cc8000] [id=12803]
>
> Stack: [0x0000700006bc8000,0x0000700006cc8000],  sp=0x0000700006cc6a60,
> free space=1018k
> Native frames: (J=compiled Java code, A=aot compiled Java code,
> j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.dylib+0x39ac75]
> _ZNK5frame28sender_for_interpreter_frameEP11RegisterMap+0x15
> V  [libjvm.dylib+0x39a99d]  _ZNK5frame6senderEP11RegisterMap+0x4d
> V  [libjvm.dylib+0x997f4e]
> _ZN10JavaThread11nmethods_doEP15CodeBlobClosure+0x9e
> V  [libjvm.dylib+0x99973c]
> _ZN7Threads28possibly_parallel_threads_doEbP13ThreadClosure+0x8c
> V  [libjvm.dylib+0x8b5c59]  _ZN21ParallelSPCleanupTask4workEj+0x29
> V  [libjvm.dylib+0xa3cc1d]  _ZN10GangWorker4loopEv+0x4d
> V  [libjvm.dylib+0x992ad1]  _ZN6Thread8call_runEv+0x71
> V  [libjvm.dylib+0x825177]  _ZL19thread_native_entryP6Thread+0x197
> C  [libsystem_pthread.dylib+0x3661]  _pthread_body+0x154
> C  [libsystem_pthread.dylib+0x350d]  _pthread_body+0x0
> C  [libsystem_pthread.dylib+0x2bf9]  thread_start+0xd
>
>
> siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr:
> 0x0000700007dfa720
>
> =======================================================================
>
> For the second @run - the test failed in timeout:
>
> run main/othervm/native SocketAcceptInterruptTest
> ----------System.out:(3/107)----------
> Sending SIGPIPE to ServerSocket thread.
> Sending close Signal to server thread...
> Timeout refired 480 times
>
> best regards,
>
> -- daniel
>
> On 18/06/2020 09:02, Vyom Tiwari wrote:
> > Hi,
> > Please find the latest
> > webrev(http://cr.openjdk.java.net/~vtewari/8237858/webrev0.4/index.html)
>
> > where i fix the build issue as well.
> >
> > Thanks,
> > Vyom
> >
>
>

-- 
Thanks,
Vyom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200624/f9f5179f/attachment.htm>

From Alan.Bateman at oracle.com  Wed Jun 24 06:18:45 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 24 Jun 2020 07:18:45 +0100
Subject: RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR
 incorrectly
In-Reply-To: <CAKysZ8xeEAi60JN6hq+yO0==cfPvwDrPmi=+45h8VeaVS82rKA@mail.gmail.com>
References: <eb820990-538f-6462-83f1-00db9c5addb9@oracle.com>
 <315dfbdb-b27a-4e9c-067a-81718ef0645f@oracle.com>
 <OFE61C7987.C97DF629-ON00258519.004BEA69-00258519.005B3C41@notes.na.collabserv.com>
 <OF56E349E5.3746C443-ON00258527.005A4210-00258527.005CC3C4@notes.na.collabserv.com>
 <OFAA5282CA.C667B8FA-ON00258528.001143A6-00258528.0011D91A@notes.na.collabserv.com>
 <OF5EC3FD65.03E16FA0-ON00258528.002A5E98-00258528.002CC5FB@notes.na.collabserv.com>
 <de408110-7b0d-d630-1783-5e48e034d1f7@oracle.com>
 <DB7PR03MB439343CCC0E3DB80F5976F89FFFC0@DB7PR03MB4393.eurprd03.prod.outlook.com>
 <CAKysZ8yw=7kbG+THEKEi3DY3RoeS55tt=-zP0PfZXqeg4inz8w@mail.gmail.com>
 <242fe9b7-b9bc-03b9-0f5e-b0d01775fb64@oracle.com>
 <CAKysZ8z725FrYLcfrj5muD-AfAPda6nyksyXMVJrMM4475MzHw@mail.gmail.com>
 <CAKysZ8zX44bGfHqXUXX4GXTr04-oA-BPSU5gwmKU_x=t7-=Dow@mail.gmail.com>
 <655d84a0-648a-8217-99da-df87b16b7251@oracle.com>
 <CAKysZ8xeEAi60JN6hq+yO0==cfPvwDrPmi=+45h8VeaVS82rKA@mail.gmail.com>
Message-ID: <46cc1d6e-6e8a-388b-72a7-cdea3dd676e8@oracle.com>

On 24/06/2020 05:53, Vyom Tiwari wrote:
> Hi Daniel/Alan,
>
> Thanks for the review , I was not sure how JVM/JDK handles the signals 
> that's why I installed my own signal handler. As you both pointed out, 
> I removed the custom signal handler in NativeThread.
>
> Please find the latest 
> webrev(http://cr.openjdk.java.net/~vtewari/8237858/webrev0.5/index.html) 
> where i have incorporated most of the review comments.
>
This iteration is still missing the formatting fixes to linux_close.c 
and bsd_close.c. Also NativeSignal still has hardcoded values for the 
signals. NativeThread.close signals, it doesn't close, so needs to be 
renamed. I've skimmed through the updated SocketXXXInterruptTests but I 
don't think they are ready for review yet, e.g. I would expect 
SocketAcceptInterruptTest to test both timed and untimed accept. Also I 
would expect the test would establish a connection so that it verifies 
that a connection can be accept while until a barrage of signals. Also 
the cleanup is not clear, it looks like it seems the Server thread 
behind (this may be masked by running it with /othervm).

-Alan

From vyommani at gmail.com  Wed Jun 24 06:45:48 2020
From: vyommani at gmail.com (Vyom Tiwari)
Date: Wed, 24 Jun 2020 12:15:48 +0530
Subject: RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR
 incorrectly
In-Reply-To: <46cc1d6e-6e8a-388b-72a7-cdea3dd676e8@oracle.com>
References: <eb820990-538f-6462-83f1-00db9c5addb9@oracle.com>
 <315dfbdb-b27a-4e9c-067a-81718ef0645f@oracle.com>
 <OFE61C7987.C97DF629-ON00258519.004BEA69-00258519.005B3C41@notes.na.collabserv.com>
 <OF56E349E5.3746C443-ON00258527.005A4210-00258527.005CC3C4@notes.na.collabserv.com>
 <OFAA5282CA.C667B8FA-ON00258528.001143A6-00258528.0011D91A@notes.na.collabserv.com>
 <OF5EC3FD65.03E16FA0-ON00258528.002A5E98-00258528.002CC5FB@notes.na.collabserv.com>
 <de408110-7b0d-d630-1783-5e48e034d1f7@oracle.com>
 <DB7PR03MB439343CCC0E3DB80F5976F89FFFC0@DB7PR03MB4393.eurprd03.prod.outlook.com>
 <CAKysZ8yw=7kbG+THEKEi3DY3RoeS55tt=-zP0PfZXqeg4inz8w@mail.gmail.com>
 <242fe9b7-b9bc-03b9-0f5e-b0d01775fb64@oracle.com>
 <CAKysZ8z725FrYLcfrj5muD-AfAPda6nyksyXMVJrMM4475MzHw@mail.gmail.com>
 <CAKysZ8zX44bGfHqXUXX4GXTr04-oA-BPSU5gwmKU_x=t7-=Dow@mail.gmail.com>
 <655d84a0-648a-8217-99da-df87b16b7251@oracle.com>
 <CAKysZ8xeEAi60JN6hq+yO0==cfPvwDrPmi=+45h8VeaVS82rKA@mail.gmail.com>
 <46cc1d6e-6e8a-388b-72a7-cdea3dd676e8@oracle.com>
Message-ID: <CAKysZ8yBRzUm1K5oXkpdE4B5DTx1TCA5MKvSC41Jv=UoVDHV4A@mail.gmail.com>

Hi Alan,
thanks for the review, i think there is some problem with webrev, in my
local repo linux_close.c, bsd_close.c both are properly formatted.

I will do the suggested changes in the tests and  will send the updated
webrev soon.

Thanks,
Vyom

On Wed, Jun 24, 2020 at 11:49 AM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 24/06/2020 05:53, Vyom Tiwari wrote:
> > Hi Daniel/Alan,
> >
> > Thanks for the review , I was not sure how JVM/JDK handles the signals
> > that's why I installed my own signal handler. As you both pointed out,
> > I removed the custom signal handler in NativeThread.
> >
> > Please find the latest
> > webrev(http://cr.openjdk.java.net/~vtewari/8237858/webrev0.5/index.html)
>
> > where i have incorporated most of the review comments.
> >
> This iteration is still missing the formatting fixes to linux_close.c
> and bsd_close.c. Also NativeSignal still has hardcoded values for the
> signals. NativeThread.close signals, it doesn't close, so needs to be
> renamed. I've skimmed through the updated SocketXXXInterruptTests but I
> don't think they are ready for review yet, e.g. I would expect
> SocketAcceptInterruptTest to test both timed and untimed accept. Also I
> would expect the test would establish a connection so that it verifies
> that a connection can be accept while until a barrage of signals. Also
> the cleanup is not clear, it looks like it seems the Server thread
> behind (this may be masked by running it with /othervm).
>
> -Alan
>


-- 
Thanks,
Vyom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200624/8a6aba09/attachment.htm>

From daniel.fuchs at oracle.com  Wed Jun 24 10:40:57 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 24 Jun 2020 11:40:57 +0100
Subject: RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR
 incorrectly
In-Reply-To: <CAKysZ8xeEAi60JN6hq+yO0==cfPvwDrPmi=+45h8VeaVS82rKA@mail.gmail.com>
References: <eb820990-538f-6462-83f1-00db9c5addb9@oracle.com>
 <315dfbdb-b27a-4e9c-067a-81718ef0645f@oracle.com>
 <OFE61C7987.C97DF629-ON00258519.004BEA69-00258519.005B3C41@notes.na.collabserv.com>
 <OF56E349E5.3746C443-ON00258527.005A4210-00258527.005CC3C4@notes.na.collabserv.com>
 <OFAA5282CA.C667B8FA-ON00258528.001143A6-00258528.0011D91A@notes.na.collabserv.com>
 <OF5EC3FD65.03E16FA0-ON00258528.002A5E98-00258528.002CC5FB@notes.na.collabserv.com>
 <de408110-7b0d-d630-1783-5e48e034d1f7@oracle.com>
 <DB7PR03MB439343CCC0E3DB80F5976F89FFFC0@DB7PR03MB4393.eurprd03.prod.outlook.com>
 <CAKysZ8yw=7kbG+THEKEi3DY3RoeS55tt=-zP0PfZXqeg4inz8w@mail.gmail.com>
 <242fe9b7-b9bc-03b9-0f5e-b0d01775fb64@oracle.com>
 <CAKysZ8z725FrYLcfrj5muD-AfAPda6nyksyXMVJrMM4475MzHw@mail.gmail.com>
 <CAKysZ8zX44bGfHqXUXX4GXTr04-oA-BPSU5gwmKU_x=t7-=Dow@mail.gmail.com>
 <655d84a0-648a-8217-99da-df87b16b7251@oracle.com>
 <CAKysZ8xeEAi60JN6hq+yO0==cfPvwDrPmi=+45h8VeaVS82rKA@mail.gmail.com>
Message-ID: <540969d4-62a3-a74f-273d-95354b956ca1@oracle.com>

Hi Vyom,

What is the purpose of calling NativeThread.close?
Is that just to clean up and make the server thread terminate?
If so there should be better ways to do that.

When does the test succeed?

Looking at SocketAcceptInterruptTest it looks like the test
will succeed if it manages to send the signal - and that's it.
Is it really a measure of success?

Also it seems like better synchronization primitive could
be used (for instance CountDownLatch) than relying on arbitrary
timeout. In particular `isSet` could be a CountDownLatch.

best regards,

-- daniel

On 24/06/2020 05:53, Vyom Tiwari wrote:
> Hi Daniel/Alan,
> 
> Thanks for the review , I was not sure how JVM/JDK handles the signals 
> that's why I installed my own signal handler. As you both pointed out, I 
> removed the custom signal handler in NativeThread.
> 
> Please find the latest 
> webrev(http://cr.openjdk.java.net/~vtewari/8237858/webrev0.5/index.html) 
> where i have incorporated most of the review comments.
> 
> Thanks,
> Vyom

From vyommani at gmail.com  Wed Jun 24 11:14:01 2020
From: vyommani at gmail.com (Vyom Tiwari)
Date: Wed, 24 Jun 2020 16:44:01 +0530
Subject: RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR
 incorrectly
In-Reply-To: <540969d4-62a3-a74f-273d-95354b956ca1@oracle.com>
References: <eb820990-538f-6462-83f1-00db9c5addb9@oracle.com>
 <315dfbdb-b27a-4e9c-067a-81718ef0645f@oracle.com>
 <OFE61C7987.C97DF629-ON00258519.004BEA69-00258519.005B3C41@notes.na.collabserv.com>
 <OF56E349E5.3746C443-ON00258527.005A4210-00258527.005CC3C4@notes.na.collabserv.com>
 <OFAA5282CA.C667B8FA-ON00258528.001143A6-00258528.0011D91A@notes.na.collabserv.com>
 <OF5EC3FD65.03E16FA0-ON00258528.002A5E98-00258528.002CC5FB@notes.na.collabserv.com>
 <de408110-7b0d-d630-1783-5e48e034d1f7@oracle.com>
 <DB7PR03MB439343CCC0E3DB80F5976F89FFFC0@DB7PR03MB4393.eurprd03.prod.outlook.com>
 <CAKysZ8yw=7kbG+THEKEi3DY3RoeS55tt=-zP0PfZXqeg4inz8w@mail.gmail.com>
 <242fe9b7-b9bc-03b9-0f5e-b0d01775fb64@oracle.com>
 <CAKysZ8z725FrYLcfrj5muD-AfAPda6nyksyXMVJrMM4475MzHw@mail.gmail.com>
 <CAKysZ8zX44bGfHqXUXX4GXTr04-oA-BPSU5gwmKU_x=t7-=Dow@mail.gmail.com>
 <655d84a0-648a-8217-99da-df87b16b7251@oracle.com>
 <CAKysZ8xeEAi60JN6hq+yO0==cfPvwDrPmi=+45h8VeaVS82rKA@mail.gmail.com>
 <540969d4-62a3-a74f-273d-95354b956ca1@oracle.com>
Message-ID: <CAKysZ8xODBi_hdpObpqrnFcDYGADfBR2OqXUGnNPp-RuuVxJmA@mail.gmail.com>

Hi Daniel,

Thanks for review, please find my answers below.

1-> What is the purpose of calling NativeThread.close?
To close the thread which is waiting in SocketAccept,  I wrote a test in
such a way that the server thread will wait infinitely in socket accept and
there will not be any incoming socket so accept will never return. As Alan
suggested we should have an incoming connection to test if accept works
after SIGPIPE.  I will change the test as per his suggestion and I think we
don't need the "close" method.

2-> When does the test succeed?
test succeeds if no SocketTimeoutException is thrown when you send a
SIGPIPE to the server thread. If you run the same test without a fix, the
test will throw a SocketTimeoutException.
#####################################
Sending SIGPIPE to ServerSocket thread.
Exception in thread "Thread-0" java.lang.RuntimeException:
java.net.SocketTimeoutException: Accept timed out
at SocketAcceptTest$Server.run(SocketAcceptTest.java:89)
at java.base/java.lang.Thread.run(Thread.java:832)
Caused by: java.net.SocketTimeoutException: Accept timed out
at java.base/java.net.PlainSocketImpl.socketAccept(Native Method)
############################################

3-> Looking at SocketAcceptInterruptTest it looks like the test
will succeed if it manages to send the signal - and that's it.
Is it really a measure of success?
No, I explained in  question 2.

Use of  CountdownLatch  will be good, let me rewrite the test I will try to
use if it is possible.

Thanks,
Vyom


On Wed, Jun 24, 2020 at 4:11 PM Daniel Fuchs <daniel.fuchs at oracle.com>
wrote:

> Hi Vyom,
>
> What is the purpose of calling NativeThread.close?
> Is that just to clean up and make the server thread terminate?
> If so there should be better ways to do that.
>
> When does the test succeed?
>
> Looking at SocketAcceptInterruptTest it looks like the test
> will succeed if it manages to send the signal - and that's it.
> Is it really a measure of success?
>
> Also it seems like better synchronization primitive could
> be used (for instance CountDownLatch) than relying on arbitrary
> timeout. In particular `isSet` could be a CountDownLatch.
>
> best regards,
>
> -- daniel
>
> On 24/06/2020 05:53, Vyom Tiwari wrote:
> > Hi Daniel/Alan,
> >
> > Thanks for the review , I was not sure how JVM/JDK handles the signals
> > that's why I installed my own signal handler. As you both pointed out, I
> > removed the custom signal handler in NativeThread.
> >
> > Please find the latest
> > webrev(http://cr.openjdk.java.net/~vtewari/8237858/webrev0.5/index.html)
>
> > where i have incorporated most of the review comments.
> >
> > Thanks,
> > Vyom
>


-- 
Thanks,
Vyom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200624/c4ff1cd7/attachment.htm>

From daniel.fuchs at oracle.com  Wed Jun 24 11:50:34 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 24 Jun 2020 12:50:34 +0100
Subject: RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR
 incorrectly
In-Reply-To: <CAKysZ8xODBi_hdpObpqrnFcDYGADfBR2OqXUGnNPp-RuuVxJmA@mail.gmail.com>
References: <eb820990-538f-6462-83f1-00db9c5addb9@oracle.com>
 <OF56E349E5.3746C443-ON00258527.005A4210-00258527.005CC3C4@notes.na.collabserv.com>
 <OFAA5282CA.C667B8FA-ON00258528.001143A6-00258528.0011D91A@notes.na.collabserv.com>
 <OF5EC3FD65.03E16FA0-ON00258528.002A5E98-00258528.002CC5FB@notes.na.collabserv.com>
 <de408110-7b0d-d630-1783-5e48e034d1f7@oracle.com>
 <DB7PR03MB439343CCC0E3DB80F5976F89FFFC0@DB7PR03MB4393.eurprd03.prod.outlook.com>
 <CAKysZ8yw=7kbG+THEKEi3DY3RoeS55tt=-zP0PfZXqeg4inz8w@mail.gmail.com>
 <242fe9b7-b9bc-03b9-0f5e-b0d01775fb64@oracle.com>
 <CAKysZ8z725FrYLcfrj5muD-AfAPda6nyksyXMVJrMM4475MzHw@mail.gmail.com>
 <CAKysZ8zX44bGfHqXUXX4GXTr04-oA-BPSU5gwmKU_x=t7-=Dow@mail.gmail.com>
 <655d84a0-648a-8217-99da-df87b16b7251@oracle.com>
 <CAKysZ8xeEAi60JN6hq+yO0==cfPvwDrPmi=+45h8VeaVS82rKA@mail.gmail.com>
 <540969d4-62a3-a74f-273d-95354b956ca1@oracle.com>
 <CAKysZ8xODBi_hdpObpqrnFcDYGADfBR2OqXUGnNPp-RuuVxJmA@mail.gmail.com>
Message-ID: <f89ad3f8-8bfa-87c4-69cc-3b0d98a0dd1d@oracle.com>

On 24/06/2020 12:14, Vyom Tiwari wrote:
> 3-> Looking at SocketAcceptInterruptTest it looks like the test
> will succeed if it manages to send the signal - and that's it.
> Is it really a measure of success?
> No, I explained in? question 2.
> 

So basically you rely on the test infrastructure having
registered an UncaughtExceptionHandler to catch the exception
thrown by your server thread.

I would prederably not rely on this, and instead check whether
the exception has been thrown by the server thread from
the main thread.

best regards,

-- daniel

From vyommani at gmail.com  Wed Jun 24 12:02:32 2020
From: vyommani at gmail.com (Vyom Tiwari)
Date: Wed, 24 Jun 2020 17:32:32 +0530
Subject: RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR
 incorrectly
In-Reply-To: <f89ad3f8-8bfa-87c4-69cc-3b0d98a0dd1d@oracle.com>
References: <eb820990-538f-6462-83f1-00db9c5addb9@oracle.com>
 <OF56E349E5.3746C443-ON00258527.005A4210-00258527.005CC3C4@notes.na.collabserv.com>
 <OFAA5282CA.C667B8FA-ON00258528.001143A6-00258528.0011D91A@notes.na.collabserv.com>
 <OF5EC3FD65.03E16FA0-ON00258528.002A5E98-00258528.002CC5FB@notes.na.collabserv.com>
 <de408110-7b0d-d630-1783-5e48e034d1f7@oracle.com>
 <DB7PR03MB439343CCC0E3DB80F5976F89FFFC0@DB7PR03MB4393.eurprd03.prod.outlook.com>
 <CAKysZ8yw=7kbG+THEKEi3DY3RoeS55tt=-zP0PfZXqeg4inz8w@mail.gmail.com>
 <242fe9b7-b9bc-03b9-0f5e-b0d01775fb64@oracle.com>
 <CAKysZ8z725FrYLcfrj5muD-AfAPda6nyksyXMVJrMM4475MzHw@mail.gmail.com>
 <CAKysZ8zX44bGfHqXUXX4GXTr04-oA-BPSU5gwmKU_x=t7-=Dow@mail.gmail.com>
 <655d84a0-648a-8217-99da-df87b16b7251@oracle.com>
 <CAKysZ8xeEAi60JN6hq+yO0==cfPvwDrPmi=+45h8VeaVS82rKA@mail.gmail.com>
 <540969d4-62a3-a74f-273d-95354b956ca1@oracle.com>
 <CAKysZ8xODBi_hdpObpqrnFcDYGADfBR2OqXUGnNPp-RuuVxJmA@mail.gmail.com>
 <f89ad3f8-8bfa-87c4-69cc-3b0d98a0dd1d@oracle.com>
Message-ID: <CAKysZ8xSi8PR0ZxVt4-uM6UZngCqStRJkUmSr97ZUd1BHBDvhw@mail.gmail.com>

let me refactor the test, i will try to incorporate your suggestion.
Vyom


On Wed, Jun 24, 2020 at 5:21 PM Daniel Fuchs <daniel.fuchs at oracle.com>
wrote:

> On 24/06/2020 12:14, Vyom Tiwari wrote:
> > 3-> Looking at SocketAcceptInterruptTest it looks like the test
> > will succeed if it manages to send the signal - and that's it.
> > Is it really a measure of success?
> > No, I explained in  question 2.
> >
>
> So basically you rely on the test infrastructure having
> registered an UncaughtExceptionHandler to catch the exception
> thrown by your server thread.
>
> I would prederably not rely on this, and instead check whether
> the exception has been thrown by the server thread from
> the main thread.
>
> best regards,
>
> -- daniel
>


-- 
Thanks,
Vyom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200624/033b857b/attachment.htm>

From sgehwolf at redhat.com  Thu Jun 25 13:39:38 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 25 Jun 2020 15:39:38 +0200
Subject: [8u] RFR(m): 8194298: Add support for per Socket configuration of
 TCP keepalive
Message-ID: <d3692fd45bce49b5ad51ce1078ffbb345d495d03.camel@redhat.com>

Hi,

Please review this OpenJDK 8u backport of JDK-8194298 which adds socket
configuration options for TCP keepalive. It's one of the Oracle JDK
parity patches.

As with the OpenJDK 11u change, this includes Linux and Mac only
changes. This backport is pretty much a rewrite as the JDK 11u codebase
is rather different in this area.

Bug:    https://bugs.openjdk.java.net/browse/JDK-8194298
8u CSR: https://bugs.openjdk.java.net/browse/JDK-8236187
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8194298/jdk8/04/webrev/

Testing:
 * Build/test on Linux x86_64 and Mac OS x (thanks to Simon Tooke).
   Build on Windows x86_64 (also thanks to Simon Tooke)
 * tier1 tests,?test/java/nio test/java/net/ test/jdk/net/ on Linux
   x86_64. No regressions noted.

Thoughts?

Thanks,
Severin



From ecki at zusammenkunft.net  Thu Jun 25 23:55:04 2020
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Thu, 25 Jun 2020 23:55:04 +0000
Subject: [8u] RFR(m): 8194298: Add support for per Socket configuration of
 TCP keepalive
In-Reply-To: <d3692fd45bce49b5ad51ce1078ffbb345d495d03.camel@redhat.com>
References: <d3692fd45bce49b5ad51ce1078ffbb345d495d03.camel@redhat.com>
Message-ID: <AM6PR03MB4389EFA46B30CEA78F11B6D8FF920@AM6PR03MB4389.eurprd03.prod.outlook.com>

Hello,

This would be a great addition. I do not understand why it does not support the options available for Windows. Especially given the fact that it actually implements 6 native methods to print "Unsupported".

But I guess that's less a question to the backport and more to the general implementation.

Gruss
Bernd


--
http://bernd.eckenfels.net
________________________________
Von: net-dev <net-dev-retn at openjdk.java.net> im Auftrag von Severin Gehwolf <sgehwolf at redhat.com>
Gesendet: Thursday, June 25, 2020 3:39:38 PM
An: jdk8u-dev <jdk8u-dev at openjdk.java.net>
Cc: net-dev <net-dev at openjdk.java.net>
Betreff: [8u] RFR(m): 8194298: Add support for per Socket configuration of TCP keepalive

Hi,

Please review this OpenJDK 8u backport of JDK-8194298 which adds socket
configuration options for TCP keepalive. It's one of the Oracle JDK
parity patches.

As with the OpenJDK 11u change, this includes Linux and Mac only
changes. This backport is pretty much a rewrite as the JDK 11u codebase
is rather different in this area.

Bug:    https://bugs.openjdk.java.net/browse/JDK-8194298
8u CSR: https://bugs.openjdk.java.net/browse/JDK-8236187
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8194298/jdk8/04/webrev/

Testing:
 * Build/test on Linux x86_64 and Mac OS x (thanks to Simon Tooke).
   Build on Windows x86_64 (also thanks to Simon Tooke)
 * tier1 tests, test/java/nio test/java/net/ test/jdk/net/ on Linux
   x86_64. No regressions noted.

Thoughts?

Thanks,
Severin


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200625/c8386baf/attachment.htm>

From vyommani at gmail.com  Fri Jun 26 04:17:23 2020
From: vyommani at gmail.com (Vyom Tiwari)
Date: Fri, 26 Jun 2020 09:47:23 +0530
Subject: RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR
 incorrectly
In-Reply-To: <CAKysZ8xSi8PR0ZxVt4-uM6UZngCqStRJkUmSr97ZUd1BHBDvhw@mail.gmail.com>
References: <eb820990-538f-6462-83f1-00db9c5addb9@oracle.com>
 <OF56E349E5.3746C443-ON00258527.005A4210-00258527.005CC3C4@notes.na.collabserv.com>
 <OFAA5282CA.C667B8FA-ON00258528.001143A6-00258528.0011D91A@notes.na.collabserv.com>
 <OF5EC3FD65.03E16FA0-ON00258528.002A5E98-00258528.002CC5FB@notes.na.collabserv.com>
 <de408110-7b0d-d630-1783-5e48e034d1f7@oracle.com>
 <DB7PR03MB439343CCC0E3DB80F5976F89FFFC0@DB7PR03MB4393.eurprd03.prod.outlook.com>
 <CAKysZ8yw=7kbG+THEKEi3DY3RoeS55tt=-zP0PfZXqeg4inz8w@mail.gmail.com>
 <242fe9b7-b9bc-03b9-0f5e-b0d01775fb64@oracle.com>
 <CAKysZ8z725FrYLcfrj5muD-AfAPda6nyksyXMVJrMM4475MzHw@mail.gmail.com>
 <CAKysZ8zX44bGfHqXUXX4GXTr04-oA-BPSU5gwmKU_x=t7-=Dow@mail.gmail.com>
 <655d84a0-648a-8217-99da-df87b16b7251@oracle.com>
 <CAKysZ8xeEAi60JN6hq+yO0==cfPvwDrPmi=+45h8VeaVS82rKA@mail.gmail.com>
 <540969d4-62a3-a74f-273d-95354b956ca1@oracle.com>
 <CAKysZ8xODBi_hdpObpqrnFcDYGADfBR2OqXUGnNPp-RuuVxJmA@mail.gmail.com>
 <f89ad3f8-8bfa-87c4-69cc-3b0d98a0dd1d@oracle.com>
 <CAKysZ8xSi8PR0ZxVt4-uM6UZngCqStRJkUmSr97ZUd1BHBDvhw@mail.gmail.com>
Message-ID: <CAKysZ8wiRZErb6m9sR3+JUAvktMC7P8F_uJoaOnfwx+WSA-2TQ@mail.gmail.com>

Hi Daniel/Alan,
Please find the latest webrev(
http://cr.openjdk.java.net/~vtewari/8237858/webrev0.6/index.html).
Thanks,
Vyom

On Wed, Jun 24, 2020 at 5:32 PM Vyom Tiwari <vyommani at gmail.com> wrote:

> let me refactor the test, i will try to incorporate your suggestion.
> Vyom
>
>
> On Wed, Jun 24, 2020 at 5:21 PM Daniel Fuchs <daniel.fuchs at oracle.com>
> wrote:
>
>> On 24/06/2020 12:14, Vyom Tiwari wrote:
>> > 3-> Looking at SocketAcceptInterruptTest it looks like the test
>> > will succeed if it manages to send the signal - and that's it.
>> > Is it really a measure of success?
>> > No, I explained in  question 2.
>> >
>>
>> So basically you rely on the test infrastructure having
>> registered an UncaughtExceptionHandler to catch the exception
>> thrown by your server thread.
>>
>> I would prederably not rely on this, and instead check whether
>> the exception has been thrown by the server thread from
>> the main thread.
>>
>> best regards,
>>
>> -- daniel
>>
>
>
> --
> Thanks,
> Vyom
>


-- 
Thanks,
Vyom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200626/ae2fed5b/attachment-0001.htm>

From vyommani at gmail.com  Fri Jun 26 07:11:39 2020
From: vyommani at gmail.com (Vyom Tiwari)
Date: Fri, 26 Jun 2020 12:41:39 +0530
Subject: [8u] RFR(m): 8194298: Add support for per Socket configuration of
 TCP keepalive
In-Reply-To: <AM6PR03MB4389EFA46B30CEA78F11B6D8FF920@AM6PR03MB4389.eurprd03.prod.outlook.com>
References: <d3692fd45bce49b5ad51ce1078ffbb345d495d03.camel@redhat.com>
 <AM6PR03MB4389EFA46B30CEA78F11B6D8FF920@AM6PR03MB4389.eurprd03.prod.outlook.com>
Message-ID: <CAKysZ8yC71tjT2V6rc=-n6H2KGDMw-=FdtyHKgDmfihu=m2Tmg@mail.gmail.com>

Hi Bernd,

When we added these socket options to JDK, that time these options were not
available on Windows.

Thanks,
Vyom


On Fri, Jun 26, 2020 at 7:12 AM Bernd Eckenfels <ecki at zusammenkunft.net>
wrote:

> Hello,
>
> This would be a great addition. I do not understand why it does not
> support the options available for Windows. Especially given the fact that
> it actually implements 6 native methods to print "Unsupported".
>
> But I guess that's less a question to the backport and more to the general
> implementation.
>
> Gruss
> Bernd
>
>
> --
> http://bernd.eckenfels.net
> ------------------------------
> *Von:* net-dev <net-dev-retn at openjdk.java.net> im Auftrag von Severin
> Gehwolf <sgehwolf at redhat.com>
> *Gesendet:* Thursday, June 25, 2020 3:39:38 PM
> *An:* jdk8u-dev <jdk8u-dev at openjdk.java.net>
> *Cc:* net-dev <net-dev at openjdk.java.net>
> *Betreff:* [8u] RFR(m): 8194298: Add support for per Socket configuration
> of TCP keepalive
>
> Hi,
>
> Please review this OpenJDK 8u backport of JDK-8194298 which adds socket
> configuration options for TCP keepalive. It's one of the Oracle JDK
> parity patches.
>
> As with the OpenJDK 11u change, this includes Linux and Mac only
> changes. This backport is pretty much a rewrite as the JDK 11u codebase
> is rather different in this area.
>
> Bug:    https://bugs.openjdk.java.net/browse/JDK-8194298
> 8u CSR: https://bugs.openjdk.java.net/browse/JDK-8236187
> webrev:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8194298/jdk8/04/webrev/
>
> Testing:
>  * Build/test on Linux x86_64 and Mac OS x (thanks to Simon Tooke).
>    Build on Windows x86_64 (also thanks to Simon Tooke)
>  * tier1 tests, test/java/nio test/java/net/ test/jdk/net/ on Linux
>    x86_64. No regressions noted.
>
> Thoughts?
>
> Thanks,
> Severin
>
>
>

-- 
Thanks,
Vyom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200626/b99add32/attachment.htm>

From sgehwolf at redhat.com  Fri Jun 26 07:35:03 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 26 Jun 2020 09:35:03 +0200
Subject: [8u] RFR(m): 8194298: Add support for per Socket configuration
 of TCP keepalive
In-Reply-To: <AM6PR03MB4389EFA46B30CEA78F11B6D8FF920@AM6PR03MB4389.eurprd03.prod.outlook.com>
References: <d3692fd45bce49b5ad51ce1078ffbb345d495d03.camel@redhat.com>
 <AM6PR03MB4389EFA46B30CEA78F11B6D8FF920@AM6PR03MB4389.eurprd03.prod.outlook.com>
Message-ID: <21064bd9028fa4b1f0185c05df948217f857e4cc.camel@redhat.com>

Hi,

On Thu, 2020-06-25 at 23:55 +0000, Bernd Eckenfels wrote:
> This would be a great addition.

Thanks.

> I do not understand why it does not support the options available for
> Windows. Especially given the fact that it actually implements 6
> native methods to print "Unsupported".
> 
> But I guess that's less a question to the backport and more to the
> general implementation.

Yes, indeed. This should be brought up for discussion in JDK head first
and implemented there before we can consider a backport.

Thanks,
Severin



From vyommani at gmail.com  Fri Jun 26 10:25:06 2020
From: vyommani at gmail.com (Vyom Tiwari)
Date: Fri, 26 Jun 2020 15:55:06 +0530
Subject: [8u] RFR(m): 8194298: Add support for per Socket configuration of
 TCP keepalive
In-Reply-To: <21064bd9028fa4b1f0185c05df948217f857e4cc.camel@redhat.com>
References: <d3692fd45bce49b5ad51ce1078ffbb345d495d03.camel@redhat.com>
 <AM6PR03MB4389EFA46B30CEA78F11B6D8FF920@AM6PR03MB4389.eurprd03.prod.outlook.com>
 <21064bd9028fa4b1f0185c05df948217f857e4cc.camel@redhat.com>
Message-ID: <CAKysZ8ymRs+_rJ_RL_NWJjft3SKRXrA42Ln7H2q6obzad9M5Yg@mail.gmail.com>

Hi Severin,

Overall code changes looks ok to me, I build & tested at my local REL it
worked fine for me.

Below are few minor comments.

1-> Net.java
    1.1-> I think you don't need to explicitly convert value to integer and
then pass it. You can avoid the local int variable creation as follows.
      ExtendedOptionsImpl.setTcpKeepAliveIntvl(fd, (Integer)value);
   1.2-> In getSocketOption you don't need to explicitly cast it to Integer.
             return ExtendedOptionsImpl.getTcpKeepAliveIntvl(fd);
2-> PlainSocketImpl.java
    1.1 -> In setOption(SocketOption<T> name, T value) you can avoid the
local int variable.
3-> Any specific reason for two set of functions "setTcpKeepAliveTime0
and setTcpKeepAliveTime"
for all three socket options ?

Thanks,
Vyom

On Fri, Jun 26, 2020 at 1:08 PM Severin Gehwolf <sgehwolf at redhat.com> wrote:

> Hi,
>
> On Thu, 2020-06-25 at 23:55 +0000, Bernd Eckenfels wrote:
> > This would be a great addition.
>
> Thanks.
>
> > I do not understand why it does not support the options available for
> > Windows. Especially given the fact that it actually implements 6
> > native methods to print "Unsupported".
> >
> > But I guess that's less a question to the backport and more to the
> > general implementation.
>
> Yes, indeed. This should be brought up for discussion in JDK head first
> and implemented there before we can consider a backport.
>
> Thanks,
> Severin
>
>
>

-- 
Thanks,
Vyom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200626/ad77a402/attachment.htm>

From rahul.r.yadav at oracle.com  Fri Jun 26 11:57:11 2020
From: rahul.r.yadav at oracle.com (Rahul Yadav)
Date: Fri, 26 Jun 2020 12:57:11 +0100
Subject: RFR 8245245 : WebSocket can loose the URL encoding of URI query
 parameters
In-Reply-To: <e0122722-3c32-bdc2-2e99-a2fbfeb45f91@oracle.com>
References: <e0122722-3c32-bdc2-2e99-a2fbfeb45f91@oracle.com>
Message-ID: <09896607-ecb3-5062-02fe-26696bd4cc28@oracle.com>

Hello,

Request to have my fix reviewed for issue:

JDK-8247675 :? WebSocket can loose the URL encoding of URI query parameters

The fix updates the jdk.internal.net.http.websocket.OpeningHandshake
to ensure that the URL is not reencoded/decoded and loose the original
encoding

Issue:? https://bugs.openjdk.java.net/browse/JDK-8245245
webrev: http://cr.openjdk.java.net/~ryadav/webrev_8245245/index.html

- rahul

From rahul.r.yadav at oracle.com  Fri Jun 26 12:03:42 2020
From: rahul.r.yadav at oracle.com (Rahul Yadav)
Date: Fri, 26 Jun 2020 13:03:42 +0100
Subject: RFR 8245245 : WebSocket can loose the URL encoding of URI query
 parameters
In-Reply-To: <09896607-ecb3-5062-02fe-26696bd4cc28@oracle.com>
References: <09896607-ecb3-5062-02fe-26696bd4cc28@oracle.com>
Message-ID: <e97e5cc2-3595-0b5e-e1a6-0894c0edaba8@oracle.com>

Hello,

Request to have my fix reviewed for issue:

JDK-8245245? :? WebSocket can loose the URL encoding of URI query parameters

The fix updates the jdk.internal.net.http.websocket.OpeningHandshake
to ensure that the URL is not reencoded/decoded and loose the original
encoding

Issue:? https://bugs.openjdk.java.net/browse/JDK-8245245
webrev: http://cr.openjdk.java.net/~ryadav/webrev_8245245/index.html

- rahul

From pavel.rappo at oracle.com  Fri Jun 26 13:38:55 2020
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Fri, 26 Jun 2020 14:38:55 +0100
Subject: RFR 8245245 : WebSocket can loose the URL encoding of URI query
 parameters
In-Reply-To: <e97e5cc2-3595-0b5e-e1a6-0894c0edaba8@oracle.com>
References: <09896607-ecb3-5062-02fe-26696bd4cc28@oracle.com>
 <e97e5cc2-3595-0b5e-e1a6-0894c0edaba8@oracle.com>
Message-ID: <7F1D6F6A-D58A-4486-8D0B-01FE79A85BEA@oracle.com>

Rahul,

Won't that start retaining the URL fragment? From https://tools.ietf.org/html/rfc6455#section-3

   Fragment identifiers are meaningless in the context of WebSocket URIs
   and MUST NOT be used on these URIs.  As with any URI scheme, the
   character "#", when not indicating the start of a fragment, MUST be
   escaped as %23.

-Pavel

> On 26 Jun 2020, at 13:03, Rahul Yadav <rahul.r.yadav at oracle.com> wrote:
> 
> Hello,
> 
> Request to have my fix reviewed for issue:
> 
> JDK-8245245  :  WebSocket can loose the URL encoding of URI query parameters
> 
> The fix updates the jdk.internal.net.http.websocket.OpeningHandshake
> to ensure that the URL is not reencoded/decoded and loose the original
> encoding
> 
> Issue:  https://bugs.openjdk.java.net/browse/JDK-8245245
> webrev: http://cr.openjdk.java.net/~ryadav/webrev_8245245/index.html
> 
> - rahul


From chris.hegarty at oracle.com  Fri Jun 26 13:51:54 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 26 Jun 2020 14:51:54 +0100
Subject: RFR 8245245 : WebSocket can loose the URL encoding of URI query
 parameters
In-Reply-To: <7F1D6F6A-D58A-4486-8D0B-01FE79A85BEA@oracle.com>
References: <09896607-ecb3-5062-02fe-26696bd4cc28@oracle.com>
 <e97e5cc2-3595-0b5e-e1a6-0894c0edaba8@oracle.com>
 <7F1D6F6A-D58A-4486-8D0B-01FE79A85BEA@oracle.com>
Message-ID: <1AD7DAAA-2522-4501-B674-8025BE6DF0C8@oracle.com>



> On 26 Jun 2020, at 14:38, Pavel Rappo <pavel.rappo at oracle.com> wrote:
> 
> Rahul,
> 
> Won't that start retaining the URL fragment? From https://tools.ietf.org/html/rfc6455#section-3
> 
>   Fragment identifiers are meaningless in the context of WebSocket URIs
>   and MUST NOT be used on these URIs.  As with any URI scheme, the
>   character "#", when not indicating the start of a fragment, MUST be
>   escaped as %23.

I don?t think that a a fragment will be retained, see

   182        null); // No fragment

 , but maybe the concern is that a fragment character can be sneaked into other parts of the URI components, like the query?   If so, then the test could be expanded to ensure that this cannot happen.

-Chris.


From pavel.rappo at oracle.com  Fri Jun 26 14:10:32 2020
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Fri, 26 Jun 2020 15:10:32 +0100
Subject: RFR 8245245 : WebSocket can loose the URL encoding of URI query
 parameters
In-Reply-To: <1AD7DAAA-2522-4501-B674-8025BE6DF0C8@oracle.com>
References: <09896607-ecb3-5062-02fe-26696bd4cc28@oracle.com>
 <e97e5cc2-3595-0b5e-e1a6-0894c0edaba8@oracle.com>
 <7F1D6F6A-D58A-4486-8D0B-01FE79A85BEA@oracle.com>
 <1AD7DAAA-2522-4501-B674-8025BE6DF0C8@oracle.com>
Message-ID: <3CBBD959-6B3E-4EAC-A27B-13363C3C4165@oracle.com>

Chris,

Currently (i.e. before the proposed change has been applied) the fragment is NOT retained. This is because of the requirement of the mentioned RFC section. The proposed change seems to overlook that detail. Hence, my question.

-Pavel

> On 26 Jun 2020, at 14:51, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
> 
> 
>> On 26 Jun 2020, at 14:38, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>> 
>> Rahul,
>> 
>> Won't that start retaining the URL fragment? From https://tools.ietf.org/html/rfc6455#section-3
>> 
>>  Fragment identifiers are meaningless in the context of WebSocket URIs
>>  and MUST NOT be used on these URIs.  As with any URI scheme, the
>>  character "#", when not indicating the start of a fragment, MUST be
>>  escaped as %23.
> 
> I don?t think that a a fragment will be retained, see
> 
>   182        null); // No fragment
> 
> , but maybe the concern is that a fragment character can be sneaked into other parts of the URI components, like the query?   If so, then the test could be expanded to ensure that this cannot happen.
> 
> -Chris.
> 


From chris.hegarty at oracle.com  Fri Jun 26 14:18:32 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 26 Jun 2020 15:18:32 +0100
Subject: RFR 8245245 : WebSocket can loose the URL encoding of URI query
 parameters
In-Reply-To: <3CBBD959-6B3E-4EAC-A27B-13363C3C4165@oracle.com>
References: <09896607-ecb3-5062-02fe-26696bd4cc28@oracle.com>
 <e97e5cc2-3595-0b5e-e1a6-0894c0edaba8@oracle.com>
 <7F1D6F6A-D58A-4486-8D0B-01FE79A85BEA@oracle.com>
 <1AD7DAAA-2522-4501-B674-8025BE6DF0C8@oracle.com>
 <3CBBD959-6B3E-4EAC-A27B-13363C3C4165@oracle.com>
Message-ID: <3E786867-A179-47E7-8DEF-BC4E0B02A6F2@oracle.com>



> On 26 Jun 2020, at 15:10, Pavel Rappo <pavel.rappo at oracle.com> wrote:
> 
> Chris,
> 
> Currently (i.e. before the proposed change has been applied) the fragment is NOT retained. This is because of the requirement of the mentioned RFC section. The proposed change seems to overlook that detail. Hence, my question.

D?oh! Pavel is correct. I was reading the diffs the wrong way round !

-Chris.

From rahul.r.yadav at oracle.com  Fri Jun 26 15:42:34 2020
From: rahul.r.yadav at oracle.com (Rahul Yadav)
Date: Fri, 26 Jun 2020 16:42:34 +0100
Subject: RFR 8245245 : WebSocket can loose the URL encoding of URI query
 parameters
In-Reply-To: <7F1D6F6A-D58A-4486-8D0B-01FE79A85BEA@oracle.com>
References: <09896607-ecb3-5062-02fe-26696bd4cc28@oracle.com>
 <e97e5cc2-3595-0b5e-e1a6-0894c0edaba8@oracle.com>
 <7F1D6F6A-D58A-4486-8D0B-01FE79A85BEA@oracle.com>
Message-ID: <20b92bd9-08b9-700f-c2a0-61a8b45d451a@oracle.com>

Pavel,

That scenario is already handled, the existing behavior is if there is a 
fragment, an exception is thrown.
That hasn't changed.

  344     private static URI checkURI(URI uri) {
  345         String scheme = uri.getScheme();
  346         if (!("ws".equalsIgnoreCase(scheme) || "wss".equalsIgnoreCase(scheme)))
  347             throw illegal("invalid URI scheme: " + scheme);
  348         if (uri.getHost() == null)
  349             throw illegal("URI must contain a host: " + uri);
  350         if (uri.getFragment() != null)
  351             throw illegal("URI must not contain a fragment: " + uri);
  352         return uri;
  353     }
  354



- rahul


On 26/06/2020 14:38, Pavel Rappo wrote:
> Rahul,
>
> Won't that start retaining the URL fragment? From https://tools.ietf.org/html/rfc6455#section-3
>
>     Fragment identifiers are meaningless in the context of WebSocket URIs
>     and MUST NOT be used on these URIs.  As with any URI scheme, the
>     character "#", when not indicating the start of a fragment, MUST be
>     escaped as %23.
>
> -Pavel
>
>> On 26 Jun 2020, at 13:03, Rahul Yadav <rahul.r.yadav at oracle.com> wrote:
>>
>> Hello,
>>
>> Request to have my fix reviewed for issue:
>>
>> JDK-8245245  :  WebSocket can loose the URL encoding of URI query parameters
>>
>> The fix updates the jdk.internal.net.http.websocket.OpeningHandshake
>> to ensure that the URL is not reencoded/decoded and loose the original
>> encoding
>>
>> Issue:  https://bugs.openjdk.java.net/browse/JDK-8245245
>> webrev: http://cr.openjdk.java.net/~ryadav/webrev_8245245/index.html
>>
>> - rahul

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200626/68ea899e/attachment.htm>

From daniel.fuchs at oracle.com  Fri Jun 26 17:18:28 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 26 Jun 2020 18:18:28 +0100
Subject: RFR 8245245 : WebSocket can loose the URL encoding of URI query
 parameters
In-Reply-To: <20b92bd9-08b9-700f-c2a0-61a8b45d451a@oracle.com>
References: <09896607-ecb3-5062-02fe-26696bd4cc28@oracle.com>
 <e97e5cc2-3595-0b5e-e1a6-0894c0edaba8@oracle.com>
 <7F1D6F6A-D58A-4486-8D0B-01FE79A85BEA@oracle.com>
 <20b92bd9-08b9-700f-c2a0-61a8b45d451a@oracle.com>
Message-ID: <8306e693-c3c1-91ac-fcb2-fc15ec167d65@oracle.com>

I concur. Rahul has convinced me.
Rahul also pointed me to a test that verifies that the IAE is
thrown, so I believe that
http://cr.openjdk.java.net/~ryadav/webrev_8245245/index.html
is good.

best regards,

-- daniel

On 26/06/2020 16:42, Rahul Yadav wrote:
> Pavel,
> 
> That scenario is already handled, the existing behavior is if there is a 
> fragment, an exception is thrown.
> That hasn't changed.
> 
>   344     private static URI checkURI(URI uri) {
>   345         String scheme = uri.getScheme();
>   346         if (!("ws".equalsIgnoreCase(scheme) || "wss".equalsIgnoreCase(scheme)))
>   347             throw illegal("invalid URI scheme: " + scheme);
>   348         if (uri.getHost() == null)
>   349             throw illegal("URI must contain a host: " + uri);
>   350         if (uri.getFragment() != null)
>   351             throw illegal("URI must not contain a fragment: " + uri);
>   352         return uri;
>   353     }
>   354
> 
> 
> 
> - rahul

From pavel.rappo at oracle.com  Fri Jun 26 19:20:23 2020
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Fri, 26 Jun 2020 20:20:23 +0100
Subject: RFR 8245245 : WebSocket can loose the URL encoding of URI query
 parameters
In-Reply-To: <8306e693-c3c1-91ac-fcb2-fc15ec167d65@oracle.com>
References: <09896607-ecb3-5062-02fe-26696bd4cc28@oracle.com>
 <e97e5cc2-3595-0b5e-e1a6-0894c0edaba8@oracle.com>
 <7F1D6F6A-D58A-4486-8D0B-01FE79A85BEA@oracle.com>
 <20b92bd9-08b9-700f-c2a0-61a8b45d451a@oracle.com>
 <8306e693-c3c1-91ac-fcb2-fc15ec167d65@oracle.com>
Message-ID: <8267C403-6C2C-44B5-A66B-AA410BD7B3BE@oracle.com>

Looks good to me.

P.S. I think I began to forget the very code I wrote.

> On 26 Jun 2020, at 18:18, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> I concur. Rahul has convinced me.
> Rahul also pointed me to a test that verifies that the IAE is
> thrown, so I believe that
> http://cr.openjdk.java.net/~ryadav/webrev_8245245/index.html
> is good.
> 
> best regards,
> 
> -- daniel
> 
> On 26/06/2020 16:42, Rahul Yadav wrote:
>> Pavel,
>> That scenario is already handled, the existing behavior is if there is a fragment, an exception is thrown.
>> That hasn't changed.
>>  344     private static URI checkURI(URI uri) {
>>  345         String scheme = uri.getScheme();
>>  346         if (!("ws".equalsIgnoreCase(scheme) || "wss".equalsIgnoreCase(scheme)))
>>  347             throw illegal("invalid URI scheme: " + scheme);
>>  348         if (uri.getHost() == null)
>>  349             throw illegal("URI must contain a host: " + uri);
>>  350         if (uri.getFragment() != null)
>>  351             throw illegal("URI must not contain a fragment: " + uri);
>>  352         return uri;
>>  353     }
>>  354
>> - rahul


From Alan.Bateman at oracle.com  Sat Jun 27 06:16:09 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 27 Jun 2020 07:16:09 +0100
Subject: RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR
 incorrectly
In-Reply-To: <CAKysZ8wiRZErb6m9sR3+JUAvktMC7P8F_uJoaOnfwx+WSA-2TQ@mail.gmail.com>
References: <eb820990-538f-6462-83f1-00db9c5addb9@oracle.com>
 <OF5EC3FD65.03E16FA0-ON00258528.002A5E98-00258528.002CC5FB@notes.na.collabserv.com>
 <de408110-7b0d-d630-1783-5e48e034d1f7@oracle.com>
 <DB7PR03MB439343CCC0E3DB80F5976F89FFFC0@DB7PR03MB4393.eurprd03.prod.outlook.com>
 <CAKysZ8yw=7kbG+THEKEi3DY3RoeS55tt=-zP0PfZXqeg4inz8w@mail.gmail.com>
 <242fe9b7-b9bc-03b9-0f5e-b0d01775fb64@oracle.com>
 <CAKysZ8z725FrYLcfrj5muD-AfAPda6nyksyXMVJrMM4475MzHw@mail.gmail.com>
 <CAKysZ8zX44bGfHqXUXX4GXTr04-oA-BPSU5gwmKU_x=t7-=Dow@mail.gmail.com>
 <655d84a0-648a-8217-99da-df87b16b7251@oracle.com>
 <CAKysZ8xeEAi60JN6hq+yO0==cfPvwDrPmi=+45h8VeaVS82rKA@mail.gmail.com>
 <540969d4-62a3-a74f-273d-95354b956ca1@oracle.com>
 <CAKysZ8xODBi_hdpObpqrnFcDYGADfBR2OqXUGnNPp-RuuVxJmA@mail.gmail.com>
 <f89ad3f8-8bfa-87c4-69cc-3b0d98a0dd1d@oracle.com>
 <CAKysZ8xSi8PR0ZxVt4-uM6UZngCqStRJkUmSr97ZUd1BHBDvhw@mail.gmail.com>
 <CAKysZ8wiRZErb6m9sR3+JUAvktMC7P8F_uJoaOnfwx+WSA-2TQ@mail.gmail.com>
Message-ID: <aa1f3bc4-9f34-f663-c433-1e37de771ee5@oracle.com>

On 26/06/2020 05:17, Vyom Tiwari wrote:
> Hi Daniel/Alan,
> Please find the latest 
> webrev(http://cr.openjdk.java.net/~vtewari/8237858/webrev0.6/index.html).
>
I think we can do better than one signal after 200ms. Have you given any 
thought to have a thread that signals many times so that you have a 
better chance of tickling bugs?? One other comment at this time is that 
the value of SIGPIPE is still hardcoded - I think you'll need to add 
another native method to return its value.

BTW:? The formatting issues with linux_close.c and bsd_close.c are the 
same as the previous iterations. Did you track down that issue, I think 
you thought it was webrev or an issue with your patch queue.

-Alan.


From vyommani at gmail.com  Sat Jun 27 07:26:54 2020
From: vyommani at gmail.com (Vyom Tiwari)
Date: Sat, 27 Jun 2020 12:56:54 +0530
Subject: RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR
 incorrectly
In-Reply-To: <aa1f3bc4-9f34-f663-c433-1e37de771ee5@oracle.com>
References: <eb820990-538f-6462-83f1-00db9c5addb9@oracle.com>
 <OF5EC3FD65.03E16FA0-ON00258528.002A5E98-00258528.002CC5FB@notes.na.collabserv.com>
 <de408110-7b0d-d630-1783-5e48e034d1f7@oracle.com>
 <DB7PR03MB439343CCC0E3DB80F5976F89FFFC0@DB7PR03MB4393.eurprd03.prod.outlook.com>
 <CAKysZ8yw=7kbG+THEKEi3DY3RoeS55tt=-zP0PfZXqeg4inz8w@mail.gmail.com>
 <242fe9b7-b9bc-03b9-0f5e-b0d01775fb64@oracle.com>
 <CAKysZ8z725FrYLcfrj5muD-AfAPda6nyksyXMVJrMM4475MzHw@mail.gmail.com>
 <CAKysZ8zX44bGfHqXUXX4GXTr04-oA-BPSU5gwmKU_x=t7-=Dow@mail.gmail.com>
 <655d84a0-648a-8217-99da-df87b16b7251@oracle.com>
 <CAKysZ8xeEAi60JN6hq+yO0==cfPvwDrPmi=+45h8VeaVS82rKA@mail.gmail.com>
 <540969d4-62a3-a74f-273d-95354b956ca1@oracle.com>
 <CAKysZ8xODBi_hdpObpqrnFcDYGADfBR2OqXUGnNPp-RuuVxJmA@mail.gmail.com>
 <f89ad3f8-8bfa-87c4-69cc-3b0d98a0dd1d@oracle.com>
 <CAKysZ8xSi8PR0ZxVt4-uM6UZngCqStRJkUmSr97ZUd1BHBDvhw@mail.gmail.com>
 <CAKysZ8wiRZErb6m9sR3+JUAvktMC7P8F_uJoaOnfwx+WSA-2TQ@mail.gmail.com>
 <aa1f3bc4-9f34-f663-c433-1e37de771ee5@oracle.com>
Message-ID: <CAKysZ8whWMcWxOhr7dq_0U7xD=H71umvQ9mLqn1j8dc011TFkQ@mail.gmail.com>

Hi Alan,

Thanks for the review comment, we can send multiple signals for sure. I
will create a  thread which will send multiple signals.

Creating a new native method  that returns a signal is a bit too much as
SIGPIPE is a standard signal, but I will add a native method as you
suggested.

I think webrev is ignoring the spaces that is why you are observing the
formatting issues in (linux/bsd)_close.c files. In my local repo code looks
well formatted.

Thanks,
Vyom

On Sat, Jun 27, 2020 at 11:46 AM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 26/06/2020 05:17, Vyom Tiwari wrote:
> > Hi Daniel/Alan,
> > Please find the latest
> > webrev(http://cr.openjdk.java.net/~vtewari/8237858/webrev0.6/index.html
> ).
> >
> I think we can do better than one signal after 200ms. Have you given any
> thought to have a thread that signals many times so that you have a
> better chance of tickling bugs?  One other comment at this time is that
> the value of SIGPIPE is still hardcoded - I think you'll need to add
> another native method to return its value.
>
> BTW:  The formatting issues with linux_close.c and bsd_close.c are the
> same as the previous iterations. Did you track down that issue, I think
> you thought it was webrev or an issue with your patch queue.
>
> -Alan.
>
>

-- 
Thanks,
Vyom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200627/8c760c01/attachment.htm>

From vyommani at gmail.com  Mon Jun 29 07:03:39 2020
From: vyommani at gmail.com (Vyom Tiwari)
Date: Mon, 29 Jun 2020 12:33:39 +0530
Subject: RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR
 incorrectly
In-Reply-To: <CAKysZ8whWMcWxOhr7dq_0U7xD=H71umvQ9mLqn1j8dc011TFkQ@mail.gmail.com>
References: <eb820990-538f-6462-83f1-00db9c5addb9@oracle.com>
 <OF5EC3FD65.03E16FA0-ON00258528.002A5E98-00258528.002CC5FB@notes.na.collabserv.com>
 <de408110-7b0d-d630-1783-5e48e034d1f7@oracle.com>
 <DB7PR03MB439343CCC0E3DB80F5976F89FFFC0@DB7PR03MB4393.eurprd03.prod.outlook.com>
 <CAKysZ8yw=7kbG+THEKEi3DY3RoeS55tt=-zP0PfZXqeg4inz8w@mail.gmail.com>
 <242fe9b7-b9bc-03b9-0f5e-b0d01775fb64@oracle.com>
 <CAKysZ8z725FrYLcfrj5muD-AfAPda6nyksyXMVJrMM4475MzHw@mail.gmail.com>
 <CAKysZ8zX44bGfHqXUXX4GXTr04-oA-BPSU5gwmKU_x=t7-=Dow@mail.gmail.com>
 <655d84a0-648a-8217-99da-df87b16b7251@oracle.com>
 <CAKysZ8xeEAi60JN6hq+yO0==cfPvwDrPmi=+45h8VeaVS82rKA@mail.gmail.com>
 <540969d4-62a3-a74f-273d-95354b956ca1@oracle.com>
 <CAKysZ8xODBi_hdpObpqrnFcDYGADfBR2OqXUGnNPp-RuuVxJmA@mail.gmail.com>
 <f89ad3f8-8bfa-87c4-69cc-3b0d98a0dd1d@oracle.com>
 <CAKysZ8xSi8PR0ZxVt4-uM6UZngCqStRJkUmSr97ZUd1BHBDvhw@mail.gmail.com>
 <CAKysZ8wiRZErb6m9sR3+JUAvktMC7P8F_uJoaOnfwx+WSA-2TQ@mail.gmail.com>
 <aa1f3bc4-9f34-f663-c433-1e37de771ee5@oracle.com>
 <CAKysZ8whWMcWxOhr7dq_0U7xD=H71umvQ9mLqn1j8dc011TFkQ@mail.gmail.com>
Message-ID: <CAKysZ8yLGVWGaFZh+ZP-b93aMyCudVyQ6jqp5CE8gM3EG7mU=Q@mail.gmail.com>

Hi Alan,Daniel,

Please find the latest webrev(
http://cr.openjdk.java.net/~vtewari/8237858/webrev0.7/index.html). I have
added a new native method and removed the hardcoding(SIGPIPE).

I  gave a thought on creating a separate thread and sending a signal but it
will further increase the complexity of the test. If tests send signals in
separate threads  then  tests have to make sure that server thread is alive
and running.

Thanks,
Vyom

On Sat, Jun 27, 2020 at 12:56 PM Vyom Tiwari <vyommani at gmail.com> wrote:

> Hi Alan,
>
> Thanks for the review comment, we can send multiple signals for sure. I
> will create a  thread which will send multiple signals.
>
> Creating a new native method  that returns a signal is a bit too much as
> SIGPIPE is a standard signal, but I will add a native method as you
> suggested.
>
> I think webrev is ignoring the spaces that is why you are observing the
> formatting issues in (linux/bsd)_close.c files. In my local repo code looks
> well formatted.
>
> Thanks,
> Vyom
>
> On Sat, Jun 27, 2020 at 11:46 AM Alan Bateman <Alan.Bateman at oracle.com>
> wrote:
>
>> On 26/06/2020 05:17, Vyom Tiwari wrote:
>> > Hi Daniel/Alan,
>> > Please find the latest
>> > webrev(http://cr.openjdk.java.net/~vtewari/8237858/webrev0.6/index.html
>> ).
>> >
>> I think we can do better than one signal after 200ms. Have you given any
>> thought to have a thread that signals many times so that you have a
>> better chance of tickling bugs?  One other comment at this time is that
>> the value of SIGPIPE is still hardcoded - I think you'll need to add
>> another native method to return its value.
>>
>> BTW:  The formatting issues with linux_close.c and bsd_close.c are the
>> same as the previous iterations. Did you track down that issue, I think
>> you thought it was webrev or an issue with your patch queue.
>>
>> -Alan.
>>
>>
>
> --
> Thanks,
> Vyom
>


-- 
Thanks,
Vyom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200629/bd171e29/attachment.htm>

From sgehwolf at redhat.com  Mon Jun 29 08:54:17 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 29 Jun 2020 10:54:17 +0200
Subject: [8u] RFR(m): 8194298: Add support for per Socket configuration
 of TCP keepalive
In-Reply-To: <CAKysZ8ymRs+_rJ_RL_NWJjft3SKRXrA42Ln7H2q6obzad9M5Yg@mail.gmail.com>
References: <d3692fd45bce49b5ad51ce1078ffbb345d495d03.camel@redhat.com>
 <AM6PR03MB4389EFA46B30CEA78F11B6D8FF920@AM6PR03MB4389.eurprd03.prod.outlook.com>
 <21064bd9028fa4b1f0185c05df948217f857e4cc.camel@redhat.com>
 <CAKysZ8ymRs+_rJ_RL_NWJjft3SKRXrA42Ln7H2q6obzad9M5Yg@mail.gmail.com>
Message-ID: <0b4b7b2859a10cd36dd6f0f1083a92dd7f52ba06.camel@redhat.com>

Hi Vyom!

On Fri, 2020-06-26 at 15:55 +0530, Vyom Tiwari wrote:
> Hi Severin,
> 
> Overall code changes looks ok to me, I build & tested at my local REL
> it worked fine for me.

Thanks for the review!

> Below are few minor comments.
> 
> 1-> Net.java
>     1.1-> I think you don't need to explicitly convert value to integer and then pass it. You can avoid the local int variable creation as follows.
>       ExtendedOptionsImpl.setTcpKeepAliveIntvl(fd, (Integer)value);
>    1.2-> In getSocketOption you don't need to explicitly cast it to Integer.
>              return ExtendedOptionsImpl.getTcpKeepAliveIntvl(fd);
> 2-> PlainSocketImpl.java
>     1.1 -> In setOption(SocketOption<T> name, T value) you can avoid the local int variable.

Should all be fixed.

> 3-> Any specific reason for two set of functions "setTcpKeepAliveTime0 and setTcpKeepAliveTime" for all three socket options ?

Not really, other than keeping the backport aligned to the JDK 11u
patch. I've updated it in the latest webrev:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8194298/jdk8/05/webrev/

Thanks,
Severin


> Thanks,
> Vyom
> 
> On Fri, Jun 26, 2020 at 1:08 PM Severin Gehwolf <sgehwolf at redhat.com> wrote:
> > Hi,
> > 
> > On Thu, 2020-06-25 at 23:55 +0000, Bernd Eckenfels wrote:
> > > This would be a great addition.
> > 
> > Thanks.
> > 
> > > I do not understand why it does not support the options available for
> > > Windows. Especially given the fact that it actually implements 6
> > > native methods to print "Unsupported".
> > > 
> > > But I guess that's less a question to the backport and more to the
> > > general implementation.
> > 
> > Yes, indeed. This should be brought up for discussion in JDK head first
> > and implemented there before we can consider a backport.
> > 
> > Thanks,
> > Severin
> > 
> > 
> 
> 


From chris.hegarty at oracle.com  Mon Jun 29 11:05:49 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 29 Jun 2020 12:05:49 +0100
Subject: RFR 8245245 : WebSocket can loose the URL encoding of URI query
 parameters
In-Reply-To: <8306e693-c3c1-91ac-fcb2-fc15ec167d65@oracle.com>
References: <09896607-ecb3-5062-02fe-26696bd4cc28@oracle.com>
 <e97e5cc2-3595-0b5e-e1a6-0894c0edaba8@oracle.com>
 <7F1D6F6A-D58A-4486-8D0B-01FE79A85BEA@oracle.com>
 <20b92bd9-08b9-700f-c2a0-61a8b45d451a@oracle.com>
 <8306e693-c3c1-91ac-fcb2-fc15ec167d65@oracle.com>
Message-ID: <BEC8D4B9-F69B-4C5D-A196-5E301C99379E@oracle.com>


> On 26 Jun 2020, at 18:18, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> I concur. Rahul has convinced me.
> Rahul also pointed me to a test that verifies that the IAE is
> thrown, so I believe that
> http://cr.openjdk.java.net/~ryadav/webrev_8245245/index.html

LGTM.

-Chris.

From vyommani at gmail.com  Mon Jun 29 11:41:34 2020
From: vyommani at gmail.com (Vyom Tiwari)
Date: Mon, 29 Jun 2020 17:11:34 +0530
Subject: [8u] RFR(m): 8194298: Add support for per Socket configuration of
 TCP keepalive
In-Reply-To: <0b4b7b2859a10cd36dd6f0f1083a92dd7f52ba06.camel@redhat.com>
References: <d3692fd45bce49b5ad51ce1078ffbb345d495d03.camel@redhat.com>
 <AM6PR03MB4389EFA46B30CEA78F11B6D8FF920@AM6PR03MB4389.eurprd03.prod.outlook.com>
 <21064bd9028fa4b1f0185c05df948217f857e4cc.camel@redhat.com>
 <CAKysZ8ymRs+_rJ_RL_NWJjft3SKRXrA42Ln7H2q6obzad9M5Yg@mail.gmail.com>
 <0b4b7b2859a10cd36dd6f0f1083a92dd7f52ba06.camel@redhat.com>
Message-ID: <CAKysZ8w+EuN-AobuRmk+qbPA+AVCLoPE-T+BDYEvM3FEMvN-fw@mail.gmail.com>

Hi Severin,

Latest code looks good, I think in
src/solaris/native/java/net/ExtendedOptionsImpl.c, you don't need #ifdef
blocks. In case of "flowOption" it was required because flow is specific to
Solaris.

In case of KEEPALIVE we are using the POSIX api(setsockopt/getsockopt)
which exists on all POSIX OS's. If a  OS does not support KEEPALIVE then

Java_sun_net_ExtendedOptionsImpl_keepAliveOptionsSupported will return
false and #else will never execute.

For Windows we have different files and for all other platforms same
code will work without explicit #ifdef.

Please do let me know if i am missing something.

Thanks,

Vyom



On Mon, Jun 29, 2020 at 2:25 PM Severin Gehwolf <sgehwolf at redhat.com> wrote:

> Hi Vyom!
>
> On Fri, 2020-06-26 at 15:55 +0530, Vyom Tiwari wrote:
> > Hi Severin,
> >
> > Overall code changes looks ok to me, I build & tested at my local REL
> > it worked fine for me.
>
> Thanks for the review!
>
> > Below are few minor comments.
> >
> > 1-> Net.java
> >     1.1-> I think you don't need to explicitly convert value to integer
> and then pass it. You can avoid the local int variable creation as follows.
> >       ExtendedOptionsImpl.setTcpKeepAliveIntvl(fd, (Integer)value);
> >    1.2-> In getSocketOption you don't need to explicitly cast it to
> Integer.
> >              return ExtendedOptionsImpl.getTcpKeepAliveIntvl(fd);
> > 2-> PlainSocketImpl.java
> >     1.1 -> In setOption(SocketOption<T> name, T value) you can avoid the
> local int variable.
>
> Should all be fixed.
>
> > 3-> Any specific reason for two set of functions "setTcpKeepAliveTime0
> and setTcpKeepAliveTime" for all three socket options ?
>
> Not really, other than keeping the backport aligned to the JDK 11u
> patch. I've updated it in the latest webrev:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8194298/jdk8/05/webrev/
>
> Thanks,
> Severin
>
>
> > Thanks,
> > Vyom
> >
> > On Fri, Jun 26, 2020 at 1:08 PM Severin Gehwolf <sgehwolf at redhat.com>
> wrote:
> > > Hi,
> > >
> > > On Thu, 2020-06-25 at 23:55 +0000, Bernd Eckenfels wrote:
> > > > This would be a great addition.
> > >
> > > Thanks.
> > >
> > > > I do not understand why it does not support the options available for
> > > > Windows. Especially given the fact that it actually implements 6
> > > > native methods to print "Unsupported".
> > > >
> > > > But I guess that's less a question to the backport and more to the
> > > > general implementation.
> > >
> > > Yes, indeed. This should be brought up for discussion in JDK head first
> > > and implemented there before we can consider a backport.
> > >
> > > Thanks,
> > > Severin
> > >
> > >
> >
> >
>
>

-- 
Thanks,
Vyom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200629/875252b7/attachment.htm>

From sgehwolf at redhat.com  Mon Jun 29 11:57:30 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 29 Jun 2020 13:57:30 +0200
Subject: [8u] RFR(m): 8194298: Add support for per Socket configuration
 of TCP keepalive
In-Reply-To: <CAKysZ8w+EuN-AobuRmk+qbPA+AVCLoPE-T+BDYEvM3FEMvN-fw@mail.gmail.com>
References: <d3692fd45bce49b5ad51ce1078ffbb345d495d03.camel@redhat.com>
 <AM6PR03MB4389EFA46B30CEA78F11B6D8FF920@AM6PR03MB4389.eurprd03.prod.outlook.com>
 <21064bd9028fa4b1f0185c05df948217f857e4cc.camel@redhat.com>
 <CAKysZ8ymRs+_rJ_RL_NWJjft3SKRXrA42Ln7H2q6obzad9M5Yg@mail.gmail.com>
 <0b4b7b2859a10cd36dd6f0f1083a92dd7f52ba06.camel@redhat.com>
 <CAKysZ8w+EuN-AobuRmk+qbPA+AVCLoPE-T+BDYEvM3FEMvN-fw@mail.gmail.com>
Message-ID: <d7c288c3acfe4549fd5abea69d8608eb17429379.camel@redhat.com>

Hi Vyom,

On Mon, 2020-06-29 at 17:11 +0530, Vyom Tiwari wrote:
> Hi Severin,
> 
> Latest code looks good

Thanks!

> I think in src/solaris/native/java/net/ExtendedOptionsImpl.c, you
> don't need #ifdef blocks. In case of "flowOption" it was required
> because flow is specific to Solaris.
> 
> In case of KEEPALIVE we are using the POSIX
> api(setsockopt/getsockopt) which exists on all POSIX OS's. If a  OS
> does not support KEEPALIVE then 
> Java_sun_net_ExtendedOptionsImpl_keepAliveOptionsSupported will
> return false and #else will never execute.
> For Windows we have different files and for all other platforms same
> code will work without explicit #ifdef.

Not quite.

For example, on MACOSX some macros have a diferent name than on Linux.
Thus, the ifdef magic to work around that. I don't have any insight as
to what they're called on, say, solaris or aix, or, if they're
different at all. Anyway, I'd rely on somebody else doing the testing.
Without that, I don't think we can add this to other platforms and
potentially break them. Support for them could get added later if
somebody with the relevant systems steps up to do it.

> Please do let me know if i am missing something.

FWIW, those options are only enabled on Linux/Mac for JDK 11u and
jdk/jdk. Those changes would have to be done there first and then
backported.

Thanks,
Severin

> 
> On Mon, Jun 29, 2020 at 2:25 PM Severin Gehwolf <sgehwolf at redhat.com>
> wrote:
> > Hi Vyom!
> > 
> > On Fri, 2020-06-26 at 15:55 +0530, Vyom Tiwari wrote:
> > > Hi Severin,
> > > 
> > > Overall code changes looks ok to me, I build & tested at my local
> > REL
> > > it worked fine for me.
> > 
> > Thanks for the review!
> > 
> > > Below are few minor comments.
> > > 
> > > 1-> Net.java
> > >     1.1-> I think you don't need to explicitly convert value to
> > integer and then pass it. You can avoid the local int variable
> > creation as follows.
> > >       ExtendedOptionsImpl.setTcpKeepAliveIntvl(fd,
> > (Integer)value);
> > >    1.2-> In getSocketOption you don't need to explicitly cast it
> > to Integer.
> > >              return ExtendedOptionsImpl.getTcpKeepAliveIntvl(fd);
> > > 2-> PlainSocketImpl.java
> > >     1.1 -> In setOption(SocketOption<T> name, T value) you can
> > avoid the local int variable.
> > 
> > Should all be fixed.
> > 
> > > 3-> Any specific reason for two set of functions
> > "setTcpKeepAliveTime0 and setTcpKeepAliveTime" for all three socket
> > options ?
> > 
> > Not really, other than keeping the backport aligned to the JDK 11u
> > patch. I've updated it in the latest webrev:
> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8194298/jdk8/05/webrev/
> > 
> > Thanks,
> > Severin
> > 
> > 
> > > Thanks,
> > > Vyom
> > > 
> > > On Fri, Jun 26, 2020 at 1:08 PM Severin Gehwolf <
> > sgehwolf at redhat.com> wrote:
> > > > Hi,
> > > > 
> > > > On Thu, 2020-06-25 at 23:55 +0000, Bernd Eckenfels wrote:
> > > > > This would be a great addition.
> > > > 
> > > > Thanks.
> > > > 
> > > > > I do not understand why it does not support the options
> > available for
> > > > > Windows. Especially given the fact that it actually
> > implements 6
> > > > > native methods to print "Unsupported".
> > > > > 
> > > > > But I guess that's less a question to the backport and more
> > to the
> > > > > general implementation.
> > > > 
> > > > Yes, indeed. This should be brought up for discussion in JDK
> > head first
> > > > and implemented there before we can consider a backport.
> > > > 
> > > > Thanks,
> > > > Severin
> > > > 
> > > > 
> > > 
> > > 
> > 
> 
> 


From daniel.fuchs at oracle.com  Mon Jun 29 14:09:22 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 29 Jun 2020 15:09:22 +0100
Subject: 8246114: java/net/MulticastSocket/Promiscuous.java fails after
 8241072 (multi-homed systems)
Message-ID: <299ea391-b022-4901-ea34-c7bafba3cbce@oracle.com>

Hi,

Please find a trivial fix for:

8246114: java/net/MulticastSocket/Promiscuous.java fails after
          8241072 (multi-homed systems)
https://bugs.openjdk.java.net/browse/JDK-8246114

webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8246114/webrev.00/

The test should only use NetworkInterfaces for which an IPv4 address
is configured, since it's trying to join an IPv4 group.

best regards,

-- daniel

From Alan.Bateman at oracle.com  Mon Jun 29 14:40:01 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 29 Jun 2020 15:40:01 +0100
Subject: 8246114: java/net/MulticastSocket/Promiscuous.java fails after
 8241072 (multi-homed systems)
In-Reply-To: <299ea391-b022-4901-ea34-c7bafba3cbce@oracle.com>
References: <299ea391-b022-4901-ea34-c7bafba3cbce@oracle.com>
Message-ID: <47f30a58-4667-36e6-295b-f3db3dbd1fa8@oracle.com>

On 29/06/2020 15:09, Daniel Fuchs wrote:
> Hi,
>
> Please find a trivial fix for:
>
> 8246114: java/net/MulticastSocket/Promiscuous.java fails after
> ???????? 8241072 (multi-homed systems)
> https://bugs.openjdk.java.net/browse/JDK-8246114
>
> webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8246114/webrev.00/
>
> The test should only use NetworkInterfaces for which an IPv4 address
> is configured, since it's trying to join an IPv4 group.
Do you need to do the same filtering at L158? I guess I would have 
expected leaveGroup to fail because the joinGroup has been skipped.

-Alan

From daniel.fuchs at oracle.com  Mon Jun 29 15:01:54 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 29 Jun 2020 16:01:54 +0100
Subject: 8246114: java/net/MulticastSocket/Promiscuous.java fails after
 8241072 (multi-homed systems)
In-Reply-To: <47f30a58-4667-36e6-295b-f3db3dbd1fa8@oracle.com>
References: <299ea391-b022-4901-ea34-c7bafba3cbce@oracle.com>
 <47f30a58-4667-36e6-295b-f3db3dbd1fa8@oracle.com>
Message-ID: <a84da600-72c1-f51b-de8d-bbe166b61b49@oracle.com>

Ah! Good catch Alan!

http://cr.openjdk.java.net/~dfuchs/webrev_8246114/webrev.01/

best regards,

-- daniel

On 29/06/2020 15:40, Alan Bateman wrote:
> Do you need to do the same filtering at L158? I guess I would have 
> expected leaveGroup to fail because the joinGroup has been skipped.
> 


From vyommani at gmail.com  Mon Jun 29 15:48:07 2020
From: vyommani at gmail.com (Vyom Tiwari)
Date: Mon, 29 Jun 2020 21:18:07 +0530
Subject: [8u] RFR(m): 8194298: Add support for per Socket configuration of
 TCP keepalive
In-Reply-To: <d7c288c3acfe4549fd5abea69d8608eb17429379.camel@redhat.com>
References: <d3692fd45bce49b5ad51ce1078ffbb345d495d03.camel@redhat.com>
 <AM6PR03MB4389EFA46B30CEA78F11B6D8FF920@AM6PR03MB4389.eurprd03.prod.outlook.com>
 <21064bd9028fa4b1f0185c05df948217f857e4cc.camel@redhat.com>
 <CAKysZ8ymRs+_rJ_RL_NWJjft3SKRXrA42Ln7H2q6obzad9M5Yg@mail.gmail.com>
 <0b4b7b2859a10cd36dd6f0f1083a92dd7f52ba06.camel@redhat.com>
 <CAKysZ8w+EuN-AobuRmk+qbPA+AVCLoPE-T+BDYEvM3FEMvN-fw@mail.gmail.com>
 <d7c288c3acfe4549fd5abea69d8608eb17429379.camel@redhat.com>
Message-ID: <CAKysZ8wR7v79Z54NctSntVyHSRH09CkPa9cOjyRegQL7Q0jh-Q@mail.gmail.com>

Hi Severin,

thanks for clarification, we can still simplify the ExtendedOptionsImpl.c.
Please have a look on below change and do let me know if it makes sense.

I moved the "#if defined(__linux__) || defined(MACOSX)" inside the
corresponding  methods and this way we will eliminate lot's of duplicate
code.

Thanks,
Vyom
diff -r beb15266ba1a src/solaris/native/java/net/ExtendedOptionsImpl.c
--- a/src/solaris/native/java/net/ExtendedOptionsImpl.c Thu Feb 27 19:01:36
2020 +0000
+++ b/src/solaris/native/java/net/ExtendedOptionsImpl.c Mon Jun 29 21:12:16
2020 +0530
@@ -25,6 +25,10 @@

 #include <jni.h>
 #include <string.h>
+#if defined(__linux__) || defined(MACOSX)
+#include <netinet/tcp.h>
+#include <netinet/in.h>
+#endif

 #include "net_util.h"
 #include "jdk_net_SocketFlow.h"
@@ -328,9 +332,204 @@
     return JNI_FALSE;
 }

+// Keep alive options are available for MACOSX and Linux only for
+// the time being.
+#if defined(__linux__) || defined(MACOSX)
+
+// Map socket option level/name to OS specific constant
+#ifdef __linux__
+#define SOCK_OPT_LEVEL SOL_TCP
+#define SOCK_OPT_NAME_KEEPIDLE TCP_KEEPIDLE
+#define SOCK_OPT_NAME_KEEPIDLE_STR "TCP_KEEPIDLE"
+#endif
+#ifdef MACOSX
+#define SOCK_OPT_LEVEL IPPROTO_TCP
+#define SOCK_OPT_NAME_KEEPIDLE TCP_KEEPALIVE
+#define SOCK_OPT_NAME_KEEPIDLE_STR "TCP_KEEPALIVE"
+#endif
+
+static jint socketOptionSupported(jint sockopt) {
+    jint one = 1;
+    jint rv, s;
+    s = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);
+    if (s < 0) {
+        return 0;
+    }
+    rv = setsockopt(s, SOCK_OPT_LEVEL, sockopt, (void *) &one, sizeof
(one));
+    if (rv != 0 && errno == ENOPROTOOPT) {
+        rv = 0;
+    } else {
+        rv = 1;
+    }
+    close(s);
+    return rv;
+}
+
+static void handleError(JNIEnv *env, jint rv, const char *errmsg) {
+    if (rv < 0) {
+        if (errno == ENOPROTOOPT) {
+            JNU_ThrowByName(env, "java/lang/UnsupportedOperationException",
+                    "unsupported socket option");
+        } else {
+            JNU_ThrowByNameWithLastError(env, "java/net/SocketException",
errmsg);
+        }
+    }
+}
+
+#endif /* __linux__ || MACOSX*/
+
 #endif /* __solaris__ */

 JNIEXPORT jboolean JNICALL Java_sun_net_ExtendedOptionsImpl_flowSupported
   (JNIEnv *env, jclass UNUSED) {
     return flowSupported0();
 }
+
+/*
+ * Class:     sun_net_ExtendedOptionsImpl
+ * Method:    keepAliveOptionsSupported
+ * Signature: ()Z
+ */
+JNIEXPORT jboolean JNICALL
Java_sun_net_ExtendedOptionsImpl_keepAliveOptionsSupported
+(JNIEnv *env, jobject unused) {
+    #if defined(__linux__) || defined(MACOSX)
+        return socketOptionSupported(SOCK_OPT_NAME_KEEPIDLE) &&
socketOptionSupported(TCP_KEEPCNT)
+                && socketOptionSupported(TCP_KEEPINTVL);
+    #else
+        return JNI_FALSE;
+}
+
+/*
+ * Class:     sun_net_ExtendedOptionsImpl
+ * Method:    setTcpKeepAliveProbes
+ * Signature: (Ljava/io/FileDescriptor;I)V
+ */
+JNIEXPORT void JNICALL
Java_sun_net_ExtendedOptionsImpl_setTcpKeepAliveProbes
+(JNIEnv *env, jobject unused, jobject fileDesc, jint optval) {
+    #if defined(__linux__) || defined(MACOSX)
+        int fd = getFD(env, fileDesc);
+        if (fd < 0) {
+            NET_ERROR(env, JNU_JAVANETPKG "SocketException", "socket
closed");
+            return;
+        } else {
+            jint rv = setsockopt(fd, SOCK_OPT_LEVEL, TCP_KEEPCNT, &optval,
sizeof (optval));
+            handleError(env, rv, "set option TCP_KEEPCNT failed");
+        }
+    #else
+        JNU_ThrowByName(env, "java/lang/UnsupportedOperationException",
"unsupported socket option");
+    #endif
+}
+
+/*
+ * Class:     sun_net_ExtendedOptionsImpl
+ * Method:    setTcpKeepAliveTime
+ * Signature: (Ljava/io/FileDescriptor;I)V
+ */
+JNIEXPORT void JNICALL Java_sun_net_ExtendedOptionsImpl_setTcpKeepAliveTime
+(JNIEnv *env, jobject unused, jobject fileDesc, jint optval) {
+    #if defined(__linux__) || defined(MACOSX)
+        int fd = getFD(env, fileDesc);
+        if (fd < 0) {
+            NET_ERROR(env, JNU_JAVANETPKG "SocketException", "socket
closed");
+            return;
+        } else {
+            jint rv = setsockopt(fd, SOCK_OPT_LEVEL,
SOCK_OPT_NAME_KEEPIDLE, &optval, sizeof (optval));
+            handleError(env, rv, "set option " SOCK_OPT_NAME_KEEPIDLE_STR
" failed");
+        }
+    #else
+        JNU_ThrowByName(env, "java/lang/UnsupportedOperationException",
"unsupported socket option");
+    #endif
+}
+
+/*
+ * Class:     sun_net_ExtendedOptionsImpl
+ * Method:    setTcpKeepAliveIntvl
+ * Signature: (Ljava/io/FileDescriptor;I)V
+ */
+JNIEXPORT void JNICALL
Java_sun_net_ExtendedOptionsImpl_setTcpKeepAliveIntvl
+(JNIEnv *env, jobject unused, jobject fileDesc, jint optval) {
+    #if defined(__linux__) || defined(MACOSX)
+        int fd = getFD(env, fileDesc);
+        if (fd < 0) {
+            NET_ERROR(env, JNU_JAVANETPKG "SocketException", "socket
closed");
+            return;
+        } else {
+            jint rv = setsockopt(fd, SOCK_OPT_LEVEL, TCP_KEEPINTVL,
&optval, sizeof (optval));
+            handleError(env, rv, "set option TCP_KEEPINTVL failed");
+        }
+    #else
+        JNU_ThrowByName(env, "java/lang/UnsupportedOperationException",
"unsupported socket option");
+    #endif
+}
+
+/*
+ * Class:     sun_net_ExtendedOptionsImpl
+ * Method:    getTcpKeepAliveProbes
+ * Signature: (Ljava/io/FileDescriptor;)I
+ */
+JNIEXPORT jint JNICALL
Java_sun_net_ExtendedOptionsImpl_getTcpKeepAliveProbes
+(JNIEnv *env, jobject unused, jobject fileDesc) {
+    #if defined(__linux__) || defined(MACOSX)
+        int fd = getFD(env, fileDesc);
+        if (fd < 0) {
+            NET_ERROR(env, JNU_JAVANETPKG "SocketException", "socket
closed");
+            return -1;
+        } else {
+            jint optval, rv;
+            socklen_t sz = sizeof (optval);
+            rv = getsockopt(fd, SOCK_OPT_LEVEL, TCP_KEEPCNT, &optval, &sz);
+            handleError(env, rv, "get option TCP_KEEPCNT failed");
+            return optval;
+        }
+    #else
+        JNU_ThrowByName(env, "java/lang/UnsupportedOperationException",
"unsupported socket option");
+    #endif
+}
+
+/*
+ * Class:     sun_net_ExtendedOptionsImpl
+ * Method:    getTcpKeepAliveTime
+ * Signature: (Ljava/io/FileDescriptor;)I
+ */
+JNIEXPORT jint JNICALL Java_sun_net_ExtendedOptionsImpl_getTcpKeepAliveTime
+(JNIEnv *env, jobject unused, jobject fileDesc) {
+    #if defined(__linux__) || defined(MACOSX)
+        int fd = getFD(env, fileDesc);
+        if (fd < 0) {
+            NET_ERROR(env, JNU_JAVANETPKG "SocketException", "socket
closed");
+            return -1;
+        } else {
+            jint optval, rv;
+            socklen_t sz = sizeof (optval);
+            rv = getsockopt(fd, SOCK_OPT_LEVEL, SOCK_OPT_NAME_KEEPIDLE,
&optval, &sz);
+            handleError(env, rv, "get option " SOCK_OPT_NAME_KEEPIDLE_STR
" failed");
+            return optval;
+        }
+    #else
+        JNU_ThrowByName(env, "java/lang/UnsupportedOperationException",
"unsupported socket option");
+    #endif
+}
+
+/*
+ * Class:     sun_net_ExtendedOptionsImpl
+ * Method:    getTcpKeepAliveIntvl
+ * Signature: (Ljava/io/FileDescriptor;)I
+ */
+JNIEXPORT jint JNICALL
Java_sun_net_ExtendedOptionsImpl_getTcpKeepAliveIntvl
+(JNIEnv *env, jobject unused, jobject fileDesc) {
+    #if defined(__linux__) || defined(MACOSX)
+        int fd = getFD(env, fileDesc);
+        if (fd < 0) {
+            NET_ERROR(env, JNU_JAVANETPKG "SocketException", "socket
closed");
+            return -1;
+        } else {
+            jint optval, rv;
+            socklen_t sz = sizeof (optval);
+            rv = getsockopt(fd, SOCK_OPT_LEVEL, TCP_KEEPINTVL, &optval,
&sz);
+            handleError(env, rv, "get option TCP_KEEPINTVL failed");
+            return optval;
+        }
+    #else
+        JNU_ThrowByName(env, "java/lang/UnsupportedOperationException",
"unsupported socket option");
+    #endif
+}

On Mon, Jun 29, 2020 at 5:27 PM Severin Gehwolf <sgehwolf at redhat.com> wrote:

> Hi Vyom,
>
> On Mon, 2020-06-29 at 17:11 +0530, Vyom Tiwari wrote:
> > Hi Severin,
> >
> > Latest code looks good
>
> Thanks!
>
> > I think in src/solaris/native/java/net/ExtendedOptionsImpl.c, you
> > don't need #ifdef blocks. In case of "flowOption" it was required
> > because flow is specific to Solaris.
> >
> > In case of KEEPALIVE we are using the POSIX
> > api(setsockopt/getsockopt) which exists on all POSIX OS's. If a  OS
> > does not support KEEPALIVE then
> > Java_sun_net_ExtendedOptionsImpl_keepAliveOptionsSupported will
> > return false and #else will never execute.
> > For Windows we have different files and for all other platforms same
> > code will work without explicit #ifdef.
>
> Not quite.
>
> For example, on MACOSX some macros have a diferent name than on Linux.
> Thus, the ifdef magic to work around that. I don't have any insight as
> to what they're called on, say, solaris or aix, or, if they're
> different at all. Anyway, I'd rely on somebody else doing the testing.
> Without that, I don't think we can add this to other platforms and
> potentially break them. Support for them could get added later if
> somebody with the relevant systems steps up to do it.
>
> > Please do let me know if i am missing something.
>
> FWIW, those options are only enabled on Linux/Mac for JDK 11u and
> jdk/jdk. Those changes would have to be done there first and then
> backported.
>
> Thanks,
> Severin
>
> >
> > On Mon, Jun 29, 2020 at 2:25 PM Severin Gehwolf <sgehwolf at redhat.com>
> > wrote:
> > > Hi Vyom!
> > >
> > > On Fri, 2020-06-26 at 15:55 +0530, Vyom Tiwari wrote:
> > > > Hi Severin,
> > > >
> > > > Overall code changes looks ok to me, I build & tested at my local
> > > REL
> > > > it worked fine for me.
> > >
> > > Thanks for the review!
> > >
> > > > Below are few minor comments.
> > > >
> > > > 1-> Net.java
> > > >     1.1-> I think you don't need to explicitly convert value to
> > > integer and then pass it. You can avoid the local int variable
> > > creation as follows.
> > > >       ExtendedOptionsImpl.setTcpKeepAliveIntvl(fd,
> > > (Integer)value);
> > > >    1.2-> In getSocketOption you don't need to explicitly cast it
> > > to Integer.
> > > >              return ExtendedOptionsImpl.getTcpKeepAliveIntvl(fd);
> > > > 2-> PlainSocketImpl.java
> > > >     1.1 -> In setOption(SocketOption<T> name, T value) you can
> > > avoid the local int variable.
> > >
> > > Should all be fixed.
> > >
> > > > 3-> Any specific reason for two set of functions
> > > "setTcpKeepAliveTime0 and setTcpKeepAliveTime" for all three socket
> > > options ?
> > >
> > > Not really, other than keeping the backport aligned to the JDK 11u
> > > patch. I've updated it in the latest webrev:
> > >
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8194298/jdk8/05/webrev/
> > >
> > > Thanks,
> > > Severin
> > >
> > >
> > > > Thanks,
> > > > Vyom
> > > >
> > > > On Fri, Jun 26, 2020 at 1:08 PM Severin Gehwolf <
> > > sgehwolf at redhat.com> wrote:
> > > > > Hi,
> > > > >
> > > > > On Thu, 2020-06-25 at 23:55 +0000, Bernd Eckenfels wrote:
> > > > > > This would be a great addition.
> > > > >
> > > > > Thanks.
> > > > >
> > > > > > I do not understand why it does not support the options
> > > available for
> > > > > > Windows. Especially given the fact that it actually
> > > implements 6
> > > > > > native methods to print "Unsupported".
> > > > > >
> > > > > > But I guess that's less a question to the backport and more
> > > to the
> > > > > > general implementation.
> > > > >
> > > > > Yes, indeed. This should be brought up for discussion in JDK
> > > head first
> > > > > and implemented there before we can consider a backport.
> > > > >
> > > > > Thanks,
> > > > > Severin
> > > > >
> > > > >
> > > >
> > > >
> > >
> >
> >
>
>

-- 
Thanks,
Vyom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200629/329c53b1/attachment-0001.htm>

From Alan.Bateman at oracle.com  Mon Jun 29 15:50:07 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 29 Jun 2020 16:50:07 +0100
Subject: 8246114: java/net/MulticastSocket/Promiscuous.java fails after
 8241072 (multi-homed systems)
In-Reply-To: <a84da600-72c1-f51b-de8d-bbe166b61b49@oracle.com>
References: <299ea391-b022-4901-ea34-c7bafba3cbce@oracle.com>
 <47f30a58-4667-36e6-295b-f3db3dbd1fa8@oracle.com>
 <a84da600-72c1-f51b-de8d-bbe166b61b49@oracle.com>
Message-ID: <d68fde5e-926e-86a8-f391-a35624521653@oracle.com>



On 29/06/2020 16:01, Daniel Fuchs wrote:
> Ah! Good catch Alan!
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8246114/webrev.01/
>
This looks good to me.

From sgehwolf at redhat.com  Mon Jun 29 16:06:09 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 29 Jun 2020 18:06:09 +0200
Subject: [8u] RFR(m): 8194298: Add support for per Socket configuration
 of TCP keepalive
In-Reply-To: <CAKysZ8wR7v79Z54NctSntVyHSRH09CkPa9cOjyRegQL7Q0jh-Q@mail.gmail.com>
References: <d3692fd45bce49b5ad51ce1078ffbb345d495d03.camel@redhat.com>
 <AM6PR03MB4389EFA46B30CEA78F11B6D8FF920@AM6PR03MB4389.eurprd03.prod.outlook.com>
 <21064bd9028fa4b1f0185c05df948217f857e4cc.camel@redhat.com>
 <CAKysZ8ymRs+_rJ_RL_NWJjft3SKRXrA42Ln7H2q6obzad9M5Yg@mail.gmail.com>
 <0b4b7b2859a10cd36dd6f0f1083a92dd7f52ba06.camel@redhat.com>
 <CAKysZ8w+EuN-AobuRmk+qbPA+AVCLoPE-T+BDYEvM3FEMvN-fw@mail.gmail.com>
 <d7c288c3acfe4549fd5abea69d8608eb17429379.camel@redhat.com>
 <CAKysZ8wR7v79Z54NctSntVyHSRH09CkPa9cOjyRegQL7Q0jh-Q@mail.gmail.com>
Message-ID: <26e51ac19f9e9fc445d95f4180bf5da5e3b32c87.camel@redhat.com>

Hi Yyom,

On Mon, 2020-06-29 at 21:18 +0530, Vyom Tiwari wrote:
> Hi Severin,
> 
> thanks for clarification, we can still simplify the
> ExtendedOptionsImpl.c. Please have a look on below change and do let
> me know if it makes sense.
> 
> I moved the "#if defined(__linux__) || defined(MACOSX)" inside the
> corresponding  methods and this way we will eliminate lot's of
> duplicate code.

It's a possibility. IMHO, it doesn't really make the code easier to
read, though. Some duplication for clarity seems OK to me in this case.
I'm not too fond of over-use of ifdef so I'd rather keep it at v5.
YMMV.

Let's see what others think.

Thanks,
Severin

> Thanks,
> Vyom
> diff -r beb15266ba1a
> src/solaris/native/java/net/ExtendedOptionsImpl.c
> --- a/src/solaris/native/java/net/ExtendedOptionsImpl.c Thu Feb 27
> 19:01:36 2020 +0000
> +++ b/src/solaris/native/java/net/ExtendedOptionsImpl.c Mon Jun 29
> 21:12:16 2020 +0530
> @@ -25,6 +25,10 @@
>  
>  #include <jni.h>
>  #include <string.h>
> +#if defined(__linux__) || defined(MACOSX)
> +#include <netinet/tcp.h>
> +#include <netinet/in.h>
> +#endif
>  
>  #include "net_util.h"
>  #include "jdk_net_SocketFlow.h"
> @@ -328,9 +332,204 @@
>      return JNI_FALSE;
>  }
>  
> +// Keep alive options are available for MACOSX and Linux only for
> +// the time being.
> +#if defined(__linux__) || defined(MACOSX)
> +
> +// Map socket option level/name to OS specific constant
> +#ifdef __linux__
> +#define SOCK_OPT_LEVEL SOL_TCP
> +#define SOCK_OPT_NAME_KEEPIDLE TCP_KEEPIDLE
> +#define SOCK_OPT_NAME_KEEPIDLE_STR "TCP_KEEPIDLE"
> +#endif
> +#ifdef MACOSX
> +#define SOCK_OPT_LEVEL IPPROTO_TCP
> +#define SOCK_OPT_NAME_KEEPIDLE TCP_KEEPALIVE
> +#define SOCK_OPT_NAME_KEEPIDLE_STR "TCP_KEEPALIVE"
> +#endif
> +
> +static jint socketOptionSupported(jint sockopt) {
> +    jint one = 1;
> +    jint rv, s;
> +    s = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);
> +    if (s < 0) {
> +        return 0;
> +    }
> +    rv = setsockopt(s, SOCK_OPT_LEVEL, sockopt, (void *) &one,
> sizeof (one));
> +    if (rv != 0 && errno == ENOPROTOOPT) {
> +        rv = 0;
> +    } else {
> +        rv = 1;
> +    }
> +    close(s);
> +    return rv;
> +}
> +
> +static void handleError(JNIEnv *env, jint rv, const char *errmsg) {
> +    if (rv < 0) {
> +        if (errno == ENOPROTOOPT) {
> +            JNU_ThrowByName(env,
> "java/lang/UnsupportedOperationException",
> +                    "unsupported socket option");
> +        } else {
> +            JNU_ThrowByNameWithLastError(env,
> "java/net/SocketException", errmsg);
> +        }
> +    }
> +}
> +
> +#endif /* __linux__ || MACOSX*/
> +
>  #endif /* __solaris__ */
>  
>  JNIEXPORT jboolean JNICALL
> Java_sun_net_ExtendedOptionsImpl_flowSupported
>    (JNIEnv *env, jclass UNUSED) {
>      return flowSupported0();
>  }
> +
> +/*
> + * Class:     sun_net_ExtendedOptionsImpl
> + * Method:    keepAliveOptionsSupported
> + * Signature: ()Z
> + */
> +JNIEXPORT jboolean JNICALL
> Java_sun_net_ExtendedOptionsImpl_keepAliveOptionsSupported
> +(JNIEnv *env, jobject unused) {
> +    #if defined(__linux__) || defined(MACOSX)
> +        return socketOptionSupported(SOCK_OPT_NAME_KEEPIDLE) &&
> socketOptionSupported(TCP_KEEPCNT)
> +                && socketOptionSupported(TCP_KEEPINTVL);
> +    #else
> +        return JNI_FALSE;
> +}
> +
> +/*
> + * Class:     sun_net_ExtendedOptionsImpl
> + * Method:    setTcpKeepAliveProbes
> + * Signature: (Ljava/io/FileDescriptor;I)V
> + */
> +JNIEXPORT void JNICALL
> Java_sun_net_ExtendedOptionsImpl_setTcpKeepAliveProbes
> +(JNIEnv *env, jobject unused, jobject fileDesc, jint optval) {
> +    #if defined(__linux__) || defined(MACOSX)
> +        int fd = getFD(env, fileDesc);
> +        if (fd < 0) {
> +            NET_ERROR(env, JNU_JAVANETPKG "SocketException", "socket
> closed");
> +            return;
> +        } else {
> +            jint rv = setsockopt(fd, SOCK_OPT_LEVEL, TCP_KEEPCNT,
> &optval, sizeof (optval));
> +            handleError(env, rv, "set option TCP_KEEPCNT failed");
> +        }
> +    #else
> +        JNU_ThrowByName(env,
> "java/lang/UnsupportedOperationException", "unsupported socket
> option");
> +    #endif
> +}
> +
> +/*
> + * Class:     sun_net_ExtendedOptionsImpl
> + * Method:    setTcpKeepAliveTime
> + * Signature: (Ljava/io/FileDescriptor;I)V
> + */
> +JNIEXPORT void JNICALL
> Java_sun_net_ExtendedOptionsImpl_setTcpKeepAliveTime
> +(JNIEnv *env, jobject unused, jobject fileDesc, jint optval) {
> +    #if defined(__linux__) || defined(MACOSX)
> +        int fd = getFD(env, fileDesc);
> +        if (fd < 0) {
> +            NET_ERROR(env, JNU_JAVANETPKG "SocketException", "socket
> closed");
> +            return;
> +        } else {
> +            jint rv = setsockopt(fd, SOCK_OPT_LEVEL,
> SOCK_OPT_NAME_KEEPIDLE, &optval, sizeof (optval));
> +            handleError(env, rv, "set option "
> SOCK_OPT_NAME_KEEPIDLE_STR " failed");
> +        }
> +    #else
> +        JNU_ThrowByName(env,
> "java/lang/UnsupportedOperationException", "unsupported socket
> option");
> +    #endif
> +}
> +
> +/*
> + * Class:     sun_net_ExtendedOptionsImpl
> + * Method:    setTcpKeepAliveIntvl
> + * Signature: (Ljava/io/FileDescriptor;I)V
> + */
> +JNIEXPORT void JNICALL
> Java_sun_net_ExtendedOptionsImpl_setTcpKeepAliveIntvl
> +(JNIEnv *env, jobject unused, jobject fileDesc, jint optval) {
> +    #if defined(__linux__) || defined(MACOSX)
> +        int fd = getFD(env, fileDesc);
> +        if (fd < 0) {
> +            NET_ERROR(env, JNU_JAVANETPKG "SocketException", "socket
> closed");
> +            return;
> +        } else {
> +            jint rv = setsockopt(fd, SOCK_OPT_LEVEL, TCP_KEEPINTVL,
> &optval, sizeof (optval));
> +            handleError(env, rv, "set option TCP_KEEPINTVL failed");
> +        }
> +    #else
> +        JNU_ThrowByName(env,
> "java/lang/UnsupportedOperationException", "unsupported socket
> option");
> +    #endif
> +}
> +
> +/*
> + * Class:     sun_net_ExtendedOptionsImpl
> + * Method:    getTcpKeepAliveProbes
> + * Signature: (Ljava/io/FileDescriptor;)I
> + */
> +JNIEXPORT jint JNICALL
> Java_sun_net_ExtendedOptionsImpl_getTcpKeepAliveProbes
> +(JNIEnv *env, jobject unused, jobject fileDesc) {
> +    #if defined(__linux__) || defined(MACOSX)
> +        int fd = getFD(env, fileDesc);
> +        if (fd < 0) {
> +            NET_ERROR(env, JNU_JAVANETPKG "SocketException", "socket
> closed");
> +            return -1;
> +        } else {
> +            jint optval, rv;
> +            socklen_t sz = sizeof (optval);
> +            rv = getsockopt(fd, SOCK_OPT_LEVEL, TCP_KEEPCNT,
> &optval, &sz);
> +            handleError(env, rv, "get option TCP_KEEPCNT failed");
> +            return optval;
> +        }
> +    #else
> +        JNU_ThrowByName(env,
> "java/lang/UnsupportedOperationException", "unsupported socket
> option");
> +    #endif
> +}
> +
> +/*
> + * Class:     sun_net_ExtendedOptionsImpl
> + * Method:    getTcpKeepAliveTime
> + * Signature: (Ljava/io/FileDescriptor;)I
> + */
> +JNIEXPORT jint JNICALL
> Java_sun_net_ExtendedOptionsImpl_getTcpKeepAliveTime
> +(JNIEnv *env, jobject unused, jobject fileDesc) {
> +    #if defined(__linux__) || defined(MACOSX)
> +        int fd = getFD(env, fileDesc);
> +        if (fd < 0) {
> +            NET_ERROR(env, JNU_JAVANETPKG "SocketException", "socket
> closed");
> +            return -1;
> +        } else {
> +            jint optval, rv;
> +            socklen_t sz = sizeof (optval);
> +            rv = getsockopt(fd, SOCK_OPT_LEVEL,
> SOCK_OPT_NAME_KEEPIDLE, &optval, &sz);
> +            handleError(env, rv, "get option "
> SOCK_OPT_NAME_KEEPIDLE_STR " failed");
> +            return optval;
> +        }
> +    #else
> +        JNU_ThrowByName(env,
> "java/lang/UnsupportedOperationException", "unsupported socket
> option");
> +    #endif
> +}
> +
> +/*
> + * Class:     sun_net_ExtendedOptionsImpl
> + * Method:    getTcpKeepAliveIntvl
> + * Signature: (Ljava/io/FileDescriptor;)I
> + */
> +JNIEXPORT jint JNICALL
> Java_sun_net_ExtendedOptionsImpl_getTcpKeepAliveIntvl
> +(JNIEnv *env, jobject unused, jobject fileDesc) {
> +    #if defined(__linux__) || defined(MACOSX)
> +        int fd = getFD(env, fileDesc);
> +        if (fd < 0) {
> +            NET_ERROR(env, JNU_JAVANETPKG "SocketException", "socket
> closed");
> +            return -1;
> +        } else {
> +            jint optval, rv;
> +            socklen_t sz = sizeof (optval);
> +            rv = getsockopt(fd, SOCK_OPT_LEVEL, TCP_KEEPINTVL,
> &optval, &sz);
> +            handleError(env, rv, "get option TCP_KEEPINTVL failed");
> +            return optval;
> +        }
> +    #else
> +        JNU_ThrowByName(env,
> "java/lang/UnsupportedOperationException", "unsupported socket
> option");
> +    #endif
> +}
> 
> On Mon, Jun 29, 2020 at 5:27 PM Severin Gehwolf <sgehwolf at redhat.com>
> wrote:
> > Hi Vyom,
> > 
> > On Mon, 2020-06-29 at 17:11 +0530, Vyom Tiwari wrote:
> > > Hi Severin,
> > > 
> > > Latest code looks good
> > 
> > Thanks!
> > 
> > > I think in src/solaris/native/java/net/ExtendedOptionsImpl.c, you
> > > don't need #ifdef blocks. In case of "flowOption" it was required
> > > because flow is specific to Solaris.
> > > 
> > > In case of KEEPALIVE we are using the POSIX
> > > api(setsockopt/getsockopt) which exists on all POSIX OS's. If a 
> > OS
> > > does not support KEEPALIVE then 
> > > Java_sun_net_ExtendedOptionsImpl_keepAliveOptionsSupported will
> > > return false and #else will never execute.
> > > For Windows we have different files and for all other platforms
> > same
> > > code will work without explicit #ifdef.
> > 
> > Not quite.
> > 
> > For example, on MACOSX some macros have a diferent name than on
> > Linux.
> > Thus, the ifdef magic to work around that. I don't have any insight
> > as
> > to what they're called on, say, solaris or aix, or, if they're
> > different at all. Anyway, I'd rely on somebody else doing the
> > testing.
> > Without that, I don't think we can add this to other platforms and
> > potentially break them. Support for them could get added later if
> > somebody with the relevant systems steps up to do it.
> > 
> > > Please do let me know if i am missing something.
> > 
> > FWIW, those options are only enabled on Linux/Mac for JDK 11u and
> > jdk/jdk. Those changes would have to be done there first and then
> > backported.
> > 
> > Thanks,
> > Severin
> > 
> > > 
> > > On Mon, Jun 29, 2020 at 2:25 PM Severin Gehwolf <
> > sgehwolf at redhat.com>
> > > wrote:
> > > > Hi Vyom!
> > > > 
> > > > On Fri, 2020-06-26 at 15:55 +0530, Vyom Tiwari wrote:
> > > > > Hi Severin,
> > > > > 
> > > > > Overall code changes looks ok to me, I build & tested at my
> > local
> > > > REL
> > > > > it worked fine for me.
> > > > 
> > > > Thanks for the review!
> > > > 
> > > > > Below are few minor comments.
> > > > > 
> > > > > 1-> Net.java
> > > > >     1.1-> I think you don't need to explicitly convert value
> > to
> > > > integer and then pass it. You can avoid the local int variable
> > > > creation as follows.
> > > > >       ExtendedOptionsImpl.setTcpKeepAliveIntvl(fd,
> > > > (Integer)value);
> > > > >    1.2-> In getSocketOption you don't need to explicitly cast
> > it
> > > > to Integer.
> > > > >              return
> > ExtendedOptionsImpl.getTcpKeepAliveIntvl(fd);
> > > > > 2-> PlainSocketImpl.java
> > > > >     1.1 -> In setOption(SocketOption<T> name, T value) you
> > can
> > > > avoid the local int variable.
> > > > 
> > > > Should all be fixed.
> > > > 
> > > > > 3-> Any specific reason for two set of functions
> > > > "setTcpKeepAliveTime0 and setTcpKeepAliveTime" for all three
> > socket
> > > > options ?
> > > > 
> > > > Not really, other than keeping the backport aligned to the JDK
> > 11u
> > > > patch. I've updated it in the latest webrev:
> > > > 
> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8194298/jdk8/05/webrev/
> > > > 
> > > > Thanks,
> > > > Severin
> > > > 
> > > > 
> > > > > Thanks,
> > > > > Vyom
> > > > > 
> > > > > On Fri, Jun 26, 2020 at 1:08 PM Severin Gehwolf <
> > > > sgehwolf at redhat.com> wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > On Thu, 2020-06-25 at 23:55 +0000, Bernd Eckenfels wrote:
> > > > > > > This would be a great addition.
> > > > > > 
> > > > > > Thanks.
> > > > > > 
> > > > > > > I do not understand why it does not support the options
> > > > available for
> > > > > > > Windows. Especially given the fact that it actually
> > > > implements 6
> > > > > > > native methods to print "Unsupported".
> > > > > > > 
> > > > > > > But I guess that's less a question to the backport and
> > more
> > > > to the
> > > > > > > general implementation.
> > > > > > 
> > > > > > Yes, indeed. This should be brought up for discussion in
> > JDK
> > > > head first
> > > > > > and implemented there before we can consider a backport.
> > > > > > 
> > > > > > Thanks,
> > > > > > Severin
> > > > > > 
> > > > > > 
> > > > > 
> > > > > 
> > > > 
> > > 
> > > 
> > 
> 
> 


From daniel.fuchs at oracle.com  Mon Jun 29 16:51:53 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 29 Jun 2020 17:51:53 +0100
Subject: RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR
 incorrectly
In-Reply-To: <CAKysZ8yLGVWGaFZh+ZP-b93aMyCudVyQ6jqp5CE8gM3EG7mU=Q@mail.gmail.com>
References: <eb820990-538f-6462-83f1-00db9c5addb9@oracle.com>
 <CAKysZ8yw=7kbG+THEKEi3DY3RoeS55tt=-zP0PfZXqeg4inz8w@mail.gmail.com>
 <242fe9b7-b9bc-03b9-0f5e-b0d01775fb64@oracle.com>
 <CAKysZ8z725FrYLcfrj5muD-AfAPda6nyksyXMVJrMM4475MzHw@mail.gmail.com>
 <CAKysZ8zX44bGfHqXUXX4GXTr04-oA-BPSU5gwmKU_x=t7-=Dow@mail.gmail.com>
 <655d84a0-648a-8217-99da-df87b16b7251@oracle.com>
 <CAKysZ8xeEAi60JN6hq+yO0==cfPvwDrPmi=+45h8VeaVS82rKA@mail.gmail.com>
 <540969d4-62a3-a74f-273d-95354b956ca1@oracle.com>
 <CAKysZ8xODBi_hdpObpqrnFcDYGADfBR2OqXUGnNPp-RuuVxJmA@mail.gmail.com>
 <f89ad3f8-8bfa-87c4-69cc-3b0d98a0dd1d@oracle.com>
 <CAKysZ8xSi8PR0ZxVt4-uM6UZngCqStRJkUmSr97ZUd1BHBDvhw@mail.gmail.com>
 <CAKysZ8wiRZErb6m9sR3+JUAvktMC7P8F_uJoaOnfwx+WSA-2TQ@mail.gmail.com>
 <aa1f3bc4-9f34-f663-c433-1e37de771ee5@oracle.com>
 <CAKysZ8whWMcWxOhr7dq_0U7xD=H71umvQ9mLqn1j8dc011TFkQ@mail.gmail.com>
 <CAKysZ8yLGVWGaFZh+ZP-b93aMyCudVyQ6jqp5CE8gM3EG7mU=Q@mail.gmail.com>
Message-ID: <6462be23-71b5-f04a-f289-abc77560f633@oracle.com>

Hi Vyom,


On 29/06/2020 08:03, Vyom Tiwari wrote:
> Hi Alan,Daniel,
> 
> Please find the latest 
> webrev(http://cr.openjdk.java.net/~vtewari/8237858/webrev0.7/index.html). I 
> have added a new native method and removed the hardcoding(SIGPIPE).

That fails to build on windows:

[2020-06-29T15:26:16,899Z] ERROR: Build failed for target 'default 
(product-bundles test-bundles static-libs-bundles)' in configuration 
'windows-x64' (exit code 2)
[2020-06-29T15:26:17,587Z] * For target 
support_test_jdk_jtreg_native_support_libNativeThread_libNativeThread.obj:
[2020-06-29T15:26:17,649Z] libNativeThread.c
[2020-06-29T15:26:17,649Z] 
./open/test/jdk/java/net/Socket/libNativeThread.c(26): fatal error 
C1083: Cannot open include file: 'pthread.h': No such file or directory
[2020-06-29T15:26:17,743Z]    ... (rest of output omitted)

I'll suggest to put the content of the native file under:

#ifndef _WIN32

or maybe

#ifndef _WINDOWS

You can probably use the `submit` repo to verify that there is no
build break.

> I gave a thought on creating a separate thread and sending a signal but 
> it will further increase the complexity of the test. If tests send 
> signals in separate threads? then? tests have to make sure that server 
> thread is alive and running.

You can probably send from the main thread - just bail out if the
server has closed ?

while (!ss.isClosed() && i < 20) {
    ... send SIGPIPE and sleep  10ms ...
}

best regards,

-- daniel

> 
> Thanks,
> Vyom


From aph at redhat.com  Mon Jun 29 17:34:19 2020
From: aph at redhat.com (Andrew Haley)
Date: Mon, 29 Jun 2020 18:34:19 +0100
Subject: [8u] RFR(m): 8194298: Add support for per Socket configuration of
 TCP keepalive
In-Reply-To: <26e51ac19f9e9fc445d95f4180bf5da5e3b32c87.camel@redhat.com>
References: <d3692fd45bce49b5ad51ce1078ffbb345d495d03.camel@redhat.com>
 <AM6PR03MB4389EFA46B30CEA78F11B6D8FF920@AM6PR03MB4389.eurprd03.prod.outlook.com>
 <21064bd9028fa4b1f0185c05df948217f857e4cc.camel@redhat.com>
 <CAKysZ8ymRs+_rJ_RL_NWJjft3SKRXrA42Ln7H2q6obzad9M5Yg@mail.gmail.com>
 <0b4b7b2859a10cd36dd6f0f1083a92dd7f52ba06.camel@redhat.com>
 <CAKysZ8w+EuN-AobuRmk+qbPA+AVCLoPE-T+BDYEvM3FEMvN-fw@mail.gmail.com>
 <d7c288c3acfe4549fd5abea69d8608eb17429379.camel@redhat.com>
 <CAKysZ8wR7v79Z54NctSntVyHSRH09CkPa9cOjyRegQL7Q0jh-Q@mail.gmail.com>
 <26e51ac19f9e9fc445d95f4180bf5da5e3b32c87.camel@redhat.com>
Message-ID: <d1294037-8b96-6c01-a563-75ae75a6ce63@redhat.com>

On 29/06/2020 17:06, Severin Gehwolf wrote:
> It's a possibility. IMHO, it doesn't really make the code easier to
> read, though. Some duplication for clarity seems OK to me in this case.
> I'm not too fond of over-use of ifdef so I'd rather keep it at v5.
> YMMV.

OK.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From amy.lu at oracle.com  Tue Jun 30 04:06:32 2020
From: amy.lu at oracle.com (Amy Lu)
Date: Tue, 30 Jun 2020 12:06:32 +0800
Subject: 8246114: java/net/MulticastSocket/Promiscuous.java fails after
 8241072 (multi-homed systems)
In-Reply-To: <a84da600-72c1-f51b-de8d-bbe166b61b49@oracle.com>
References: <299ea391-b022-4901-ea34-c7bafba3cbce@oracle.com>
 <47f30a58-4667-36e6-295b-f3db3dbd1fa8@oracle.com>
 <a84da600-72c1-f51b-de8d-bbe166b61b49@oracle.com>
Message-ID: <1abac635-7590-c200-08bb-81cdeea3624f@oracle.com>

On 6/29/20 11:01 PM, Daniel Fuchs wrote:
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8246114/webrev.01/
>

Looks good. (And I verified the fix on the system where issue reproducible.)

Thank you Daniel!

Thanks,
Amy

From vyommani at gmail.com  Tue Jun 30 05:39:45 2020
From: vyommani at gmail.com (Vyom Tiwari)
Date: Tue, 30 Jun 2020 11:09:45 +0530
Subject: RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR
 incorrectly
In-Reply-To: <6462be23-71b5-f04a-f289-abc77560f633@oracle.com>
References: <eb820990-538f-6462-83f1-00db9c5addb9@oracle.com>
 <CAKysZ8yw=7kbG+THEKEi3DY3RoeS55tt=-zP0PfZXqeg4inz8w@mail.gmail.com>
 <242fe9b7-b9bc-03b9-0f5e-b0d01775fb64@oracle.com>
 <CAKysZ8z725FrYLcfrj5muD-AfAPda6nyksyXMVJrMM4475MzHw@mail.gmail.com>
 <CAKysZ8zX44bGfHqXUXX4GXTr04-oA-BPSU5gwmKU_x=t7-=Dow@mail.gmail.com>
 <655d84a0-648a-8217-99da-df87b16b7251@oracle.com>
 <CAKysZ8xeEAi60JN6hq+yO0==cfPvwDrPmi=+45h8VeaVS82rKA@mail.gmail.com>
 <540969d4-62a3-a74f-273d-95354b956ca1@oracle.com>
 <CAKysZ8xODBi_hdpObpqrnFcDYGADfBR2OqXUGnNPp-RuuVxJmA@mail.gmail.com>
 <f89ad3f8-8bfa-87c4-69cc-3b0d98a0dd1d@oracle.com>
 <CAKysZ8xSi8PR0ZxVt4-uM6UZngCqStRJkUmSr97ZUd1BHBDvhw@mail.gmail.com>
 <CAKysZ8wiRZErb6m9sR3+JUAvktMC7P8F_uJoaOnfwx+WSA-2TQ@mail.gmail.com>
 <aa1f3bc4-9f34-f663-c433-1e37de771ee5@oracle.com>
 <CAKysZ8whWMcWxOhr7dq_0U7xD=H71umvQ9mLqn1j8dc011TFkQ@mail.gmail.com>
 <CAKysZ8yLGVWGaFZh+ZP-b93aMyCudVyQ6jqp5CE8gM3EG7mU=Q@mail.gmail.com>
 <6462be23-71b5-f04a-f289-abc77560f633@oracle.com>
Message-ID: <CAKysZ8zq4FR+wRJoC4FbO2BSVqiZOQhSE9=zc1kSFWta5q-qqQ@mail.gmail.com>

Hi Daniel,

Thanks for review please find the latest webrev(
http://cr.openjdk.java.net/~vtewari/8237858/webrev0.8/index.html). I fixed
the Windows build issue.

Thanks,
Vyom

On Mon, Jun 29, 2020 at 10:23 PM Daniel Fuchs <daniel.fuchs at oracle.com>
wrote:

> Hi Vyom,
>
>
> On 29/06/2020 08:03, Vyom Tiwari wrote:
> > Hi Alan,Daniel,
> >
> > Please find the latest
> > webrev(http://cr.openjdk.java.net/~vtewari/8237858/webrev0.7/index.html).
> I
> > have added a new native method and removed the hardcoding(SIGPIPE).
>
> That fails to build on windows:
>
> [2020-06-29T15:26:16,899Z] ERROR: Build failed for target 'default
> (product-bundles test-bundles static-libs-bundles)' in configuration
> 'windows-x64' (exit code 2)
> [2020-06-29T15:26:17,587Z] * For target
> support_test_jdk_jtreg_native_support_libNativeThread_libNativeThread.obj:
> [2020-06-29T15:26:17,649Z] libNativeThread.c
> [2020-06-29T15:26:17,649Z]
> ./open/test/jdk/java/net/Socket/libNativeThread.c(26): fatal error
> C1083: Cannot open include file: 'pthread.h': No such file or directory
> [2020-06-29T15:26:17,743Z]    ... (rest of output omitted)
>
> I'll suggest to put the content of the native file under:
>
> #ifndef _WIN32
>
> or maybe
>
> #ifndef _WINDOWS
>
> You can probably use the `submit` repo to verify that there is no
> build break.
>
> > I gave a thought on creating a separate thread and sending a signal but
> > it will further increase the complexity of the test. If tests send
> > signals in separate threads  then  tests have to make sure that server
> > thread is alive and running.
>
> You can probably send from the main thread - just bail out if the
> server has closed ?
>
> while (!ss.isClosed() && i < 20) {
>     ... send SIGPIPE and sleep  10ms ...
> }
>
> best regards,
>
> -- daniel
>
> >
> > Thanks,
> > Vyom
>
>

-- 
Thanks,
Vyom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200630/41fe9e5c/attachment.htm>

From joshdgreene at protonmail.com  Tue Jun 30 18:24:46 2020
From: joshdgreene at protonmail.com (joshdgreene)
Date: Tue, 30 Jun 2020 18:24:46 +0000
Subject: 8028776: Java socks proxy to resolve DNS remotely
Message-ID: <_UyUE6_JeIzNAjelPXhCccyjNigB6jijnit7_xJ__l9-aUSVSJCqX8ihGo6Gi5u3U3BK9AuvEvUs6Y4S77ztkDJPlsOq_7L8n64UNkKb5C4=@protonmail.com>

Hello,

I would like to work on bug 8028776: Java socks proxy to resolve DNS remotely, and did an analysis of the current java.net code.

After calling url.openConnection(proxy).getInputStream(), DNS resolution takes place when a new InetSocketAddress is created in NetworkClient.java lines 176-184:

if (connectTimeout >= 0) {
s.connect(new InetSocketAddress(server, port), connectTimeout);
} else {
if (defaultConnectTimeout > 0) {
s.connect(new InetSocketAddress(server, port), defaultConnectTimeout);
} else {
s.connect(new InetSocketAddress(server, port));
}
}

As you can see, in three cases a new InetSocketAddress is created, and this constructor resolves the domain name.
My First idea was to get an unresolved InetSocketAddress when SOCKS was used:

InetSocketAddress targetAddress = proxy.type() == Proxy.Type.SOCKS ?
InetSocketAddress.createUnresolved(server, port) :
new InetSocketAddress(server, port);

if (connectTimeout >= 0) {
s.connect(targetAddress, connectTimeout);
} else {
if (defaultConnectTimeout > 0) {
s.connect(targetAddress, defaultConnectTimeout);
} else {
s.connect(targetAddress);
}
}

Then, SocksSocketImpl just had to send the domain name for unresolved endpoints. Luckily, this has already been implemented in SocksSocketImpl.java, lines 416-421:

if (epoint.isUnresolved()) {
out.write(DOMAIN_NAME);
out.write(epoint.getHostName().length());
out.write(epoint.getHostName().getBytes(StandardCharsets.ISO_8859_1));
out.write((epoint.getPort() >> 8) & 0xff);
out.write((epoint.getPort() >> 0) & 0xff);

While this works flawlessly for SOCKS v5 proxies, this won't work for SOCKS v4. Proxying DNS is not possible with SOCKS v4, so DNS should still be resolved for SOCKS v4. Unfortunately, there are several caveats:

* While the SocksProxy class has a protocolVersion property, this property cannot be read at the location of the change above, because URL.openConnection creates a new Proxy of type ApplicationProxy. According to the comment, this is as a security measure. This copy is not a full copy, because it lacks the SocksProxy protocolVersion property.
* SocksSocketImpl.useV4 (which determines whether to use v4 or v5) does not only check the proxy type (which AFAIK never is SocksProxy), but also DefaultProxySelector.socksProxyVersion() == 4 (line 74). While convenient, there could be a difference between the socksProxyVersion in the SocksProxy object that was originally created, and the version in the system property (even though the SocksProxy property cannot currently be set programmatically).
* The change in NetworkClient.java above could use the same trick, to check DefaultProxySelector.socksProxyVersion(). However, lines 397-406 prevent this. Starting at line 389:

// This is SOCKS V5
out.write(PROTO_VERS);
out.write(2);
out.write(NO_AUTH);
out.write(USER_PASSW);
out.flush();
byte[] data = new byte[2];
int i = readSocksReply(in, data, deadlineMillis);
if (i != 2 || ((int)data[0]) != PROTO_VERS) {
// Maybe it's not a V5 sever after all
// Let's try V4 before we give up
// SOCKS Protocol version 4 doesn't know how to deal with
// DOMAIN type of addresses (unresolved addresses here)
if (epoint.isUnresolved())
throw new UnknownHostException(epoint.toString());
connectV4(in, out, epoint, deadlineMillis);
return;
}

So even if SOCKS v5 is configured, SocksSocketImpl tries v4 if v5 fails, and then v4 will always fail because the address is unresolved. The fallback from v5 to v4 breaks the first idea.

Before I found out that the proxy object was changed into an ApplicationProxy object, I thought about adding a 'proxyDns' property to the SocksProxy class. When this property would be explicitly set to true, proxying DNS is expected, so SOCKS v5 is mandatory. In this case, it wouldn't matter if the fallback would throw an exception. However, the SocksProxy information disappears in the ApplicationProxy copy, and as far as I see, there is no easy way to create a SocksProxy with the right version and a new property from code, without using system properties and the ProxySelector. Maybe a ProxyFactory could help out, but such a class does not exist.

Currently, the version of SOCKS can only be set in system property socksProxyVersion. We could introduce a new system property socksProxyDns, which tells NetworkClient to proxy DNS when using SOCKS, like this:

private static final String SOCKS_PROXY_DNS = "socksProxyDns";
public static boolean socksProxyDns() {
Boolean val = AccessController.doPrivileged(
new PrivilegedAction<Boolean>() {
@Override public Boolean run() {
return NetProperties.getBoolean(SOCKS_PROXY_DNS);
}
});
return val == null ? false : val;
}

Again, NetworkClient.java lines 176-184, now checking the new property:

InetSocketAddress targetAddress = proxy.type() == Proxy.Type.SOCKS && socksProxyDns() ?
InetSocketAddress.createUnresolved(server, port) :
new InetSocketAddress(server, port);

if (connectTimeout >= 0) {
s.connect(targetAddress, connectTimeout);
} else {
if (defaultConnectTimeout > 0) {
s.connect(targetAddress, defaultConnectTimeout);
} else {
s.connect(targetAddress);
}
}

This works, and compatibility-wise, I think this is almost risk free. But from an application programmer's point of view, I'd prefer a way to specify the SOCKS version and DNS proxying in type safe code instead of a system property.

What would be the preferred solution? What can I do next?

I already prepared some jtreg tests to test the proxy (SOCKS protocol is very easy to test). However, I'd like to guarantee that no local DNS query is made when SOCKS v5 with DNS proxying is enabled, and that a local DNS query is made when DNS proxying is not enabled. Unfortunately, I didn't find a clean way to replace the default NameService implementation. I tested this with a NetworkService class implementing an InvocationHandler, which I assigned to the static nameService property of InetAddress. Even though this currently works, it may not work in a future release:

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access to field java.net.InetAddress.nameService
WARNING: Please consider reporting this to the maintainers of this class
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

Does anyone have any suggestions to replace the NameService in test code?

-Josh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200630/c8030ead/attachment-0001.htm>