From goetz.lindenmaier at sap.com Fri Oct 6 06:48:11 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 6 Oct 2017 06:48:11 +0000 Subject: RFR(XS): 8188855: Fix VS10 build after "8187658: Bigger buffer for GetAdaptersAddresses" Message-ID: <7c7b1caa2cd64f40bdb6a0f19ac45d14@sap.com> Hi, could I please get reviews for this tiny change? http://cr.openjdk.java.net/~goetz/wr17/8188855-winBuild/webrev/ Best regards, Goetz. From vyom.tewari at oracle.com Fri Oct 6 08:12:44 2017 From: vyom.tewari at oracle.com (vyom tewari) Date: Fri, 6 Oct 2017 13:42:44 +0530 Subject: RFR(XS): 8188855: Fix VS10 build after "8187658: Bigger buffer for GetAdaptersAddresses" In-Reply-To: <7c7b1caa2cd64f40bdb6a0f19ac45d14@sap.com> References: <7c7b1caa2cd64f40bdb6a0f19ac45d14@sap.com> Message-ID: <550f4518-0738-629b-6a6b-5047c679874a@oracle.com> Hi Goetz, Change looks OK to me, although i am not the official reviewer. Thanks, Vyom On Friday 06 October 2017 12:18 PM, Lindenmaier, Goetz wrote: > Hi, > > could I please get reviews for this tiny change? > http://cr.openjdk.java.net/~goetz/wr17/8188855-winBuild/webrev/ > > Best regards, > Goetz. From volker.simonis at gmail.com Fri Oct 6 08:31:21 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 6 Oct 2017 10:31:21 +0200 Subject: RFR(XS): 8188855: Fix VS10 build after "8187658: Bigger buffer for GetAdaptersAddresses" In-Reply-To: <7c7b1caa2cd64f40bdb6a0f19ac45d14@sap.com> References: <7c7b1caa2cd64f40bdb6a0f19ac45d14@sap.com> Message-ID: Looks good! Thanks, Volker On Fri, Oct 6, 2017 at 8:48 AM, Lindenmaier, Goetz wrote: > Hi, > > could I please get reviews for this tiny change? > http://cr.openjdk.java.net/~goetz/wr17/8188855-winBuild/webrev/ > > Best regards, > Goetz. From goetz.lindenmaier at sap.com Fri Oct 6 09:15:21 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 6 Oct 2017 09:15:21 +0000 Subject: RFR(XS): 8188855: Fix VS10 build after "8187658: Bigger buffer for GetAdaptersAddresses" In-Reply-To: References: <7c7b1caa2cd64f40bdb6a0f19ac45d14@sap.com> Message-ID: <925fe08890cd4f52ab2ab556062bc856@sap.com> Thanks, volker! Best regards, Goetz > -----Original Message----- > From: Volker Simonis [mailto:volker.simonis at gmail.com] > Sent: Freitag, 6. Oktober 2017 10:31 > To: Lindenmaier, Goetz > Cc: net-dev at openjdk.java.net > Subject: Re: RFR(XS): 8188855: Fix VS10 build after "8187658: Bigger buffer for > GetAdaptersAddresses" > > Looks good! > > Thanks, > Volker > > > On Fri, Oct 6, 2017 at 8:48 AM, Lindenmaier, Goetz > wrote: > > Hi, > > > > could I please get reviews for this tiny change? > > http://cr.openjdk.java.net/~goetz/wr17/8188855-winBuild/webrev/ > > > > Best regards, > > Goetz. From goetz.lindenmaier at sap.com Fri Oct 6 09:15:51 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 6 Oct 2017 09:15:51 +0000 Subject: RFR(XS): 8188855: Fix VS10 build after "8187658: Bigger buffer for GetAdaptersAddresses" In-Reply-To: <550f4518-0738-629b-6a6b-5047c679874a@oracle.com> References: <7c7b1caa2cd64f40bdb6a0f19ac45d14@sap.com> <550f4518-0738-629b-6a6b-5047c679874a@oracle.com> Message-ID: <0cc9d28ae99c4af8b75e9b3be44ebc67@sap.com> Thanks, Vyom! Best regards, Goetz. > -----Original Message----- > From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of > vyom tewari > Sent: Freitag, 6. Oktober 2017 10:13 > To: net-dev at openjdk.java.net > Subject: Re: RFR(XS): 8188855: Fix VS10 build after "8187658: Bigger buffer for > GetAdaptersAddresses" > > Hi Goetz, > > Change looks OK to me, although i am not the official reviewer. > > Thanks, > > Vyom > > > On Friday 06 October 2017 12:18 PM, Lindenmaier, Goetz wrote: > > Hi, > > > > could I please get reviews for this tiny change? > > http://cr.openjdk.java.net/~goetz/wr17/8188855-winBuild/webrev/ > > > > Best regards, > > Goetz. From chris.hegarty at oracle.com Tue Oct 10 18:58:28 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 10 Oct 2017 19:58:28 +0100 Subject: RFR 8145635 : Add TCP_QUICKACK socket option In-Reply-To: <82e35025-cd86-5119-3556-f0989eb3a785@oracle.com> References: <56CD74E1.60309@oracle.com> <56CD7C0A.2080402@oracle.com> <0b0989b5-c791-a476-a82f-6c686b19c9d3@oracle.com> <54CDCFD4-97F5-480C-A4D9-03CEA58803B5@oracle.com> <82e35025-cd86-5119-3556-f0989eb3a785@oracle.com> Message-ID: Vyom, What about suggestion 1) below, the name of the socket option? -Chris. > On 27 Sep 2017, at 09:56, vyom tewari wrote: > > Hi Chris, > > Thanks for review, please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8145635/webrev0.2/index.html). I incorporated review comments from you and re-base the patch to our consolidated repo(jdk10/master). > > Thanks, > > Vyom > > > On Monday 25 September 2017 01:57 AM, Chris Hegarty wrote: >> Vyom, >> >>> On 11 Sep 2017, at 16:38, vyom tewari wrote: >>> >>> Hi All, >>> >>> As jdk.net API already moved out of java.base, Please review the below code change for jdk10. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145635 >>> Webrev: http://cr.openjdk.java.net/~vtewari/8145635/webrev0.1/index.html >>> >> This looks quite good. Some comments: >> >> 1) I wonder if we should just call the option TCP_QUICKACK, rather than SO_QUICKACK? Similar to TCP_NODELAY. >> >> 2) I think LinuxSocketOptions.h is largely unnecessary, if we do 1) above. >> >> 3) Java_jdk_net_LinuxSocketOptions_getQuickAck could return jint, rather than jobject, thus avoiding the need for createBoolean. The conversation can happen in the Java layer. Can you please reduce the lint length in this file, by wrapping similar to the style of the Solaris version. >> >> 4) ExtendedSocketOptions.java >> - drop the

, they are unnecessary. >> - I think, similar to TCP_NODELAY, the spec should say that the options is TCP specific. From TCP_NODELAY: "The socket option is specific to stream-oriented sockets using the TCP/IP protocol.? >> - "In TCP_QUICKACK mode?, maybe ?When the option is enabled?? >> >> -Chris. >> >> > From vyom.tewari at oracle.com Wed Oct 11 09:43:37 2017 From: vyom.tewari at oracle.com (vyom tewari) Date: Wed, 11 Oct 2017 15:13:37 +0530 Subject: RFR 8145635 : Add TCP_QUICKACK socket option In-Reply-To: References: <56CD74E1.60309@oracle.com> <56CD7C0A.2080402@oracle.com> <0b0989b5-c791-a476-a82f-6c686b19c9d3@oracle.com> <54CDCFD4-97F5-480C-A4D9-03CEA58803B5@oracle.com> <82e35025-cd86-5119-3556-f0989eb3a785@oracle.com> Message-ID: <21b6170f-67e8-b00b-a5a4-81939a8c74ec@oracle.com> Hi Chris, On Wednesday 11 October 2017 12:28 AM, Chris Hegarty wrote: > Vyom, > > What about suggestion 1) below, the name of the socket option? to be consistent with SO_FLOW_SLA in ExtendedSocketOptions.java, i choose the "SO" prefix. But I don't know the history behind the "SO" prefix? so i changed the socket option name to "TCP_QUICKACK" as suggested. Please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8145635/webrev0.3/index.html). Thanks, Vyom > > -Chris. > >> On 27 Sep 2017, at 09:56, vyom tewari wrote: >> >> Hi Chris, >> >> Thanks for review, please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8145635/webrev0.2/index.html). I incorporated review comments from you and re-base the patch to our consolidated repo(jdk10/master). >> >> Thanks, >> >> Vyom >> >> >> On Monday 25 September 2017 01:57 AM, Chris Hegarty wrote: >>> Vyom, >>> >>>> On 11 Sep 2017, at 16:38, vyom tewari wrote: >>>> >>>> Hi All, >>>> >>>> As jdk.net API already moved out of java.base, Please review the below code change for jdk10. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145635 >>>> Webrev: http://cr.openjdk.java.net/~vtewari/8145635/webrev0.1/index.html >>>> >>> This looks quite good. Some comments: >>> >>> 1) I wonder if we should just call the option TCP_QUICKACK, rather than SO_QUICKACK? Similar to TCP_NODELAY. >>> >>> 2) I think LinuxSocketOptions.h is largely unnecessary, if we do 1) above. >>> >>> 3) Java_jdk_net_LinuxSocketOptions_getQuickAck could return jint, rather than jobject, thus avoiding the need for createBoolean. The conversation can happen in the Java layer. Can you please reduce the lint length in this file, by wrapping similar to the style of the Solaris version. >>> >>> 4) ExtendedSocketOptions.java >>> - drop the

, they are unnecessary. >>> - I think, similar to TCP_NODELAY, the spec should say that the options is TCP specific. From TCP_NODELAY: "The socket option is specific to stream-oriented sockets using the TCP/IP protocol.? >>> - "In TCP_QUICKACK mode?, maybe ?When the option is enabled?? >>> >>> -Chris. >>> >>> From chris.hegarty at oracle.com Wed Oct 11 20:08:35 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 11 Oct 2017 21:08:35 +0100 Subject: RFR 8145635 : Add TCP_QUICKACK socket option In-Reply-To: <21b6170f-67e8-b00b-a5a4-81939a8c74ec@oracle.com> References: <56CD74E1.60309@oracle.com> <56CD7C0A.2080402@oracle.com> <0b0989b5-c791-a476-a82f-6c686b19c9d3@oracle.com> <54CDCFD4-97F5-480C-A4D9-03CEA58803B5@oracle.com> <82e35025-cd86-5119-3556-f0989eb3a785@oracle.com> <21b6170f-67e8-b00b-a5a4-81939a8c74ec@oracle.com> Message-ID: <3F1588ED-715D-44A0-A89C-A006916EFA0A@oracle.com> > On 11 Oct 2017, at 10:43, vyom tewari wrote: > > Hi Chris, > > > On Wednesday 11 October 2017 12:28 AM, Chris Hegarty wrote: >> Vyom, >> >> What about suggestion 1) below, the name of the socket option? > to be consistent with SO_FLOW_SLA in ExtendedSocketOptions.java, i choose the "SO" prefix. But I don't know the history behind the "SO" prefix so i changed the socket option name to "TCP_QUICKACK" as suggested. Given that this option is specific to TCP, then the `TCP_` prefix is more appropriate. -Chris. From Alan.Bateman at oracle.com Thu Oct 12 07:15:45 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 12 Oct 2017 08:15:45 +0100 Subject: RFR 8145635 : Add TCP_QUICKACK socket option In-Reply-To: <3F1588ED-715D-44A0-A89C-A006916EFA0A@oracle.com> References: <56CD74E1.60309@oracle.com> <56CD7C0A.2080402@oracle.com> <0b0989b5-c791-a476-a82f-6c686b19c9d3@oracle.com> <54CDCFD4-97F5-480C-A4D9-03CEA58803B5@oracle.com> <82e35025-cd86-5119-3556-f0989eb3a785@oracle.com> <21b6170f-67e8-b00b-a5a4-81939a8c74ec@oracle.com> <3F1588ED-715D-44A0-A89C-A006916EFA0A@oracle.com> Message-ID: On 11/10/2017 21:08, Chris Hegarty wrote: > > Given that this option is specific to TCP, then the `TCP_` prefix is more appropriate. > I agree. We have StandardSocketOptions.TCP_NODELAY as an example to look at. -Alan From vyom.tewari at oracle.com Thu Oct 12 12:51:35 2017 From: vyom.tewari at oracle.com (vyom tewari) Date: Thu, 12 Oct 2017 18:21:35 +0530 Subject: RFR 8145635 : Add TCP_QUICKACK socket option In-Reply-To: <42980dc4-3138-d05f-f481-934785c7d843@oracle.com> References: <56CD74E1.60309@oracle.com> <56CD7C0A.2080402@oracle.com> <0b0989b5-c791-a476-a82f-6c686b19c9d3@oracle.com> <54CDCFD4-97F5-480C-A4D9-03CEA58803B5@oracle.com> <82e35025-cd86-5119-3556-f0989eb3a785@oracle.com> <81600a54-f514-8a47-e719-10864f59f612@oracle.com> <42980dc4-3138-d05f-f481-934785c7d843@oracle.com> Message-ID: <741425b7-f5fa-55ab-2aaf-c3208bb20768@oracle.com> Hi Alan, thanks for pointing out, i am forwarding it to net-dev list. Vyom On Thursday 12 October 2017 03:54 PM, Alan Bateman wrote: > Best to reply on net-dev as that is where the main review should be > going on (seems there are at two review threads going, maybe they > could unite on net-dev). > > > On 12/10/2017 10:01, vyom tewari wrote: >> Hi Roger, >> >> Thanks for the review, i incorporated all review comments from you >> except("you can use ExtendedSocketOptions.TCP_QUICKACK to check for >> the option to omit without >> ?embedding the name."). ExtendedSocketOptions.java is part of >> "jdk.net"? so we can not directly use it in java.base, hence i used >> the option name to filter "TCP_QUICKACK". >> >> Please find the update >> webrev(http://cr.openjdk.java.net/~vtewari/8145635/webrev0.4/index.html). >> >> Thanks, >> >> Vyom >> >> >> On Wednesday 11 October 2017 08:46 PM, Roger Riggs wrote: >>> Hi Vyom, >>> >>> Comments: >>> >>> ?- update copyright >>> ?- use @since 18.3 instead of @since 10 >>> >>> - ExtendedSocketOptions.java: 265,269? include the "TCP_QUICKACK" in >>> the exception messages. >>> >>> ??? Line 144: if you are going to keep the assert, add a explanation >>> about how it could happen. >>> ??? I'd remove the assert. >>> >>> ?- The first sentence should be a complete sentence: "TCP_QUICKACK >>> socket option enables sending TCP/IP acks immediately" or similar. >>> >>> ?- A reference to the appropriate TCP/IP spec for quickack would be >>> a good addition. At least the RFC # and section. >>> ?- 85: space after "."? The phrasing is a bit odd in places in the >>> javadoc. >>> ?- line 81/82 the value is true to enable and false to disable. >>> ?- This phrase is confusing: "it only enables a switch to or from >>> TCP_QUICKACK mode"; >>> ?? Since it is set on a socket, it should remain set on that socket >>> until it is changed. >>> >>> ?- 203: be consistent in using enable/disable in parameters, etc >>> even for private methods. >>> ??? "on" -> "enable" >>> >>> PlainDatagramSocketImpl: 89: >>> ? Why create a new set with zero or one items just to throw it away? >>> ? Use the iterator to add only the non-TCP_QUICKACK options to the >>> supported options. >>> ?Also, you can use ExtendedSocketOptions.TCP_QUICKACK to check for >>> the option to omit without >>> ?embedding the name. >>> >>> >>> Sockets.java: >>> ? - The initialization of isQuickAckAvailable might be cleaner as an >>> nested static class >>> ??? that initializes the value in its static initializer. That would >>> delay the init til needed >>> ??? and avoid extra flags. >>> >>> LinuxSocketOptions.java: >>> ?? - the native methods should be static; since the instance is unused. >>> >>> ?- line 41: the return type should be Boolean >>> >>> ?- line 46: the return type of getQuickAck0 should be Boolean like >>> the argument to set. >>> >>> ?- line 34:? using JNU_ThrowByNameWithLastError directly is >>> sufficient; if the errno does not have a string unix supplies >>> "unknown error nnn". >>> >>> >>> Regards, Roger >>> >>> On 10/10/2017 2:58 PM, Chris Hegarty wrote: >>>> Vyom, >>>> >>>> What about suggestion 1) below, the name of the socket option? >>>> >>>> -Chris. >>>> >>>>> On 27 Sep 2017, at 09:56, vyom tewari wrote: >>>>> >>>>> Hi Chris, >>>>> >>>>> Thanks for review, please find the latest >>>>> webrev(http://cr.openjdk.java.net/~vtewari/8145635/webrev0.2/index.html). >>>>> I incorporated review comments from you and re-base the patch to >>>>> our consolidated repo(jdk10/master). >>>>> >>>>> Thanks, >>>>> >>>>> Vyom >>>>> >>>>> >>>>> On Monday 25 September 2017 01:57 AM, Chris Hegarty wrote: >>>>>> Vyom, >>>>>> >>>>>>> On 11 Sep 2017, at 16:38, vyom tewari >>>>>>> wrote: >>>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> As jdk.net API already moved out of java.base, Please review the >>>>>>> below code change for jdk10. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145635 >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~vtewari/8145635/webrev0.1/index.html >>>>>>> >>>>>> This looks quite good. Some comments: >>>>>> >>>>>> 1) I wonder if we should just call the option TCP_QUICKACK, >>>>>> rather than SO_QUICKACK? Similar to TCP_NODELAY. >>>>>> >>>>>> 2) I think LinuxSocketOptions.h is largely unnecessary, if we do >>>>>> 1) above. >>>>>> >>>>>> 3) Java_jdk_net_LinuxSocketOptions_getQuickAck could return jint, >>>>>> rather than jobject, thus avoiding the need for createBoolean. >>>>>> The conversation can happen in the Java layer.? Can you please >>>>>> reduce the lint length in this file, by wrapping similar to the >>>>>> style of the Solaris version. >>>>>> >>>>>> 4) ExtendedSocketOptions.java >>>>>> ?? - drop the

, they are unnecessary. >>>>>> ?? - I think, similar to TCP_NODELAY, the spec should say that >>>>>> the options is TCP specific. From TCP_NODELAY: "The socket option >>>>>> is specific to stream-oriented sockets using the TCP/IP protocol.? >>>>>> ?? - "In TCP_QUICKACK mode?, maybe ?When the option is enabled?? >>>>>> >>>>>> -Chris. >>>>>> >>>>>> >>> >> > From chris.hegarty at oracle.com Fri Oct 13 20:55:43 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 13 Oct 2017 21:55:43 +0100 Subject: RFR 8145635 : Add TCP_QUICKACK socket option In-Reply-To: <81600a54-f514-8a47-e719-10864f59f612@oracle.com> References: <56CD74E1.60309@oracle.com> <56CD7C0A.2080402@oracle.com> <0b0989b5-c791-a476-a82f-6c686b19c9d3@oracle.com> <54CDCFD4-97F5-480C-A4D9-03CEA58803B5@oracle.com> <82e35025-cd86-5119-3556-f0989eb3a785@oracle.com> <81600a54-f514-8a47-e719-10864f59f612@oracle.com> Message-ID: <7F57E4CA-5A33-46C5-AA44-A739B3D7BA10@oracle.com> Vyom, > On 12 Oct 2017, at 10:01, vyom tewari wrote: > > Hi Roger, > > Thanks for the review, i incorporated all review comments from you except("you can use ExtendedSocketOptions.TCP_QUICKACK to check for the option to omit without > embedding the name."). ExtendedSocketOptions.java is part of "jdk.net" so we can not directly use it in java.base, hence i used the option name to filter "TCP_QUICKACK". > > Please find the update webrev(http://cr.openjdk.java.net/~vtewari/8145635/webrev0.4/index.html). This looks much better. Some suggested wordings of the JDK-specific option: /** * Disable Delayed Acknowledgements. * *

This socket option can be used to reduce or disable delayed * acknowledgments (ACKs). * *

The value of this socket option is a {@code Boolean} that represents * whether the option is enabled or disabled. The socket option is specific * to stream-oriented sockets using the TCP/IP protocol. * *

The exact semantics of this socket option are socket type and system * dependent. * *

When TCP_QUICKACK is enabled, ACKs are sent immediately, rather than * delayed if needed in accordance to normal TCP operation. This option is * not permanent, it only enables a switch to or from TCP_QUICKACK mode. * *

Subsequent operations of the TCP protocol will once again enter/leave * TCP_QUICKACK mode depending on internal protocol processing and factors * such as delayed ack timeouts occurring and data transfer. * * @since 18.3 */ -Chris. P.S. D?oh, sorry, of course you need the paragraph tags. > Thanks, > > Vyom > > > On Wednesday 11 October 2017 08:46 PM, Roger Riggs wrote: >> Hi Vyom, >> >> Comments: >> >> - update copyright >> - use @since 18.3 instead of @since 10 >> >> - ExtendedSocketOptions.java: 265,269 include the "TCP_QUICKACK" in the exception messages. >> >> Line 144: if you are going to keep the assert, add a explanation about how it could happen. >> I'd remove the assert. >> >> - The first sentence should be a complete sentence: "TCP_QUICKACK socket option enables sending TCP/IP acks immediately" or similar. >> >> - A reference to the appropriate TCP/IP spec for quickack would be a good addition. At least the RFC # and section. >> - 85: space after "." The phrasing is a bit odd in places in the javadoc. >> - line 81/82 the value is true to enable and false to disable. >> - This phrase is confusing: "it only enables a switch to or from TCP_QUICKACK mode"; >> Since it is set on a socket, it should remain set on that socket until it is changed. >> >> - 203: be consistent in using enable/disable in parameters, etc even for private methods. >> "on" -> "enable" >> >> PlainDatagramSocketImpl: 89: >> Why create a new set with zero or one items just to throw it away? >> Use the iterator to add only the non-TCP_QUICKACK options to the supported options. >> Also, you can use ExtendedSocketOptions.TCP_QUICKACK to check for the option to omit without >> embedding the name. >> >> >> Sockets.java: >> - The initialization of isQuickAckAvailable might be cleaner as an nested static class >> that initializes the value in its static initializer. That would delay the init til needed >> and avoid extra flags. >> >> LinuxSocketOptions.java: >> - the native methods should be static; since the instance is unused. >> >> - line 41: the return type should be Boolean >> >> - line 46: the return type of getQuickAck0 should be Boolean like the argument to set. >> >> - line 34: using JNU_ThrowByNameWithLastError directly is sufficient; if the errno does not have a string unix supplies "unknown error nnn". >> >> >> Regards, Roger >> >> On 10/10/2017 2:58 PM, Chris Hegarty wrote: >>> Vyom, >>> >>> What about suggestion 1) below, the name of the socket option? >>> >>> -Chris. >>> >>>> On 27 Sep 2017, at 09:56, vyom tewari wrote: >>>> >>>> Hi Chris, >>>> >>>> Thanks for review, please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8145635/webrev0.2/index.html). I incorporated review comments from you and re-base the patch to our consolidated repo(jdk10/master). >>>> >>>> Thanks, >>>> >>>> Vyom >>>> >>>> >>>> On Monday 25 September 2017 01:57 AM, Chris Hegarty wrote: >>>>> Vyom, >>>>> >>>>>> On 11 Sep 2017, at 16:38, vyom tewari wrote: >>>>>> >>>>>> Hi All, >>>>>> >>>>>> As jdk.net API already moved out of java.base, Please review the below code change for jdk10. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145635 >>>>>> Webrev: http://cr.openjdk.java.net/~vtewari/8145635/webrev0.1/index.html >>>>>> >>>>> This looks quite good. Some comments: >>>>> >>>>> 1) I wonder if we should just call the option TCP_QUICKACK, rather than SO_QUICKACK? Similar to TCP_NODELAY. >>>>> >>>>> 2) I think LinuxSocketOptions.h is largely unnecessary, if we do 1) above. >>>>> >>>>> 3) Java_jdk_net_LinuxSocketOptions_getQuickAck could return jint, rather than jobject, thus avoiding the need for createBoolean. The conversation can happen in the Java layer. Can you please reduce the lint length in this file, by wrapping similar to the style of the Solaris version. >>>>> >>>>> 4) ExtendedSocketOptions.java >>>>> - drop the

, they are unnecessary. >>>>> - I think, similar to TCP_NODELAY, the spec should say that the options is TCP specific. From TCP_NODELAY: "The socket option is specific to stream-oriented sockets using the TCP/IP protocol.? >>>>> - "In TCP_QUICKACK mode?, maybe ?When the option is enabled?? >>>>> >>>>> -Chris. >>>>> >>>>> >> > From vyom.tewari at oracle.com Mon Oct 16 06:58:05 2017 From: vyom.tewari at oracle.com (vyom tewari) Date: Mon, 16 Oct 2017 12:28:05 +0530 Subject: RFR 8145635 : Add TCP_QUICKACK socket option In-Reply-To: <7F57E4CA-5A33-46C5-AA44-A739B3D7BA10@oracle.com> References: <56CD74E1.60309@oracle.com> <56CD7C0A.2080402@oracle.com> <0b0989b5-c791-a476-a82f-6c686b19c9d3@oracle.com> <54CDCFD4-97F5-480C-A4D9-03CEA58803B5@oracle.com> <82e35025-cd86-5119-3556-f0989eb3a785@oracle.com> <81600a54-f514-8a47-e719-10864f59f612@oracle.com> <7F57E4CA-5A33-46C5-AA44-A739B3D7BA10@oracle.com> Message-ID: <4ff68a2b-108b-293f-e498-ec81590e00db@oracle.com> Hi Chris, Thanks for review. Please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8145635/webrev0.5/index.html). Thanks, Vyom On Saturday 14 October 2017 02:25 AM, Chris Hegarty wrote: > Vyom, > >> On 12 Oct 2017, at 10:01, vyom tewari wrote: >> >> Hi Roger, >> >> Thanks for the review, i incorporated all review comments from you except("you can use ExtendedSocketOptions.TCP_QUICKACK to check for the option to omit without >> embedding the name."). ExtendedSocketOptions.java is part of "jdk.net" so we can not directly use it in java.base, hence i used the option name to filter "TCP_QUICKACK". >> >> Please find the update webrev(http://cr.openjdk.java.net/~vtewari/8145635/webrev0.4/index.html). > This looks much better. > > Some suggested wordings of the JDK-specific option: > > /** > * Disable Delayed Acknowledgements. > * > *

This socket option can be used to reduce or disable delayed > * acknowledgments (ACKs). > * > *

The value of this socket option is a {@code Boolean} that represents > * whether the option is enabled or disabled. The socket option is specific > * to stream-oriented sockets using the TCP/IP protocol. > * > *

The exact semantics of this socket option are socket type and system > * dependent. > * > *

When TCP_QUICKACK is enabled, ACKs are sent immediately, rather than > * delayed if needed in accordance to normal TCP operation. This option is > * not permanent, it only enables a switch to or from TCP_QUICKACK mode. > * > *

Subsequent operations of the TCP protocol will once again enter/leave > * TCP_QUICKACK mode depending on internal protocol processing and factors > * such as delayed ack timeouts occurring and data transfer. > * > * @since 18.3 > */ > > -Chris. > > P.S. D?oh, sorry, of course you need the paragraph tags. > > >> Thanks, >> >> Vyom >> >> >> On Wednesday 11 October 2017 08:46 PM, Roger Riggs wrote: >>> Hi Vyom, >>> >>> Comments: >>> >>> - update copyright >>> - use @since 18.3 instead of @since 10 >>> >>> - ExtendedSocketOptions.java: 265,269 include the "TCP_QUICKACK" in the exception messages. >>> >>> Line 144: if you are going to keep the assert, add a explanation about how it could happen. >>> I'd remove the assert. >>> >>> - The first sentence should be a complete sentence: "TCP_QUICKACK socket option enables sending TCP/IP acks immediately" or similar. >>> >>> - A reference to the appropriate TCP/IP spec for quickack would be a good addition. At least the RFC # and section. >>> - 85: space after "." The phrasing is a bit odd in places in the javadoc. >>> - line 81/82 the value is true to enable and false to disable. >>> - This phrase is confusing: "it only enables a switch to or from TCP_QUICKACK mode"; >>> Since it is set on a socket, it should remain set on that socket until it is changed. >>> >>> - 203: be consistent in using enable/disable in parameters, etc even for private methods. >>> "on" -> "enable" >>> >>> PlainDatagramSocketImpl: 89: >>> Why create a new set with zero or one items just to throw it away? >>> Use the iterator to add only the non-TCP_QUICKACK options to the supported options. >>> Also, you can use ExtendedSocketOptions.TCP_QUICKACK to check for the option to omit without >>> embedding the name. >>> >>> >>> Sockets.java: >>> - The initialization of isQuickAckAvailable might be cleaner as an nested static class >>> that initializes the value in its static initializer. That would delay the init til needed >>> and avoid extra flags. >>> >>> LinuxSocketOptions.java: >>> - the native methods should be static; since the instance is unused. >>> >>> - line 41: the return type should be Boolean >>> >>> - line 46: the return type of getQuickAck0 should be Boolean like the argument to set. >>> >>> - line 34: using JNU_ThrowByNameWithLastError directly is sufficient; if the errno does not have a string unix supplies "unknown error nnn". >>> >>> >>> Regards, Roger >>> >>> On 10/10/2017 2:58 PM, Chris Hegarty wrote: >>>> Vyom, >>>> >>>> What about suggestion 1) below, the name of the socket option? >>>> >>>> -Chris. >>>> >>>>> On 27 Sep 2017, at 09:56, vyom tewari wrote: >>>>> >>>>> Hi Chris, >>>>> >>>>> Thanks for review, please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8145635/webrev0.2/index.html). I incorporated review comments from you and re-base the patch to our consolidated repo(jdk10/master). >>>>> >>>>> Thanks, >>>>> >>>>> Vyom >>>>> >>>>> >>>>> On Monday 25 September 2017 01:57 AM, Chris Hegarty wrote: >>>>>> Vyom, >>>>>> >>>>>>> On 11 Sep 2017, at 16:38, vyom tewari wrote: >>>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> As jdk.net API already moved out of java.base, Please review the below code change for jdk10. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145635 >>>>>>> Webrev: http://cr.openjdk.java.net/~vtewari/8145635/webrev0.1/index.html >>>>>>> >>>>>> This looks quite good. Some comments: >>>>>> >>>>>> 1) I wonder if we should just call the option TCP_QUICKACK, rather than SO_QUICKACK? Similar to TCP_NODELAY. >>>>>> >>>>>> 2) I think LinuxSocketOptions.h is largely unnecessary, if we do 1) above. >>>>>> >>>>>> 3) Java_jdk_net_LinuxSocketOptions_getQuickAck could return jint, rather than jobject, thus avoiding the need for createBoolean. The conversation can happen in the Java layer. Can you please reduce the lint length in this file, by wrapping similar to the style of the Solaris version. >>>>>> >>>>>> 4) ExtendedSocketOptions.java >>>>>> - drop the

, they are unnecessary. >>>>>> - I think, similar to TCP_NODELAY, the spec should say that the options is TCP specific. From TCP_NODELAY: "The socket option is specific to stream-oriented sockets using the TCP/IP protocol.? >>>>>> - "In TCP_QUICKACK mode?, maybe ?When the option is enabled?? >>>>>> >>>>>> -Chris. >>>>>> >>>>>> From christoph.langer at sap.com Mon Oct 16 07:22:22 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 16 Oct 2017 07:22:22 +0000 Subject: RFR(S): 8155590: Dubious collection management in sun.net.www.http.KeepAliveCache Message-ID: <37df3795719f4a15b551fb96806fd72e@sap.com> Hi, Here is a proposal for a fix for bug 8155590. I already made this fix a while ago in our JDK clone and I'd like to contribute this. Bug: https://bugs.openjdk.java.net/browse/JDK-8155590 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8155590.0/ Please review. Thanks Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From vyom.tewari at oracle.com Mon Oct 16 08:27:09 2017 From: vyom.tewari at oracle.com (vyom tewari) Date: Mon, 16 Oct 2017 13:57:09 +0530 Subject: RFR(S): 8155590: Dubious collection management in sun.net.www.http.KeepAliveCache In-Reply-To: <37df3795719f4a15b551fb96806fd72e@sap.com> References: <37df3795719f4a15b551fb96806fd72e@sap.com> Message-ID: <813e5027-0ff8-37ad-095d-c177c53a0196@oracle.com> Hi Christoph, Thanks for doing this, i think you don't need to synchronize the "remove(HttpClient h)".? This remove is get called from synchronize "remove (HttpClient h, Object obj)" and the underline data structure is which is java.util.Vector(ClientVector extends java.util.Stack) is also thread safe. What do you think ? Thanks, Vyom On Monday 16 October 2017 12:52 PM, Langer, Christoph wrote: > > Hi, > > Here is a proposal for a fix for bug 8155590. I already made this fix > a while ago in our JDK clone and I?d like to contribute this. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8155590 > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8155590.0/ > > > Please review. > > Thanks > > Christoph > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Mon Oct 16 09:33:34 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 16 Oct 2017 09:33:34 +0000 Subject: RFR(S): 8155590: Dubious collection management in sun.net.www.http.KeepAliveCache In-Reply-To: <813e5027-0ff8-37ad-095d-c177c53a0196@oracle.com> References: <37df3795719f4a15b551fb96806fd72e@sap.com> <813e5027-0ff8-37ad-095d-c177c53a0196@oracle.com> Message-ID: Hi Vyom, thanks for your feedback. I'm not so sure about dropping "synchronized". In the new remove method of ClientVector we are iterating ourself. If this is not done under synchronization, there is risk to run into a ConcurrentModificationException. But under the assumption that all access to ClientVector comes from synchronized methods of KeepAliveCache, one could argue to drop all synchronized modifiers for ClientVector, though. Let's wait for other opinions :) Best regards Christoph From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of vyom tewari Sent: Montag, 16. Oktober 2017 10:27 To: net-dev at openjdk.java.net Subject: Re: RFR(S): 8155590: Dubious collection management in sun.net.www.http.KeepAliveCache Hi Christoph, Thanks for doing this, i think you don't need to synchronize the "remove(HttpClient h)". This remove is get called from synchronize "remove (HttpClient h, Object obj)" and the underline data structure is which is java.util.Vector(ClientVector extends java.util.Stack) is also thread safe. What do you think ? Thanks, Vyom On Monday 16 October 2017 12:52 PM, Langer, Christoph wrote: Hi, Here is a proposal for a fix for bug 8155590. I already made this fix a while ago in our JDK clone and I'd like to contribute this. Bug: https://bugs.openjdk.java.net/browse/JDK-8155590 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8155590.0/ Please review. Thanks Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From roger.riggs at oracle.com Tue Oct 17 01:05:55 2017 From: roger.riggs at oracle.com (Roger Riggs) Date: Mon, 16 Oct 2017 18:05:55 -0700 Subject: RFR 8145635 : Add TCP_QUICKACK socket option In-Reply-To: <4ff68a2b-108b-293f-e498-ec81590e00db@oracle.com> References: <56CD74E1.60309@oracle.com> <56CD7C0A.2080402@oracle.com> <0b0989b5-c791-a476-a82f-6c686b19c9d3@oracle.com> <54CDCFD4-97F5-480C-A4D9-03CEA58803B5@oracle.com> <82e35025-cd86-5119-3556-f0989eb3a785@oracle.com> <81600a54-f514-8a47-e719-10864f59f612@oracle.com> <7F57E4CA-5A33-46C5-AA44-A739B3D7BA10@oracle.com> <4ff68a2b-108b-293f-e498-ec81590e00db@oracle.com> Message-ID: <55658ef6-486c-835f-a62e-e9f132dc4543@oracle.com> Hi Vyom, A few suggestions: PlainDatagramSocketImpl.java: ?- line 95/96:? I think you can use just forEach, the order version is not necessary. ??? The code will be a bit more readable if the .filter and .forEach are on a new line and don't wrap. ??? You can also remove the extra "(" and ") ?- line 87-94: these are confusing and imply some implicit resetting of the option. ?- use @since 10 - 209/268: the native setQuickAck method should use boolean as its argument to enable/disable ? Since enable is a boolean; it does not need "== true' LinuxSocketOptions.java/c: ? - 52: setQuickAck0 should use boolean for the 2nd argument; (The native code already does) Thanks, Roger On 10/15/17 11:58 PM, vyom tewari wrote: > Hi Chris, > > Thanks for review. Please find the latest > webrev(http://cr.openjdk.java.net/~vtewari/8145635/webrev0.5/index.html). > > Thanks, > > Vyom > From vyom.tewari at oracle.com Tue Oct 17 08:37:04 2017 From: vyom.tewari at oracle.com (vyom tewari) Date: Tue, 17 Oct 2017 14:07:04 +0530 Subject: RFR 8145635 : Add TCP_QUICKACK socket option In-Reply-To: <55658ef6-486c-835f-a62e-e9f132dc4543@oracle.com> References: <56CD74E1.60309@oracle.com> <56CD7C0A.2080402@oracle.com> <0b0989b5-c791-a476-a82f-6c686b19c9d3@oracle.com> <54CDCFD4-97F5-480C-A4D9-03CEA58803B5@oracle.com> <82e35025-cd86-5119-3556-f0989eb3a785@oracle.com> <81600a54-f514-8a47-e719-10864f59f612@oracle.com> <7F57E4CA-5A33-46C5-AA44-A739B3D7BA10@oracle.com> <4ff68a2b-108b-293f-e498-ec81590e00db@oracle.com> <55658ef6-486c-835f-a62e-e9f132dc4543@oracle.com> Message-ID: Hi Roger, Thanks for the review , please find the updated webrev(http://cr.openjdk.java.net/~vtewari/8145635/webrev0.6/index.html). Thanks, Vyom On Tuesday 17 October 2017 06:35 AM, Roger Riggs wrote: > Hi Vyom, > > A few suggestions: > > PlainDatagramSocketImpl.java: > ?- line 95/96:? I think you can use just forEach, the order version is > not necessary. > ??? The code will be a bit more readable if the .filter and .forEach > are on a new line and don't wrap. > ??? You can also remove the extra "(" and ") > > ?- line 87-94: these are confusing and imply some implicit resetting > of the option. > ?- use @since 10 > - 209/268: the native setQuickAck method should use boolean as its > argument to enable/disable > ? Since enable is a boolean; it does not need "== true' > > LinuxSocketOptions.java/c: > ? - 52: setQuickAck0 should use boolean for the 2nd argument; (The > native code already does) > > Thanks, Roger > > > On 10/15/17 11:58 PM, vyom tewari wrote: >> Hi Chris, >> >> Thanks for review. Please find the latest >> webrev(http://cr.openjdk.java.net/~vtewari/8145635/webrev0.5/index.html). >> >> Thanks, >> >> Vyom >> > From roger.riggs at oracle.com Tue Oct 17 14:52:30 2017 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 17 Oct 2017 07:52:30 -0700 Subject: RFR(S): 8155590: Dubious collection management in sun.net.www.http.KeepAliveCache In-Reply-To: References: <37df3795719f4a15b551fb96806fd72e@sap.com> <813e5027-0ff8-37ad-095d-c177c53a0196@oracle.com> Message-ID: <2a567045-39d7-683c-a127-0d8698fdd68f@oracle.com> Hi, Keep the synchronized, it will be low overhead since the Vector operations are synchronized and in the same thread. I think a CCE could occur during the iteration to find the entry when Vector.Itr.next() checks. (It you want to more radical fix, replace the Vector with something more current. It would be one less Vector). Roger On 10/16/17 2:33 AM, Langer, Christoph wrote: > > Hi Vyom, > > thanks for your feedback. > > I?m not so sure about dropping ?synchronized?. In the new remove > method of ClientVector we are iterating ourself. If this is not done > under synchronization, there is risk to run into a > ConcurrentModificationException. But under the assumption that all > access to ClientVector comes from synchronized methods of > KeepAliveCache, one could argue to drop all synchronized modifiers for > ClientVector, though. > > Let?s wait for other opinions J > > Best regards > > Christoph > > *From:*net-dev [mailto:net-dev-bounces at openjdk.java.net] *On Behalf Of > *vyom tewari > *Sent:* Montag, 16. Oktober 2017 10:27 > *To:* net-dev at openjdk.java.net > *Subject:* Re: RFR(S): 8155590: Dubious collection management in > sun.net.www.http.KeepAliveCache > > Hi Christoph, > > Thanks for doing this, i think you don't need to synchronize the > "remove(HttpClient h)".? This remove is get called from synchronize > "remove (HttpClient h, Object obj)" and the underline data structure > is which is java.util.Vector(ClientVector extends java.util.Stack) is > also thread safe. > > What do you think ? > > Thanks, > > Vyom > > On Monday 16 October 2017 12:52 PM, Langer, Christoph wrote: > > Hi, > > Here is a proposal for a fix for bug 8155590. I already made this > fix a while ago in our JDK clone and I?d like to contribute this. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8155590 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8155590.0/ > > > Please review. > > Thanks > > Christoph > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Wed Oct 18 13:05:58 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 18 Oct 2017 13:05:58 +0000 Subject: RFR(S): 8155590: Dubious collection management in sun.net.www.http.KeepAliveCache In-Reply-To: <2a567045-39d7-683c-a127-0d8698fdd68f@oracle.com> References: <37df3795719f4a15b551fb96806fd72e@sap.com> <813e5027-0ff8-37ad-095d-c177c53a0196@oracle.com> <2a567045-39d7-683c-a127-0d8698fdd68f@oracle.com> Message-ID: <93b83e8e602d4a898a47be1fae0bb4ec@sap.com> Hi Roger, thanks for looking. So you motivated me to do some more cleanup. :) Here is the new webrev: http://cr.openjdk.java.net/~clanger/webrevs/8155590.1/ I replaced the Stack with an ArrayDeque and did some more rather cosmetical changes to make KeepAliveCache more appealing. I verified the change by running the jtreg tests jdk/sun/net/www/http/* and it all passes. As for the CCE: I don't think this should be checked as the Stack/ArrayDeque is typed to KeepAliveEntry and no code appears to be in place which could trick this. Best regards Christoph From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of Roger Riggs Sent: Dienstag, 17. Oktober 2017 16:53 To: net-dev at openjdk.java.net Subject: Re: RFR(S): 8155590: Dubious collection management in sun.net.www.http.KeepAliveCache Hi, Keep the synchronized, it will be low overhead since the Vector operations are synchronized and in the same thread. I think a CCE could occur during the iteration to find the entry when Vector.Itr.next() checks. (It you want to more radical fix, replace the Vector with something more current. It would be one less Vector). Roger On 10/16/17 2:33 AM, Langer, Christoph wrote: Hi Vyom, thanks for your feedback. I'm not so sure about dropping "synchronized". In the new remove method of ClientVector we are iterating ourself. If this is not done under synchronization, there is risk to run into a ConcurrentModificationException. But under the assumption that all access to ClientVector comes from synchronized methods of KeepAliveCache, one could argue to drop all synchronized modifiers for ClientVector, though. Let's wait for other opinions :) Best regards Christoph From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of vyom tewari Sent: Montag, 16. Oktober 2017 10:27 To: net-dev at openjdk.java.net Subject: Re: RFR(S): 8155590: Dubious collection management in sun.net.www.http.KeepAliveCache Hi Christoph, Thanks for doing this, i think you don't need to synchronize the "remove(HttpClient h)". This remove is get called from synchronize "remove (HttpClient h, Object obj)" and the underline data structure is which is java.util.Vector(ClientVector extends java.util.Stack) is also thread safe. What do you think ? Thanks, Vyom On Monday 16 October 2017 12:52 PM, Langer, Christoph wrote: Hi, Here is a proposal for a fix for bug 8155590. I already made this fix a while ago in our JDK clone and I'd like to contribute this. Bug: https://bugs.openjdk.java.net/browse/JDK-8155590 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8155590.0/ Please review. Thanks Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Wed Oct 18 14:51:48 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 18 Oct 2017 14:51:48 +0000 Subject: RFR 8145635 : Add TCP_QUICKACK socket option In-Reply-To: References: <56CD74E1.60309@oracle.com> <56CD7C0A.2080402@oracle.com> <0b0989b5-c791-a476-a82f-6c686b19c9d3@oracle.com> <54CDCFD4-97F5-480C-A4D9-03CEA58803B5@oracle.com> <82e35025-cd86-5119-3556-f0989eb3a785@oracle.com> <81600a54-f514-8a47-e719-10864f59f612@oracle.com> <7F57E4CA-5A33-46C5-AA44-A739B3D7BA10@oracle.com> <4ff68a2b-108b-293f-e498-ec81590e00db@oracle.com> <55658ef6-486c-835f-a62e-e9f132dc4543@oracle.com> Message-ID: Hi Vyom, I just looked at your latest webrev which in general looks fine to me. Some minor remarks: make/lib/Lib-jdk.net.gmk: - copyright year needs to be updated src/java.base/unix/classes/java/net/PlainDatagramSocketImpl.java: - private void addExtSocketOptions(...) looks a bit awful concerning its formatting. I suggest something like this: private void addExtSocketOptions(Set> extOptions, Set> options) { // TCP_QUICKACK is applicable for TCP Sockets only. extOptions.stream() .filter((option) -> !option.name().equals("TCP_QUICKACK")) .forEach((option) -> options.add(option)); } src/jdk.net/share/classes/jdk/net/ExtendedSocketOptions.java: - copyright year needs to be updated - the equals sign should be placed on line 98 here: 98 public static final SocketOption TCP_QUICKACK 99 = new ExtSocketOption("TCP_QUICKACK", Boolean.class); Other than that you should consider it reviewed from my end. No need for further webrev... Best regards Christoph > -----Original Message----- > From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of > vyom tewari > Sent: Dienstag, 17. Oktober 2017 10:37 > To: net-dev at openjdk.java.net > Subject: Re: RFR 8145635 : Add TCP_QUICKACK socket option > > Hi Roger, > > Thanks for the review , please find the updated > webrev(http://cr.openjdk.java.net/~vtewari/8145635/webrev0.6/index.htm > l). > > Thanks, > > Vyom > > > On Tuesday 17 October 2017 06:35 AM, Roger Riggs wrote: > > Hi Vyom, > > > > A few suggestions: > > > > PlainDatagramSocketImpl.java: > > ?- line 95/96:? I think you can use just forEach, the order version is > > not necessary. > > ??? The code will be a bit more readable if the .filter and .forEach > > are on a new line and don't wrap. > > ??? You can also remove the extra "(" and ") > > > > ?- line 87-94: these are confusing and imply some implicit resetting > > of the option. > > ?- use @since 10 > > - 209/268: the native setQuickAck method should use boolean as its > > argument to enable/disable > > ? Since enable is a boolean; it does not need "== true' > > > > LinuxSocketOptions.java/c: > > ? - 52: setQuickAck0 should use boolean for the 2nd argument; (The > > native code already does) > > > > Thanks, Roger > > > > > > On 10/15/17 11:58 PM, vyom tewari wrote: > >> Hi Chris, > >> > >> Thanks for review. Please find the latest > >> > webrev(http://cr.openjdk.java.net/~vtewari/8145635/webrev0.5/index.htm > l). > >> > >> Thanks, > >> > >> Vyom > >> > > From roger.riggs at oracle.com Wed Oct 18 15:28:29 2017 From: roger.riggs at oracle.com (Roger Riggs) Date: Wed, 18 Oct 2017 08:28:29 -0700 Subject: RFR(S): 8155590: Dubious collection management in sun.net.www.http.KeepAliveCache In-Reply-To: <93b83e8e602d4a898a47be1fae0bb4ec@sap.com> References: <37df3795719f4a15b551fb96806fd72e@sap.com> <813e5027-0ff8-37ad-095d-c177c53a0196@oracle.com> <2a567045-39d7-683c-a127-0d8698fdd68f@oracle.com> <93b83e8e602d4a898a47be1fae0bb4ec@sap.com> Message-ID: Hi Christoph, Looks ok. The comment in remove() about CCE can be removed.? ArrayDeque is not thread safe and doesn't check for CCE (and the method is synchronized). Thanks, Roger On 10/18/17 6:05 AM, Langer, Christoph wrote: > > Hi Roger, > > thanks for looking. So you motivated me to do some more cleanup. J > > Here is the new webrev: > http://cr.openjdk.java.net/~clanger/webrevs/8155590.1/ > > > I replaced the Stack with an ArrayDeque and did some more rather > cosmetical changes to make KeepAliveCache more appealing. I verified > the change by running the jtreg tests jdk/sun/net/www/http/* and it > all passes. > > As for the CCE: I don?t think this should be checked as the > Stack/ArrayDeque is typed to KeepAliveEntry and no code appears to be > in place which could trick this. > > Best regards > > Christoph > > *From:*net-dev [mailto:net-dev-bounces at openjdk.java.net] *On Behalf Of > *Roger Riggs > *Sent:* Dienstag, 17. Oktober 2017 16:53 > *To:* net-dev at openjdk.java.net > *Subject:* Re: RFR(S): 8155590: Dubious collection management in > sun.net.www.http.KeepAliveCache > > Hi, > > Keep the synchronized, it will be low overhead since the Vector > operations > are synchronized and in the same thread. > > I think a CCE could occur during the iteration to find the entry when > Vector.Itr.next() checks. > > (It you want to more radical fix, replace the Vector with something > more current. > It would be one less Vector). > > Roger > > On 10/16/17 2:33 AM, Langer, Christoph wrote: > > Hi Vyom, > > thanks for your feedback. > > I?m not so sure about dropping ?synchronized?. In the new remove > method of ClientVector we are iterating ourself. If this is not > done under synchronization, there is risk to run into a > ConcurrentModificationException. But under the assumption that all > access to ClientVector comes from synchronized methods of > KeepAliveCache, one could argue to drop all synchronized modifiers > for ClientVector, though. > > Let?s wait for other opinions J > > Best regards > > Christoph > > *From:*net-dev [mailto:net-dev-bounces at openjdk.java.net] *On > Behalf Of *vyom tewari > *Sent:* Montag, 16. Oktober 2017 10:27 > *To:* net-dev at openjdk.java.net > *Subject:* Re: RFR(S): 8155590: Dubious collection management in > sun.net.www.http.KeepAliveCache > > Hi Christoph, > > Thanks for doing this, i think you don't need to synchronize the > "remove(HttpClient h)".? This remove is get called from > synchronize "remove (HttpClient h, Object obj)" and the underline > data structure is which is java.util.Vector(ClientVector extends > java.util.Stack) is also thread safe. > > What do you think ? > > Thanks, > > Vyom > > On Monday 16 October 2017 12:52 PM, Langer, Christoph wrote: > > Hi, > > Here is a proposal for a fix for bug 8155590. I already made > this fix a while ago in our JDK clone and I?d like to > contribute this. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8155590 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8155590.0/ > > > Please review. > > Thanks > > Christoph > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Wed Oct 18 16:47:49 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 18 Oct 2017 16:47:49 +0000 Subject: RFR(S): 8155590: Dubious collection management in sun.net.www.http.KeepAliveCache In-Reply-To: References: <37df3795719f4a15b551fb96806fd72e@sap.com> <813e5027-0ff8-37ad-095d-c177c53a0196@oracle.com> <2a567045-39d7-683c-a127-0d8698fdd68f@oracle.com> <93b83e8e602d4a898a47be1fae0bb4ec@sap.com> Message-ID: Hi Roger, maybe we have a little disconnect here in understanding. I thought you mean ClassCastException with CCE but I don't see this mentioned anywhere. My comment talks about ConcurrentModificationException (CME). I mentioned that because, when the Collection is modified while iterating (which I do by calling super.remove()) then the next call to the Iterator would throw a CME. But we don't go back to the iterator as we return after removing. Nevertheless, I can still remove the comment or change it... let me know. Thanks Christoph From: Roger Riggs [mailto:roger.riggs at oracle.com] Sent: Mittwoch, 18. Oktober 2017 17:28 To: Langer, Christoph ; net-dev at openjdk.java.net Subject: Re: RFR(S): 8155590: Dubious collection management in sun.net.www.http.KeepAliveCache Hi Christoph, Looks ok. The comment in remove() about CCE can be removed. ArrayDeque is not thread safe and doesn't check for CCE (and the method is synchronized). Thanks, Roger On 10/18/17 6:05 AM, Langer, Christoph wrote: Hi Roger, thanks for looking. So you motivated me to do some more cleanup. :) Here is the new webrev: http://cr.openjdk.java.net/~clanger/webrevs/8155590.1/ I replaced the Stack with an ArrayDeque and did some more rather cosmetical changes to make KeepAliveCache more appealing. I verified the change by running the jtreg tests jdk/sun/net/www/http/* and it all passes. As for the CCE: I don't think this should be checked as the Stack/ArrayDeque is typed to KeepAliveEntry and no code appears to be in place which could trick this. Best regards Christoph From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of Roger Riggs Sent: Dienstag, 17. Oktober 2017 16:53 To: net-dev at openjdk.java.net Subject: Re: RFR(S): 8155590: Dubious collection management in sun.net.www.http.KeepAliveCache Hi, Keep the synchronized, it will be low overhead since the Vector operations are synchronized and in the same thread. I think a CCE could occur during the iteration to find the entry when Vector.Itr.next() checks. (It you want to more radical fix, replace the Vector with something more current. It would be one less Vector). Roger On 10/16/17 2:33 AM, Langer, Christoph wrote: Hi Vyom, thanks for your feedback. I'm not so sure about dropping "synchronized". In the new remove method of ClientVector we are iterating ourself. If this is not done under synchronization, there is risk to run into a ConcurrentModificationException. But under the assumption that all access to ClientVector comes from synchronized methods of KeepAliveCache, one could argue to drop all synchronized modifiers for ClientVector, though. Let's wait for other opinions :) Best regards Christoph From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of vyom tewari Sent: Montag, 16. Oktober 2017 10:27 To: net-dev at openjdk.java.net Subject: Re: RFR(S): 8155590: Dubious collection management in sun.net.www.http.KeepAliveCache Hi Christoph, Thanks for doing this, i think you don't need to synchronize the "remove(HttpClient h)". This remove is get called from synchronize "remove (HttpClient h, Object obj)" and the underline data structure is which is java.util.Vector(ClientVector extends java.util.Stack) is also thread safe. What do you think ? Thanks, Vyom On Monday 16 October 2017 12:52 PM, Langer, Christoph wrote: Hi, Here is a proposal for a fix for bug 8155590. I already made this fix a while ago in our JDK clone and I'd like to contribute this. Bug: https://bugs.openjdk.java.net/browse/JDK-8155590 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8155590.0/ Please review. Thanks Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From roger.riggs at oracle.com Wed Oct 18 18:37:13 2017 From: roger.riggs at oracle.com (Roger Riggs) Date: Wed, 18 Oct 2017 11:37:13 -0700 Subject: RFR(S): 8155590: Dubious collection management in sun.net.www.http.KeepAliveCache In-Reply-To: References: <37df3795719f4a15b551fb96806fd72e@sap.com> <813e5027-0ff8-37ad-095d-c177c53a0196@oracle.com> <2a567045-39d7-683c-a127-0d8698fdd68f@oracle.com> <93b83e8e602d4a898a47be1fae0bb4ec@sap.com> Message-ID: <40085a66-ccca-0613-d81a-b64ee11d2cdb@oracle.com> Hi Christoph, Right, my mistake, I meant CME.? My point was that ArrayDeque does not throw CME from remove(). It is not multi-thread safe and does not check for CME. That remove might have been coded using the iterator: synchronized boolean remove(HttpClient h) { for (Iterator it =this.iterator(); it.hasNext();) { KeepAliveEntry curr = it.next(); if (curr.hc == h) { it.remove(); return true; } } return false; } your choice Thanks, Roger On 10/18/17 9:47 AM, Langer, Christoph wrote: > > Hi Roger, > > maybe we have a little disconnect here in understanding. I thought you > mean ClassCastException with CCE but I don?t see this mentioned > anywhere. My comment talks about ConcurrentModificationException > (CME). I mentioned that because, when the Collection is modified while > iterating (which I do by calling super.remove()) then the next call to > the Iterator would throw a CME. But we don?t go back to the iterator > as we return after removing. > > Nevertheless, I can still remove the comment or change it? let me know. > > Thanks > > Christoph > > *From:*Roger Riggs [mailto:roger.riggs at oracle.com] > *Sent:* Mittwoch, 18. Oktober 2017 17:28 > *To:* Langer, Christoph ; > net-dev at openjdk.java.net > *Subject:* Re: RFR(S): 8155590: Dubious collection management in > sun.net.www.http.KeepAliveCache > > Hi Christoph, > > Looks ok. > > The comment in remove() about CCE can be removed. ArrayDeque is not > thread safe > and doesn't check for CCE (and the method is synchronized). > > Thanks, Roger > > On 10/18/17 6:05 AM, Langer, Christoph wrote: > > Hi Roger, > > thanks for looking. So you motivated me to do some more cleanup. J > > Here is the new webrev: > http://cr.openjdk.java.net/~clanger/webrevs/8155590.1/ > > > I replaced the Stack with an ArrayDeque and did some more rather > cosmetical changes to make KeepAliveCache more appealing. I > verified the change by running the jtreg tests > jdk/sun/net/www/http/* and it all passes. > > As for the CCE: I don?t think this should be checked as the > Stack/ArrayDeque is typed to KeepAliveEntry and no code appears to > be in place which could trick this. > > Best regards > > Christoph > > *From:*net-dev [mailto:net-dev-bounces at openjdk.java.net] *On > Behalf Of *Roger Riggs > *Sent:* Dienstag, 17. Oktober 2017 16:53 > *To:* net-dev at openjdk.java.net > *Subject:* Re: RFR(S): 8155590: Dubious collection management in > sun.net.www.http.KeepAliveCache > > Hi, > > Keep the synchronized, it will be low overhead since the Vector > operations > are synchronized and in the same thread. > > I think a CCE could occur during the iteration to find the entry > when Vector.Itr.next() checks. > > (It you want to more radical fix, replace the Vector with > something more current. > It would be one less Vector). > > Roger > > > On 10/16/17 2:33 AM, Langer, Christoph wrote: > > Hi Vyom, > > thanks for your feedback. > > I?m not so sure about dropping ?synchronized?. In the new > remove method of ClientVector we are iterating ourself. If > this is not done under synchronization, there is risk to run > into a ConcurrentModificationException. But under the > assumption that all access to ClientVector comes from > synchronized methods of KeepAliveCache, one could argue to > drop all synchronized modifiers for ClientVector, though. > > Let?s wait for other opinions J > > Best regards > > Christoph > > *From:*net-dev [mailto:net-dev-bounces at openjdk.java.net] *On > Behalf Of *vyom tewari > *Sent:* Montag, 16. Oktober 2017 10:27 > *To:* net-dev at openjdk.java.net > *Subject:* Re: RFR(S): 8155590: Dubious collection management > in sun.net.www.http.KeepAliveCache > > Hi Christoph, > > Thanks for doing this, i think you don't need to synchronize > the "remove(HttpClient h)".? This remove is get called from > synchronize "remove (HttpClient h, Object obj)" and the > underline data structure is which is > java.util.Vector(ClientVector extends java.util.Stack) is also > thread safe. > > What do you think ? > > Thanks, > > Vyom > > On Monday 16 October 2017 12:52 PM, Langer, Christoph wrote: > > Hi, > > Here is a proposal for a fix for bug 8155590. I already > made this fix a while ago in our JDK clone and I?d like to > contribute this. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8155590 > > Webrev: > http://cr.openjdk.java.net/~clanger/webrevs/8155590.0/ > > > Please review. > > Thanks > > Christoph > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vyom.tewari at oracle.com Thu Oct 19 02:56:17 2017 From: vyom.tewari at oracle.com (vyom tewari) Date: Thu, 19 Oct 2017 08:26:17 +0530 Subject: RFR 8145635 : Add TCP_QUICKACK socket option In-Reply-To: References: <56CD74E1.60309@oracle.com> <56CD7C0A.2080402@oracle.com> <0b0989b5-c791-a476-a82f-6c686b19c9d3@oracle.com> <54CDCFD4-97F5-480C-A4D9-03CEA58803B5@oracle.com> <82e35025-cd86-5119-3556-f0989eb3a785@oracle.com> <81600a54-f514-8a47-e719-10864f59f612@oracle.com> <7F57E4CA-5A33-46C5-AA44-A739B3D7BA10@oracle.com> <4ff68a2b-108b-293f-e498-ec81590e00db@oracle.com> <55658ef6-486c-835f-a62e-e9f132dc4543@oracle.com> Message-ID: <29b37b28-f60a-dfd2-5778-030448619c2f@oracle.com> Hi All, please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8145635/webrev0.7/index.html). Thanks, Vyom On Wednesday 18 October 2017 08:21 PM, Langer, Christoph wrote: > Hi Vyom, > > I just looked at your latest webrev which in general looks fine to me. Some minor remarks: > > make/lib/Lib-jdk.net.gmk: > - copyright year needs to be updated > > src/java.base/unix/classes/java/net/PlainDatagramSocketImpl.java: > - private void addExtSocketOptions(...) looks a bit awful concerning its formatting. I suggest something like this: > > private void addExtSocketOptions(Set> extOptions, > Set> options) { > // TCP_QUICKACK is applicable for TCP Sockets only. > extOptions.stream() > .filter((option) -> !option.name().equals("TCP_QUICKACK")) > .forEach((option) -> options.add(option)); > } > > src/jdk.net/share/classes/jdk/net/ExtendedSocketOptions.java: > - copyright year needs to be updated > - the equals sign should be placed on line 98 here: > > 98 public static final SocketOption TCP_QUICKACK > 99 = new ExtSocketOption("TCP_QUICKACK", Boolean.class); > > Other than that you should consider it reviewed from my end. No need for further webrev... > > Best regards > Christoph > >> -----Original Message----- >> From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of >> vyom tewari >> Sent: Dienstag, 17. Oktober 2017 10:37 >> To: net-dev at openjdk.java.net >> Subject: Re: RFR 8145635 : Add TCP_QUICKACK socket option >> >> Hi Roger, >> >> Thanks for the review , please find the updated >> webrev(http://cr.openjdk.java.net/~vtewari/8145635/webrev0.6/index.htm >> l). >> >> Thanks, >> >> Vyom >> >> >> On Tuesday 17 October 2017 06:35 AM, Roger Riggs wrote: >>> Hi Vyom, >>> >>> A few suggestions: >>> >>> PlainDatagramSocketImpl.java: >>> ?- line 95/96:? I think you can use just forEach, the order version is >>> not necessary. >>> ??? The code will be a bit more readable if the .filter and .forEach >>> are on a new line and don't wrap. >>> ??? You can also remove the extra "(" and ") >>> >>> ?- line 87-94: these are confusing and imply some implicit resetting >>> of the option. >>> ?- use @since 10 >>> - 209/268: the native setQuickAck method should use boolean as its >>> argument to enable/disable >>> ? Since enable is a boolean; it does not need "== true' >>> >>> LinuxSocketOptions.java/c: >>> ? - 52: setQuickAck0 should use boolean for the 2nd argument; (The >>> native code already does) >>> >>> Thanks, Roger >>> >>> >>> On 10/15/17 11:58 PM, vyom tewari wrote: >>>> Hi Chris, >>>> >>>> Thanks for review. Please find the latest >>>> >> webrev(http://cr.openjdk.java.net/~vtewari/8145635/webrev0.5/index.htm >> l). >>>> Thanks, >>>> >>>> Vyom >>>> From christoph.langer at sap.com Thu Oct 19 06:18:45 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 19 Oct 2017 06:18:45 +0000 Subject: RFR 8145635 : Add TCP_QUICKACK socket option In-Reply-To: <29b37b28-f60a-dfd2-5778-030448619c2f@oracle.com> References: <56CD74E1.60309@oracle.com> <56CD7C0A.2080402@oracle.com> <0b0989b5-c791-a476-a82f-6c686b19c9d3@oracle.com> <54CDCFD4-97F5-480C-A4D9-03CEA58803B5@oracle.com> <82e35025-cd86-5119-3556-f0989eb3a785@oracle.com> <81600a54-f514-8a47-e719-10864f59f612@oracle.com> <7F57E4CA-5A33-46C5-AA44-A739B3D7BA10@oracle.com> <4ff68a2b-108b-293f-e498-ec81590e00db@oracle.com> <55658ef6-486c-835f-a62e-e9f132dc4543@oracle.com> <29b37b28-f60a-dfd2-5778-030448619c2f@oracle.com> Message-ID: <973351c934314010a3925f185716f695@sap.com> Hi Vyom, looks good to me. Best regards Christoph > -----Original Message----- > From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of > vyom tewari > Sent: Donnerstag, 19. Oktober 2017 04:56 > To: net-dev at openjdk.java.net > Subject: Re: RFR 8145635 : Add TCP_QUICKACK socket option > > Hi All, > > please find the latest > webrev(http://cr.openjdk.java.net/~vtewari/8145635/webrev0.7/index.htm > l). > > Thanks, > > Vyom > > > On Wednesday 18 October 2017 08:21 PM, Langer, Christoph wrote: > > Hi Vyom, > > > > I just looked at your latest webrev which in general looks fine to me. Some > minor remarks: > > > > make/lib/Lib-jdk.net.gmk: > > - copyright year needs to be updated > > > > src/java.base/unix/classes/java/net/PlainDatagramSocketImpl.java: > > - private void addExtSocketOptions(...) looks a bit awful concerning its > formatting. I suggest something like this: > > > > private void addExtSocketOptions(Set> extOptions, > > Set> options) { > > // TCP_QUICKACK is applicable for TCP Sockets only. > > extOptions.stream() > > .filter((option) -> !option.name().equals("TCP_QUICKACK")) > > .forEach((option) -> options.add(option)); > > } > > > > src/jdk.net/share/classes/jdk/net/ExtendedSocketOptions.java: > > - copyright year needs to be updated > > - the equals sign should be placed on line 98 here: > > > > 98 public static final SocketOption TCP_QUICKACK > > 99 = new ExtSocketOption("TCP_QUICKACK", > Boolean.class); > > > > Other than that you should consider it reviewed from my end. No need for > further webrev... > > > > Best regards > > Christoph > > > >> -----Original Message----- > >> From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of > >> vyom tewari > >> Sent: Dienstag, 17. Oktober 2017 10:37 > >> To: net-dev at openjdk.java.net > >> Subject: Re: RFR 8145635 : Add TCP_QUICKACK socket option > >> > >> Hi Roger, > >> > >> Thanks for the review , please find the updated > >> > webrev(http://cr.openjdk.java.net/~vtewari/8145635/webrev0.6/index.htm > >> l). > >> > >> Thanks, > >> > >> Vyom > >> > >> > >> On Tuesday 17 October 2017 06:35 AM, Roger Riggs wrote: > >>> Hi Vyom, > >>> > >>> A few suggestions: > >>> > >>> PlainDatagramSocketImpl.java: > >>> ?- line 95/96:? I think you can use just forEach, the order version is > >>> not necessary. > >>> ??? The code will be a bit more readable if the .filter and .forEach > >>> are on a new line and don't wrap. > >>> ??? You can also remove the extra "(" and ") > >>> > >>> ?- line 87-94: these are confusing and imply some implicit resetting > >>> of the option. > >>> ?- use @since 10 > >>> - 209/268: the native setQuickAck method should use boolean as its > >>> argument to enable/disable > >>> ? Since enable is a boolean; it does not need "== true' > >>> > >>> LinuxSocketOptions.java/c: > >>> ? - 52: setQuickAck0 should use boolean for the 2nd argument; (The > >>> native code already does) > >>> > >>> Thanks, Roger > >>> > >>> > >>> On 10/15/17 11:58 PM, vyom tewari wrote: > >>>> Hi Chris, > >>>> > >>>> Thanks for review. Please find the latest > >>>> > >> > webrev(http://cr.openjdk.java.net/~vtewari/8145635/webrev0.5/index.htm > >> l). > >>>> Thanks, > >>>> > >>>> Vyom > >>>> From chris.hegarty at oracle.com Thu Oct 19 07:31:28 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 19 Oct 2017 08:31:28 +0100 Subject: RFR 8145635 : Add TCP_QUICKACK socket option In-Reply-To: <29b37b28-f60a-dfd2-5778-030448619c2f@oracle.com> References: <56CD74E1.60309@oracle.com> <56CD7C0A.2080402@oracle.com> <0b0989b5-c791-a476-a82f-6c686b19c9d3@oracle.com> <54CDCFD4-97F5-480C-A4D9-03CEA58803B5@oracle.com> <82e35025-cd86-5119-3556-f0989eb3a785@oracle.com> <81600a54-f514-8a47-e719-10864f59f612@oracle.com> <7F57E4CA-5A33-46C5-AA44-A739B3D7BA10@oracle.com> <4ff68a2b-108b-293f-e498-ec81590e00db@oracle.com> <55658ef6-486c-835f-a62e-e9f132dc4543@oracle.com> <29b37b28-f60a-dfd2-5778-030448619c2f@oracle.com> Message-ID: <815AB06D-ED34-4654-9F53-442B9BD47220@oracle.com> > On 19 Oct 2017, at 03:56, vyom tewari wrote: > > Hi All, > > please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8145635/webrev0.7/index.html). Thanks Vyom, this update looks good to me. -Chris. From christoph.langer at sap.com Thu Oct 19 07:43:36 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 19 Oct 2017 07:43:36 +0000 Subject: RFR(S): 8155590: Dubious collection management in sun.net.www.http.KeepAliveCache In-Reply-To: <40085a66-ccca-0613-d81a-b64ee11d2cdb@oracle.com> References: <37df3795719f4a15b551fb96806fd72e@sap.com> <813e5027-0ff8-37ad-095d-c177c53a0196@oracle.com> <2a567045-39d7-683c-a127-0d8698fdd68f@oracle.com> <93b83e8e602d4a898a47be1fae0bb4ec@sap.com> <40085a66-ccca-0613-d81a-b64ee11d2cdb@oracle.com> Message-ID: <9270a10e65384558900024e45d9c947c@sap.com> Hi Roger, ah, I see. I pushed with removing the comment then: http://hg.openjdk.java.net/jdk10/master/rev/74e1913a98c0 Thanks Christoph From: Roger Riggs [mailto:roger.riggs at oracle.com] Sent: Mittwoch, 18. Oktober 2017 20:37 To: Langer, Christoph ; net-dev at openjdk.java.net Subject: Re: RFR(S): 8155590: Dubious collection management in sun.net.www.http.KeepAliveCache Hi Christoph, Right, my mistake, I meant CME. My point was that ArrayDeque does not throw CME from remove(). It is not multi-thread safe and does not check for CME. That remove might have been coded using the iterator: synchronized boolean remove(HttpClient h) { for (Iterator it = this.iterator(); it.hasNext();) { KeepAliveEntry curr = it.next(); if (curr.hc == h) { it.remove(); return true; } } return false; } your choice Thanks, Roger On 10/18/17 9:47 AM, Langer, Christoph wrote: Hi Roger, maybe we have a little disconnect here in understanding. I thought you mean ClassCastException with CCE but I don't see this mentioned anywhere. My comment talks about ConcurrentModificationException (CME). I mentioned that because, when the Collection is modified while iterating (which I do by calling super.remove()) then the next call to the Iterator would throw a CME. But we don't go back to the iterator as we return after removing. Nevertheless, I can still remove the comment or change it... let me know. Thanks Christoph From: Roger Riggs [mailto:roger.riggs at oracle.com] Sent: Mittwoch, 18. Oktober 2017 17:28 To: Langer, Christoph ; net-dev at openjdk.java.net Subject: Re: RFR(S): 8155590: Dubious collection management in sun.net.www.http.KeepAliveCache Hi Christoph, Looks ok. The comment in remove() about CCE can be removed. ArrayDeque is not thread safe and doesn't check for CCE (and the method is synchronized). Thanks, Roger On 10/18/17 6:05 AM, Langer, Christoph wrote: Hi Roger, thanks for looking. So you motivated me to do some more cleanup. :) Here is the new webrev: http://cr.openjdk.java.net/~clanger/webrevs/8155590.1/ I replaced the Stack with an ArrayDeque and did some more rather cosmetical changes to make KeepAliveCache more appealing. I verified the change by running the jtreg tests jdk/sun/net/www/http/* and it all passes. As for the CCE: I don't think this should be checked as the Stack/ArrayDeque is typed to KeepAliveEntry and no code appears to be in place which could trick this. Best regards Christoph From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of Roger Riggs Sent: Dienstag, 17. Oktober 2017 16:53 To: net-dev at openjdk.java.net Subject: Re: RFR(S): 8155590: Dubious collection management in sun.net.www.http.KeepAliveCache Hi, Keep the synchronized, it will be low overhead since the Vector operations are synchronized and in the same thread. I think a CCE could occur during the iteration to find the entry when Vector.Itr.next() checks. (It you want to more radical fix, replace the Vector with something more current. It would be one less Vector). Roger On 10/16/17 2:33 AM, Langer, Christoph wrote: Hi Vyom, thanks for your feedback. I'm not so sure about dropping "synchronized". In the new remove method of ClientVector we are iterating ourself. If this is not done under synchronization, there is risk to run into a ConcurrentModificationException. But under the assumption that all access to ClientVector comes from synchronized methods of KeepAliveCache, one could argue to drop all synchronized modifiers for ClientVector, though. Let's wait for other opinions :) Best regards Christoph From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of vyom tewari Sent: Montag, 16. Oktober 2017 10:27 To: net-dev at openjdk.java.net Subject: Re: RFR(S): 8155590: Dubious collection management in sun.net.www.http.KeepAliveCache Hi Christoph, Thanks for doing this, i think you don't need to synchronize the "remove(HttpClient h)". This remove is get called from synchronize "remove (HttpClient h, Object obj)" and the underline data structure is which is java.util.Vector(ClientVector extends java.util.Stack) is also thread safe. What do you think ? Thanks, Vyom On Monday 16 October 2017 12:52 PM, Langer, Christoph wrote: Hi, Here is a proposal for a fix for bug 8155590. I already made this fix a while ago in our JDK clone and I'd like to contribute this. Bug: https://bugs.openjdk.java.net/browse/JDK-8155590 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8155590.0/ Please review. Thanks Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Oct 19 09:12:59 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 19 Oct 2017 10:12:59 +0100 Subject: RFR 8145635 : Add TCP_QUICKACK socket option In-Reply-To: <29b37b28-f60a-dfd2-5778-030448619c2f@oracle.com> References: <56CD74E1.60309@oracle.com> <56CD7C0A.2080402@oracle.com> <0b0989b5-c791-a476-a82f-6c686b19c9d3@oracle.com> <54CDCFD4-97F5-480C-A4D9-03CEA58803B5@oracle.com> <82e35025-cd86-5119-3556-f0989eb3a785@oracle.com> <81600a54-f514-8a47-e719-10864f59f612@oracle.com> <7F57E4CA-5A33-46C5-AA44-A739B3D7BA10@oracle.com> <4ff68a2b-108b-293f-e498-ec81590e00db@oracle.com> <55658ef6-486c-835f-a62e-e9f132dc4543@oracle.com> <29b37b28-f60a-dfd2-5778-030448619c2f@oracle.com> Message-ID: <155e9947-945f-469b-3dff-96a897d3c408@oracle.com> On 19/10/2017 03:56, vyom tewari wrote: > Hi All, > > please find the latest > webrev(http://cr.openjdk.java.net/~vtewari/8145635/webrev0.7/index.html). I can't recall if I brought this up already but we do have an issue to deprecate-for-removal jdk.net.Sockets? Socket and friends were rev'ed in Java 9 to add set/getOption methods so I assume the static methods on jdk.net.Sockets can go away in time. -Alan From chris.hegarty at oracle.com Fri Oct 20 15:43:01 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 20 Oct 2017 16:43:01 +0100 Subject: RFR 8145635 : Add TCP_QUICKACK socket option In-Reply-To: <155e9947-945f-469b-3dff-96a897d3c408@oracle.com> References: <56CD74E1.60309@oracle.com> <56CD7C0A.2080402@oracle.com> <0b0989b5-c791-a476-a82f-6c686b19c9d3@oracle.com> <54CDCFD4-97F5-480C-A4D9-03CEA58803B5@oracle.com> <82e35025-cd86-5119-3556-f0989eb3a785@oracle.com> <81600a54-f514-8a47-e719-10864f59f612@oracle.com> <7F57E4CA-5A33-46C5-AA44-A739B3D7BA10@oracle.com> <4ff68a2b-108b-293f-e498-ec81590e00db@oracle.com> <55658ef6-486c-835f-a62e-e9f132dc4543@oracle.com> <29b37b28-f60a-dfd2-5778-030448619c2f@oracle.com> <155e9947-945f-469b-3dff-96a897d3c408@oracle.com> Message-ID: <47832f74-0569-6d56-bbaf-17c753b197d9@oracle.com> On 19/10/17 10:12, Alan Bateman wrote: > ... > I can't recall if I brought this up already but we do have an issue to > deprecate-for-removal jdk.net.Sockets? Socket and friends were rev'ed in > Java 9 to add set/getOption methods so I assume the static methods on > jdk.net.Sockets can go away in time. Thanks Alan, I filed the following issue to track this: https://bugs.openjdk.java.net/browse/JDK-8189744 -Chris. From vyom.tewari at oracle.com Thu Oct 26 09:26:15 2017 From: vyom.tewari at oracle.com (vyom tewari) Date: Thu, 26 Oct 2017 14:56:15 +0530 Subject: RFR: 8189366: SocketInputStream.available() should check for eof Message-ID: <1ced3b55-4061-ee59-3fd8-2309876f20de@oracle.com> Hi All, Please review the simple change below. Webrev?? : http://cr.openjdk.java.net/~vtewari/8189366/webrev0.0/index.html BugId????? : https://bugs.openjdk.java.net/browse/JDK-8189366 Currently SocketInputStream.available() does not check for "eof" and simply delegate to the impl even when "eof" reached. I put a check? to return 0 if "eof" is already reached. Thanks, Vyom From ecki at zusammenkunft.net Thu Oct 26 09:44:23 2017 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 26 Oct 2017 09:44:23 +0000 Subject: RFR: 8189366: SocketInputStream.available() should check for eof In-Reply-To: <1ced3b55-4061-ee59-3fd8-2309876f20de@oracle.com> References: <1ced3b55-4061-ee59-3fd8-2309876f20de@oracle.com> Message-ID: What is currently returned at the end of a stream? This looks like a dangerous thing to do, if a existing implementation only read when something is available it might never detect that it reached EOF. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ From: net-dev on behalf of vyom tewari Sent: Thursday, October 26, 2017 11:26:15 AM To: OpenJDK Network Dev list Subject: RFR: 8189366: SocketInputStream.available() should check for eof Hi All, Please review the simple change below. Webrev : http://cr.openjdk.java.net/~vtewari/8189366/webrev0.0/index.html BugId : https://bugs.openjdk.java.net/browse/JDK-8189366 Currently SocketInputStream.available() does not check for "eof" and simply delegate to the impl even when "eof" reached. I put a check to return 0 if "eof" is already reached. Thanks, Vyom -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Thu Oct 26 16:01:25 2017 From: martinrb at google.com (Martin Buchholz) Date: Thu, 26 Oct 2017 09:01:25 -0700 Subject: RFR: 8189366: SocketInputStream.available() should check for eof In-Reply-To: <1ced3b55-4061-ee59-3fd8-2309876f20de@oracle.com> References: <1ced3b55-4061-ee59-3fd8-2309876f20de@oracle.com> Message-ID: Any change that fiddles with "available" is never simple! I confess to not understanding sockets, but intuitively they differ from files in that eof is a murky concept - there may not be any data from the other end of the socket right now, but who knows what's coming soon? What's the difference between eof and closed? Even for files eof might be murky - if some other process is writing to a file in append mode, eof might be a transient state. On Thu, Oct 26, 2017 at 2:26 AM, vyom tewari wrote: > Hi All, > > Please review the simple change below. > > Webrev : http://cr.openjdk.java.net/~vtewari/8189366/webrev0.0/index. > html > > BugId : https://bugs.openjdk.java.net/browse/JDK-8189366 > > > Currently SocketInputStream.available() does not check for "eof" and > simply delegate to the impl even when "eof" reached. I put a check to > return 0 if "eof" is already reached. > > Thanks, > > Vyom > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lloyd at redhat.com Thu Oct 26 20:37:59 2017 From: david.lloyd at redhat.com (David Lloyd) Date: Thu, 26 Oct 2017 15:37:59 -0500 Subject: RFR: 8189366: SocketInputStream.available() should check for eof In-Reply-To: References: <1ced3b55-4061-ee59-3fd8-2309876f20de@oracle.com> Message-ID: On Thu, Oct 26, 2017 at 4:44 AM, Bernd Eckenfels wrote: > What is currently returned at the end of a stream? This looks like a > dangerous thing to do, if a existing implementation only read when something > is available it might never detect that it reached EOF. At present it ultimately delegates (on UNIXy) to ioctl(fd, FIONREAD, xxx) which I guess will return an errno in this case. If that's the case then I agree that returning 0 is a smarter option. -- - DML From vyom.tewari at oracle.com Fri Oct 27 06:01:57 2017 From: vyom.tewari at oracle.com (vyom tewari) Date: Fri, 27 Oct 2017 11:31:57 +0530 Subject: RFR: 8189366: SocketInputStream.available() should check for eof In-Reply-To: References: <1ced3b55-4061-ee59-3fd8-2309876f20de@oracle.com> Message-ID: On Thursday 26 October 2017 03:14 PM, Bernd Eckenfels wrote: > What is currently returned at the end of a stream? This looks like a > dangerous thing to do, if a existing implementation only Currently it returns 0 at end of stream and? same as after change. As David pointed out that ultimately it delegates on to "ioctl", i checked the doc(http://man7.org/linux/man-pages/man4/tty_ioctl.4.html) and did not found anything which tells about eof. What i found out, setting eof at socketinputstream there is no effect on native? "ioctl" call. I set the "eof"? and SocketInputStream.available() return 0. Let's wait for other people opinions. Note: you have to shutdown the SocketInputstream to set "eof", i am not sure if there is any other way to set "eof" for SocketInputStream. Thanks, Vyom > read when something is available it might never detect that it reached > EOF. > > Gruss > Bernd > -- > http://bernd.eckenfels.net > ------------------------------------------------------------------------ > *From:* net-dev on behalf of vyom > tewari > *Sent:* Thursday, October 26, 2017 11:26:15 AM > *To:* OpenJDK Network Dev list > *Subject:* RFR: 8189366: SocketInputStream.available() should check > for eof > Hi All, > > Please review the simple change below. > > Webrev?? : > http://cr.openjdk.java.net/~vtewari/8189366/webrev0.0/index.html > > > BugId????? : https://bugs.openjdk.java.net/browse/JDK-8189366 > > > Currently SocketInputStream.available() does not check for "eof" and > simply delegate to the impl even when "eof" reached. I put a check? to > return 0 if "eof" is already reached. > > Thanks, > > Vyom > -------------- next part -------------- An HTML attachment was scrubbed... URL: