RE: RFR(XS): 8201369: Inet4AddressImpl_getLocalHostName reverse lookup on Solaris only
Hi Chris, our testing didn’t show regressions. Are we good to push? Best regards Christoph From: Chris Hegarty [mailto:chris.hega...@oracle.com] Sent: Montag, 16. April 2018 16:39 To: Langer, Christoph Cc: Srividya Shamaiah ; OpenJDK Network Dev list Subject: Re: RFR(XS): 8201369: Inet4AddressImpl_getLocalHostName reverse lookup on Solaris only On 16 Apr 2018, at 10:29, Langer, Christoph mailto:christoph.lan...@sap.com>> wrote: Hi Srividya, thanks for doing this work. Change looks good from my side, except for a small indentation flaw in lines 91 and 94 and the copyright year that needs to be adjusted. But I can fix this when I push it. +1 Let’s wait for another review (Chris) before we can push it. I’ll also do some testing. I’ll run some tests with this patch too. I’ll also take care of the backport after the push to jdk11. Yes. Let’s first push this to jdk/jdk, then follow up with a back port request as appropriate. -Chris. Best regards Christoph From: Srividya Shamaiah [mailto:ssham...@in.ibm.com] Sent: Montag, 16. April 2018 10:44 To: Langer, Christoph mailto:christoph.lan...@sap.com>> Cc: Chris Hegarty mailto:chris.hega...@oracle.com>>; OpenJDK Network Dev list mailto:net-dev@openjdk.java.net>> Subject: RFR(XS): 8201369: Inet4AddressImpl_getLocalHostName reverse lookup on Solaris only Hi Chris, Please review the attached patch in http://cr.openjdk.java.net/~mhorie/8201369/webrev/ Can you also backport this to JDK 8, we have customers waiting for this fix at JDK 8 level. Thanks, Srividya S Srividya Shamaiah---11/04/2018 03:35:38 PM---Thanks Chris , As you suggested, I will provide the patch based on jdk 11. Thanks, From: Srividya Shamaiah/India/IBM To: "Langer, Christoph" mailto:christoph.lan...@sap.com>> Cc: Chris Hegarty mailto:chris.hega...@oracle.com>>, OpenJDK Network Dev list mailto:net-dev@openjdk.java.net>> Date: 11/04/2018 03:35 PM Subject: RE: 8169865 : Changes not ported to IPv4 Thanks Chris , As you suggested, I will provide the patch based on jdk 11. Thanks, Srividya S "Langer, Christoph" ---11/04/2018 02:51:51 PM---Hi Srividya, I would also welcome this fix. From: "Langer, Christoph" mailto:christoph.lan...@sap.com>> To: Srividya Shamaiah mailto:ssham...@in.ibm.com>>, Chris Hegarty mailto:chris.hega...@oracle.com>> Cc: OpenJDK Network Dev list mailto:net-dev@openjdk.java.net>> Date: 11/04/2018 02:51 PM Subject: RE: 8169865 : Changes not ported to IPv4 Hi Srividya, I would also welcome this fix. Will you do the fix based on the jdk (11) depot? I think Java_java_net_Inet4AddressImpl_getLocalHostName should then be exactly the same as Java_java_net_Inet6AddressImpl_getLocalHostName. I can assist you with sponsoring/backporting to JDK8, if you like. Best regards Christoph From: net-dev [mailto:net-dev-boun...@openjdk.java.net] On Behalf Of Srividya Shamaiah Sent: Mittwoch, 11. April 2018 09:19 To: Chris Hegarty mailto:chris.hega...@oracle.com>> Cc: OpenJDK Network Dev list mailto:net-dev@openjdk.java.net>> Subject: Re: 8169865 : Changes not ported to IPv4 Thank you Chris for opening the JIRA bug, I will work on the fix and contribute it . Thanks, Srividya S Chris Hegarty ---10/04/2018 08:51:05 PM---> On 10 Apr 2018, at 12:34, Srividya Shamaiah mailto:ssham...@in.ibm.com>> wrote: > From: Chris Hegarty mailto:chris.hega...@oracle.com>> To: Srividya Shamaiah mailto:ssham...@in.ibm.com>> Cc: OpenJDK Network Dev list mailto:net-dev@openjdk.java.net>> Date: 10/04/2018 08:51 PM Subject: Re: 8169865 : Changes not ported to IPv4 > On 10 Apr 2018, at 12:34, Srividya Shamaiah > mailto:ssham...@in.ibm.com>> wrote: > > Hi Chris, > > One of our customer reported a similar issue and the issue can be resolved > through the bug fix 8169865 which was include at 8u152 level. We were looking > this issue from AIX perspective as it did not do the reverse lookup with bug > fix 8169865 (as reverse lookup is limited to solaris after the bug fix). > > While implementing the fix, we want to make sure the fix works for all > scenario. As there is an inconsistency between IPv6 and IPv4 after 8169865 > (as reverse lookup still exists for IPv4 on AIX and Linux), we are afraid > whether customer can hit the same issue if they use IPv4. > > Please confirm whether it makes sense to remove the reverse lookup of IPv4 > for AIX and linux platforms so that IPv4 and IPv6 processing is consistent > for those platforms. Yes, I believe it does. I filed the follow JIRA issue to track this: https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8201369&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=cY5OjfQF2gZ_G00XrJYGrxPgLDHmXjFqs49sDD9oJN0&m=-LhngTQSiYD1d12WSDvX2Jldxusyok9A7LqJ4ZEIzos&s=8fDzPwCaD2hwIOSWkfchiRBeDz3uSyzk81kDXZFarXo&e= -Chris.
Re: RFR:8194298 Add support for per Socket configuration of TCP keepalive
Vyom,
On 13/04/18 10:50, vyom tewari wrote:
Hi All,
Please review the below code.
BugId: https://bugs.openjdk.java.net/browse/JDK-8194298
webrev : http://cr.openjdk.java.net/~vtewari/8194298/webrev0.0/index.html
Here is some proposed wording for the JDK-specific extended socket
options specification.
1) Uses a consistent style across all three new options,
and is in line with existing extended options.
2) Renamed the options slightly, to improve readability
( they don't need to conform to the native option names )
3) Reordered them so the build up is more logical
4) Removed inheritance from server sockets
5) Added standard verbiage about being "platform and
system dependent
6) Added typical values. I think this is useful, as it
gives an idea to the developer, but maybe it could be
misleading. Can be dropped if there are concerns.
Can you please confirm that this is accurate, and also
will leave enough "wriggle" room when additional platform
support is added.
---
/**
* Keep-Alive idle time.
*
* When the {@link java.net.StandardSocketOptions#SO_KEEPALIVE
* SO_KEEPALIVE} option is enabled, TCP probes a connection that
has been
* idle for some amount of time. The default value for this idle
period is
* system dependent, but is typically 2 hours. The {@code TCP_KEEPIDLE}
* option can be used to affect this value for a given socket.
*
* The value of this socket option is an {@code Integer} that
is the
* number of seconds of idle time before keep-alive initiates a
probe. 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.
*
* @since 11
*/
public static final SocketOption TCP_KEEPIDLE
= new ExtSocketOption("TCP_KEEPIDLE", Integer.class);
/**
* Keep-Alive retransmission interval time.
*
* When the {@link java.net.StandardSocketOptions#SO_KEEPALIVE
* SO_KEEPALIVE} option is enabled, TCP probes a connection that
has been
* idle for some amount of time. If the remote system does not
respond to a
* keep-alive probe, TCP retransmits the probe after some amount of
time.
* The default value for this retransmition interval is system
dependent,
* but is typically 75 seconds. The {@code TCP_KEEPINTERVAL} option
can be
* used to affect this value for a given socket.
*
* The value of this socket option is an {@code Integer} that
is the
* number of seconds to wait before retransmitting a keep-alive
probe. 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.
*
* @since 11
*/
public static final SocketOption TCP_KEEPINTERVAL
= new ExtSocketOption("TCP_KEEPINTERVAL",
Integer.class);
/**
* Keep-Alive retransmission maximum limit.
*
* When the {@link java.net.StandardSocketOptions#SO_KEEPALIVE
* SO_KEEPALIVE} option is enabled, TCP probes a connection that
has been
* idle for some amount of time. If the remote system does not
respond to a
* keep-alive probe, TCP retransmits the probe a certain number of
times
* before a connection is considered to be broken. The default
value for
* this keep-alive probe retransmit limit is system dependent, but is
* typically 8. The {@code TCP_KEEPCOUNT} option can be used to affect
* this value for a given socket.
*
* The value of this socket option is an {@code Integer} that
is the
* maximum number of keep-alive probes to be sent. 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.
*
* @since 11
*/
public static final SocketOption TCP_KEEPCOUNT
= new ExtSocketOption("TCP_KEEPCOUNT", Integer.class);
-Chris.
Re: RFR(XS): 8201369: Inet4AddressImpl_getLocalHostName reverse lookup on Solaris only
Christophe, On 18/04/18 14:44, Langer, Christoph wrote: Hi Chris, our testing didn’t show regressions. Are we good to push? My testing was positive too. I am happy to see this pushed to jdk/jdk. -Chris.
RE: RFR(XS): 8201369: Inet4AddressImpl_getLocalHostName reverse lookup on Solaris only
Thank you. Pushed: http://hg.openjdk.java.net/jdk/jdk/rev/a838e3707f3a > -Original Message- > From: Chris Hegarty [mailto:chris.hega...@oracle.com] > Sent: Mittwoch, 18. April 2018 16:20 > To: Langer, Christoph > Cc: Srividya Shamaiah ; OpenJDK Network Dev list > > Subject: Re: RFR(XS): 8201369: Inet4AddressImpl_getLocalHostName reverse > lookup on Solaris only > > Christophe, > > On 18/04/18 14:44, Langer, Christoph wrote: > > Hi Chris, > > > > our testing didn’t show regressions. Are we good to push? > > My testing was positive too. > > I am happy to see this pushed to jdk/jdk. > > -Chris.
Re: RFR:8194298 Add support for per Socket configuration of TCP keepalive
Hi Chris,
On Wednesday 18 April 2018 07:44 PM, Chris Hegarty wrote:
Vyom,
On 13/04/18 10:50, vyom tewari wrote:
Hi All,
Please review the below code.
BugId : https://bugs.openjdk.java.net/browse/JDK-8194298
webrev :
http://cr.openjdk.java.net/~vtewari/8194298/webrev0.0/index.html
Here is some proposed wording for the JDK-specific extended socket
options specification.
1) Uses a consistent style across all three new options,
and is in line with existing extended options.
2) Renamed the options slightly, to improve readability
( they don't need to conform to the native option names )
3) Reordered them so the build up is more logical
4) Removed inheritance from server sockets
5) Added standard verbiage about being "platform and
system dependent
6) Added typical values. I think this is useful, as it
gives an idea to the developer, but maybe it could be
misleading. Can be dropped if there are concerns.
Can you please confirm that this is accurate, and also
will leave enough "wriggle" room when additional platform
support is added.
yes, below is perfect i will do the changes and send the updated webrev
soon. Thanks for help, writing Java doc is always harder(4x) than
writing code.
Vyom
---
/**
* Keep-Alive idle time.
*
* When the {@link java.net.StandardSocketOptions#SO_KEEPALIVE
* SO_KEEPALIVE} option is enabled, TCP probes a connection that
has been
* idle for some amount of time. The default value for this idle
period is
* system dependent, but is typically 2 hours. The {@code
TCP_KEEPIDLE}
* option can be used to affect this value for a given socket.
*
* The value of this socket option is an {@code Integer} that
is the
* number of seconds of idle time before keep-alive initiates a
probe. 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.
*
* @since 11
*/
public static final SocketOption TCP_KEEPIDLE
= new ExtSocketOption("TCP_KEEPIDLE",
Integer.class);
/**
* Keep-Alive retransmission interval time.
*
* When the {@link java.net.StandardSocketOptions#SO_KEEPALIVE
* SO_KEEPALIVE} option is enabled, TCP probes a connection that
has been
* idle for some amount of time. If the remote system does not
respond to a
* keep-alive probe, TCP retransmits the probe after some amount
of time.
* The default value for this retransmition interval is system
dependent,
* but is typically 75 seconds. The {@code TCP_KEEPINTERVAL}
option can be
* used to affect this value for a given socket.
*
* The value of this socket option is an {@code Integer} that
is the
* number of seconds to wait before retransmitting a keep-alive
probe. 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.
*
* @since 11
*/
public static final SocketOption TCP_KEEPINTERVAL
= new ExtSocketOption("TCP_KEEPINTERVAL",
Integer.class);
/**
* Keep-Alive retransmission maximum limit.
*
* When the {@link java.net.StandardSocketOptions#SO_KEEPALIVE
* SO_KEEPALIVE} option is enabled, TCP probes a connection that
has been
* idle for some amount of time. If the remote system does not
respond to a
* keep-alive probe, TCP retransmits the probe a certain number of
times
* before a connection is considered to be broken. The default
value for
* this keep-alive probe retransmit limit is system dependent, but is
* typically 8. The {@code TCP_KEEPCOUNT} option can be used to
affect
* this value for a given socket.
*
* The value of this socket option is an {@code Integer} that
is the
* maximum number of keep-alive probes to be sent. 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.
*
* @since 11
*/
public static final SocketOption TCP_KEEPCOUNT
= new ExtSocketOption("TCP_KEEPCOUNT",
Integer.class);
-Chris.
Re: RFR 8201510 : Merge TwoStacksPlainSocketImpl into DualStackPlainSocketImpl [win]
Ivan,
On 16/04/18 17:29, Ivan Gerasimov wrote:
...
WEBREV: http://cr.openjdk.java.net/~igerasim/8201510/00/webrev/
I think this is mostly good. Just one comment.
I'm not sure that this is correct.
--- OLD ---
60 String exclBindProp = AccessController.doPrivileged(
61 new GetPropertyAction("sun.net.useExclusiveBind",
""));
62 exclusiveBind = (exclBindProp.isEmpty())
63 ? true
64 : Boolean.parseBoolean(exclBindProp);
--- NEW ---
private static final boolean useExclusiveBind =
55 Boolean.parseBoolean(AccessController.doPrivileged(
56 new GetPropertyAction("sun.net.useExclusiveBind",
"true")));
Exclusive bind should be true iif:
1) it is defined and has no value, or
2) if is defined and has a value of `true`.
I thought we had tests for this, but maybe not if you are not
seeing test failures.
-Chris.
RE: RFR(XS): 8201369: Inet4AddressImpl_getLocalHostName reverse lookup on Solaris only
Thanks Chris and Christoph for your help inpushing this to jdk repo. Thanks, Srividya S From: "Langer, Christoph" To: Chris Hegarty Cc: Srividya Shamaiah , OpenJDK Network Dev list Date: 18/04/2018 08:28 PM Subject:RE: RFR(XS): 8201369: Inet4AddressImpl_getLocalHostName reverse lookup on Solaris only Thank you. Pushed: https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_jdk_rev_a838e3707f3a&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=cY5OjfQF2gZ_G00XrJYGrxPgLDHmXjFqs49sDD9oJN0&m=mg7HJqf6pBG__iOM3R1wpwOwl--BIza3SSbiETJZha8&s=m5KeejbhNWszcJHVMRC5bi01XYsQbRF7gDF8xs1pnOo&e= > -Original Message- > From: Chris Hegarty [mailto:chris.hega...@oracle.com] > Sent: Mittwoch, 18. April 2018 16:20 > To: Langer, Christoph > Cc: Srividya Shamaiah ; OpenJDK Network Dev list > > Subject: Re: RFR(XS): 8201369: Inet4AddressImpl_getLocalHostName reverse > lookup on Solaris only > > Christophe, > > On 18/04/18 14:44, Langer, Christoph wrote: > > Hi Chris, > > > > our testing didn’t show regressions. Are we good to push? > > My testing was positive too. > > I am happy to see this pushed to jdk/jdk. > > -Chris.
