RFR 8080402: File Leak in jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java

Hi everyone, Can you please review my changes for below bug. Bug: JDK-8080402 : File Leak in jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java Webrev: http://cr.openjdk.java.net/~dfuchs/vyom/8080402/webrev.01/ This change ensure that if close() fails we throw correct io

Re: RFR 8080402: File Leak in jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java

Hi All, Please find the latest diff, which contains the latest fix. http://cr.openjdk.java.net/~dfuchs/vyom/8080402/webrev.02/ Thanks, Vyom On 9/7/2015 3:48 PM, Alan Bateman wrote: On 07/09/2015 10:26, Vyom Tewari wrote: Hi everyone, Can you please review my changes for below bug. Bug

Re: RFR 8080402: File Leak in jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java

this method throws. -Chris. regards Mark On 07/09/2015 14:29, Ivan Gerasimov wrote: Thanks! It looks good to me now. Sincerely yours, Ivan On 07.09.2015 16:08, Vyom Tewari wrote: Hi All, Please find the latest diff, which contains the latest fix. http://cr.openjdk.java.net/~dfuchs/vyom/8080402

RFR 8073542 : File Leak in jdk/src/java/base/unix/native/libnet/PlainDatagramSocketImpl.c

Hi All, Please review my changes for below bug. Bug: JDK-8073542 : File Leak in jdk/src/java/base/unix/native/libnet/PlainDatagramSocketImpl.c Webrev: http://cr.openjdk.java.net/~dfuchs/vyom/8073542/webrev.00 This change ensure that if "setsocketopt" fails we close the corresponding

RFR 8144008: Setting NO_PROXY on an URLConnection is not complied with

Hi All, Please review the below fix. Bug : JDK-8144008 Setting NO_PROXY on an URLConnection is not complied with Webrev : http://cr.openjdk.java.net/~vtewari/8144008/webrev0.0/index.html Thanks, Vyom

Re: RFR 8071660 :URLPermission not handling empty method lists correctly

nor things, looks good. Thanks, -Pavel On 20 Jun 2016, at 12:36, Daniel Fuchs <daniel.fu...@oracle.com> wrote: On 17/06/16 15:09, Vyom Tewari wrote: Hi, Please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8071660/webrev0.3/index.html <http://cr.openjdk.java.net/%7Evtewa

Re: RFR 8071660 :URLPermission not handling empty method lists correctly

04:57 PM, Daniel Fuchs wrote: On 17/06/16 09:21, Vyom Tewari wrote: Hi All, Please find the new webrev(http://cr.openjdk.java.net/~vtewari/8071660/webrev0.1/index.html <http://cr.openjdk.java.net/%7Evtewari/8071660/webrev0.1/index.html>). I addressed the review comments given by Danie

Re: RFR 8114860: Behavior of java.net.URLPermission.getActions() contradicts spec

ted out? 259 static Test[] hashTests = { 260 //hashtest("http://www.foo.com/path;, "GET:X-Foo", 388644203), 261 //hashtest("http:*", "*:*", 3255810) 262 }; IMO they either have to be updates or removed altogether.

Re: RFR 8114860: Behavior of java.net.URLPermission.getActions() contradicts spec

ppo wrote: Same here. I got this only after I had a look at the history of changes. On 20 Jun 2016, at 17:53, Vyom Tewari <vyom.tew...@oracle.com> wrote: I was not expecting that hashcodetest is testing NPE by comparing the "hardcoded" hash values.

Re: RFR 8144008: Setting NO_PROXY on an URLConnection is not complied with

Hi All, Please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8144008/webrev0.1/index.html <http://cr.openjdk.java.net/%7Evtewari/8144008/webrev0.1/index.html>), i got some off line comments from Chris. Thanks, Vyom On Tuesday 14 June 2016 12:11 PM, Vyom Tewari wrote:

Re: RFR 8071660 :URLPermission not handling empty method lists correctly

n 17/06/16 13:25, Vyom Tewari wrote: Hi Daniel, thanks for review please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8071660/webrev0.2/index.html <http://cr.openjdk.java.net/%7Evtewari/8071660/webrev0.2/index.html>) . I added some more tests where base url is different. T

Re: RFR 8071660 :URLPermission not handling empty method lists correctly

Hi All, Please find the new webrev(http://cr.openjdk.java.net/~vtewari/8071660/webrev0.1/index.html ). I addressed the review comments given by Daniel. Thanks, Vyom On Sunday 12 June 2016 02:04 PM, Daniel Fuchs wrote:

Re: RFR 8150521: Test test/java/net/InetAddress/getOriginalHostName.java fails to load JavaNetInetAddressAccess from SharedSecrets

incorporated the review comment, updated webrev in place. http://cr.openjdk.java.net/~nkumar/vyom/8150521/webrev0.1/index.html Vyom On 3/2/2016 1:45 PM, Alan Bateman wrote: On 02/03/2016 07:44, vyom wrote: Hi Chris,

Re: RFR 8148609: supportedOptions() methods return a mutable set

please find the updated webrev http://cr.openjdk.java.net/~nkumar/vyom/8148609/webrev0.2/ Thanks, Vyom On 3/2/2016 2:36 PM, Chris Hegarty wrote: On 2 Mar 2016, at 08:19, Alan Bateman wrote: On

Re: RFR 8148609: supportedOptions() methods return a mutable set

i need sponsor for this fix. Vyom On 3/3/2016 2:37 PM, Alan Bateman wrote: On 03/03/2016 09:03, Chris Hegarty wrote: On 3 Mar 2016, at 05:36, Vyom Tewari <vyom.tew...@oracle.com> wrote: please find the updated webrev http://cr.openjdk.java.net/~nkumar/vyom/8148609/webrev0.2/

Re: RFR 8150521: Test test/java/net/InetAddress/getOriginalHostName.java fails to load JavaNetInetAddressAccess from SharedSecrets

i need sponsor for this fix as well. Vyom On 3/3/2016 2:34 PM, Chris Hegarty wrote: On 3 Mar 2016, at 05:33, Vyom Tewari <vyom.tew...@oracle.com> wrote: incorporated the review comment, updated webrev in place. http://cr.openjdk.java.net/~nkumar/vyom/8150521/webrev0.1/index.html

RFR 8161291: Serialization Tests for URLPermission is failing

Hi, Please review the below code change. Bug: JDK-8161291 Serialization Tests for URLPermission is failing Webrev : http://cr.openjdk.java.net/~vtewari/8161291/webrev0.0/index.html This change make sure that

RFR 8144692: HttpServer API: use of non-existant method in example in package Javadoc

Hi All, Please review below small doc fix. Bug: JDK-8144692 HttpServer API: use of non-existant method in example in package Javadoc Webrev : http://cr.openjdk.java.net/~vtewari/8144692/webrev0.0/index.html

Re: RFR 8151788: NullPointerException from ntlm.Client.type3

gentile reminder. Vyom On Thursday 30 June 2016 02:16 PM, Vyom Tewari wrote: Hi All, Please review the below simple fix. Bug: JDK-8151788 NullPointerException from ntlm.Client.type3 Webrev : http://cr.openjdk.java.net/~vtewari/8151788/webrev0.0/index.html <h

Re: RFR 8151788: NullPointerException from ntlm.Client.type3

Hi All, Please find the updated webrev(http://cr.openjdk.java.net/%7Evtewari/8151788/webrev0.1/index.html). I addressed the review comments. Thanks, Vyom On Tuesday 12 July 2016 08:25 PM, Weijun Wang wrote: On 7/12/2016 22:34, Pavel Rappo wrote: What's the difference between no security

Re: RFR 8144692: HttpServer API: use of non-existant method in example in package Javadoc

omment. Do you think it would make sense to use space after new InetSocketAddress(8000), as in every other line in this javadoc where multiple arguments passed, the space is used. Just to be consistent in formatting. Thanks. On 12 Jul 2016, at 12:36, Vyom Tewari <vyom.tew...@o

RFR 8151788: NullPointerException from ntlm.Client.type3

Hi All, Please review the below simple fix. Bug: JDK-8151788 NullPointerException from ntlm.Client.type3 Webrev : http://cr.openjdk.java.net/~vtewari/8151788/webrev0.0/index.html Thanks, Vyom

Re: RFR: 8167178 Exported elements referring to inaccessible types in java.naming

good. Thanks Vyom. -Chris. On 16 Jan 2017, at 09:10, Vyom Tewari <vyom.tew...@oracle.com> wrote: Hi All, Please review below the small fix for the issue. BugId : https://bugs.openjdk.java.net/browse/JDK-8167178 The compatibility impact is minimum as no code in JDK is currently

RFR: 8167178 Exported elements referring to inaccessible types in java.naming

Hi All, Please review below the small fix for the issue. BugId : https://bugs.openjdk.java.net/browse/JDK-8167178 The compatibility impact is minimum as no code in JDK is currently depend on it. I will file a CCC today. Thanks, Vyom ---

RFR 8075484:SocketInputStream.socketRead0 can hang even with soTimeout set

Hi All, Please review the code changes for below issue. Bug : https://bugs.openjdk.java.net/browse/JDK-8075484 webrev: http://cr.openjdk.java.net/~vtewari/8075484/webrev0.0/index.html This issue is

Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with soTimeout set

OT reuse NET_Timeout, but effectively inline its interruptible operation. Or write a variant of NET_Timeout that takes a function to execute. Rather than effectively two loops conditioned on the timeout. Disclaimer: I have not actually tried to do this, but it seems worth considering / evaluati

Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with soTimeout set

On Tuesday 06 September 2016 06:25 PM, Chris Hegarty wrote: Vyom, On 6 Sep 2016, at 10:20, Vyom Tewari <vyom.tew...@oracle.com> wrote: Hi, Please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.2/index.html <http://cr.openjdk.java.net/%7Evtewar

Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with soTimeout set

= EWOULDBLOCK))) { gettimeofday(, NULL); newtime = t.tv_sec * 1000 + t.tv_usec / 1000; _timeout -= newtime - prevtime; if(_timeout > 0){ prevtime = newtime; } } else { break; } } } return nread; e regards Mark On 29/08/2016 10:58, Vyom Tewari wrote: gentl

Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with soTimeout set

eptember 2016 01:38 AM, Dmitry Samersoff wrote: Vyom, Did you consider to use select() to calculate timeout instead of gettimeofday ? gettimeofday is affected by system time changes, so running ntpd can cause unpredictable behavior of this code. Also it's rather expensive syscall. -Dmitry On 2016-

Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with soTimeout set

sending this mail again as my laptop clock got screwed. Vyom On Thursday 08 September 2016 08:49 AM, Vyom Tewari wrote: Hi All, Please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.5/index.html <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.5/index.h

Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with soTimeout set

Original Message- From: Vyom Tewari [mailto:vyom.tew...@oracle.com] Sent: Mittwoch, 7. September 2016 18:31 To: Langer, Christoph <christoph.lan...@sap.com> Cc: net-dev@openjdk.java.net; Chris Hegarty <chris.hega...@oracle.com> Subject: Re: RFR 8075484:SocketInputStream.socketRead0

Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with soTimeout set

tTime()" will help , Just change the implementation you are done. Vyom And no "#include " would be needed in SocketInputStream.c - maybe not even now as it is. Best regards Christoph -Original Message- From: Vyom Tewari [mailto:vyom.tew...@oracle.com] Sent: Donner

Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with soTimeout set

p; ((errno == EAGAIN) || (errno == EWOULDBLOCK))) { gettimeofday(, NULL); newtime = t.tv_sec * 1000 + t.tv_usec / 1000; _timeout -= newtime - prevtime; if(_timeout > 0){ prevtime = newtime; } } else { break; } } } return nread; e regards Mark On 29/08/2016 10:58, Vyom

Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with soTimeout set

t code JPRT is clean. Thanks, Vyom On Wednesday 07 September 2016 03:18 PM, Chris Hegarty wrote: On 07/09/16 07:45, Vyom Tewari wrote: Hi Chris, Please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.3/index.html <http://cr.openjdk.java.net/%7Evtewari/8075484/

RFR 8153674: Expected SocketException not thrown when calling bind() with setReuseAddress(false)

Hi All, Please review the below code change. Bug: https://bugs.openjdk.java.net/browse/JDK-8153674 Webrev : http://cr.openjdk.java.net/~vtewari/8153674/webrev0.0/index.html This change override the

RFR 8163482: java.net.URLPermission.getActions() adds a trailing colon when header-names is empty

Hi All, Please find the spec change for below issue. BugId : https://bugs.openjdk.java.net/browse/JDK-8163482 Webrev : http://cr.openjdk.java.net/~vtewari/8163482/webrev0.0/index.html The reason of this change is

Re: RFR 8163482: java.net.URLPermission.getActions() adds a trailing colon when header-names is empty

. Now this fix (8163482) is just to alter the spec of getActions(), lines #219-220 to match the spec at line #122 and acknowledge the existing behavior. Did I get it right? yes , you are right. Vyom best regards, -- daniel On 06/10/16 08:31, Vyom Tewari wrote: Hi All, Please find the spec

Re: RFR - 8159410: InetAddress.isReachable returns true for non existing IP addresses

Hi Rob, Do you really think this extra check is required ? if (pEchoReply->Status == IP_SUCCESS + && (int)pEchoReply->RoundTripTime <= timeout) I did not found any doc(MSDN) which explains this. I think in case of IP_SUCCESS "RoundTripTime" is always less than timeout. I think similar changes

Re: RFR - 8159410: InetAddress.isReachable returns true for non existing IP addresses

way. This part of the code is a necessity though. -Rob On 21/09/16 09:48, Vyom Tewari wrote: Hi Rob, Do you really think this extra check is required ? if (pEchoReply->Status == IP_SUCCESS + && (int)pEchoReply->RoundTripTime <= timeout) I did not found any doc(MSDN) which ex

Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with soTimeout set

of it in the new webrev nor did you comment on it. Best regards Christoph -Original Message- From: net-dev [mailto:net-dev-boun...@openjdk.java.net] On Behalf Of Vyom Tewari Sent: Mittwoch, 7. September 2016 17:10 To: Chris Hegarty <chris.hega...@oracle.com> Cc: net-dev@openjdk.java.net Subject: R

Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with soTimeout set

on AIX, may be Christoph can help. Thanks, Vyom On Tuesday 06 September 2016 06:25 PM, Chris Hegarty wrote: Vyom, On 6 Sep 2016, at 10:20, Vyom Tewari <vyom.tew...@oracle.com> wrote: Hi, Please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.2/index

Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with soTimeout set

gentle reminder, please review the below code change. Vyom On Monday 22 August 2016 05:12 PM, Vyom Tewari wrote: Hi All, Please review the code changes for below issue. Bug : https://bugs.openjdk.java.net/browse/JDK-8075484 webrev: http://cr.openjdk.java.net/~vtewari/8075484

Re: RFR 8153674: Expected SocketException not thrown when calling bind() with setReuseAddress(false)

king with us. We agree that SO_RESUEADDR and SO_REUSEPORT behave the same way for MulticastSocket. There is no need to check and enable SO_REUSEPORT for this particular type of socket. SO_REUSEADDR is sufficient. Thanks, Lucy *From:*Vyom Tewari [mailto:vyom.tew...@oracle.com] *Sent:*Wednesday, S

Re: RFR 8153674: Expected SocketException not thrown when calling bind() with setReuseAddress(false)

On 14/09/2016 11:43, Chris Hegarty wrote: Vyom, On 11/09/16 08:01, Vyom Tewari wrote: Hi All, Please review the below code change. Bug: https://bugs.openjdk.java.net/browse/JDK-8153674 Webrev : http://cr.openjdk.java.net/~vtewari/8153674/webrev0.0/index.html <http://cr.openjdk.java.

RFR 8168840: InetAddress.getByName() throws java.net.UnknownHostException no such interface when used with virtual interfaces on Solaris

Hi, Please review the code changes for below issue. BugId: https://bugs.openjdk.java.net/browse/JDK-8168840 webrev : http://cr.openjdk.java.net/~vtewari/8168840/webrev0.0/index.html Thanks, Vyom

Re: [8u-dev]: Request for Review and Approval: 8075484: SocketInputStream.socketRead0 can hang even with soTimeout set

Hi Christoph, As this is not direct backport what about using the existing function "JVM_CurrentTimeMillis(env, 0);" instead of "NET_GetCurrentTime() ". When i did this code change i did not know that we already have this.If you use the existing one then you can simply remove the

Re: [8u-dev]: Request for Review and Approval: 8075484: SocketInputStream.socketRead0 can hang even with soTimeout set

Hi Christoph, Code change looks good to me, but i am not an official reviewer. Thanks, Vyom On Monday 09 January 2017 11:26 AM, Langer, Christoph wrote: Ping: Please review this backport to JDK8. *From:*Langer, Christoph *Sent:* Donnerstag, 29. Dezember 2016 10:37 *To:*

Re: RFR 8168840: InetAddress.getByName() throws java.net.UnknownHostException no such interface when used with virtual interfaces on Solaris

strcmp(name_utf, curr->name) == 0) { break; } curr = curr->next; } } Best regards Christoph -Original Message- From: net-dev [mailto:net-dev-boun...@openjdk.java.net] On Behalf Of Vyom Tewari Sent: Dienstag, 13. Dezember 2016 04:4

Re: RFR 8168840: InetAddress.getByName() throws java.net.UnknownHostException no such interface when used with virtual interfaces on Solaris

orkInterface.getByName, how do these interact? -Chris. On 21/12/16 10:20, Vyom Tewari wrote: incorporated the comments(http://cr.openjdk.java.net/~vtewari/8168840/webrev0.2/index.html <http://cr.openjdk.java.net/%7Evtewari/8168840/webrev0.2/index.html>). Thanks, Vyom On Wednesday 21 December 20

Re: RFR 8168840: InetAddress.getByName() throws java.net.UnknownHostException no such interface when used with virtual interfaces on Solaris

changes look fine as are, but maybe '250 *colonP = '\0';' would be clearer ( though I do note that we do *name_colonP = 0; elsewhere in this file ). -Chris. On 21/12/16 13:41, Vyom Tewari wrote: Hi Chris, If you create the Inet6Address using the following constructor "Inet6Address (S

Re: RFR:8170868: DefaultProxySelector should use system defaults on Windows, MacOS and Gnome

before(if NewString fails at 266) function call. Thanks, Vyom Best regards, Arno *From:*net-dev [mailto:net-dev-boun...@openjdk.java.net] *On Behalf Of *Vyom Tewari *Sent:* Mittwoch, 21. Dezember 2016 17:08 *To:* net-dev@openjdk.java.net *Subject:* Re: RFR:8170868: DefaultProxySelector sh

Re: RFR:8170868: DefaultProxySelector should use system defaults on Windows, MacOS and Gnome

Hi Arno, I suggest you to call "CHECK_NULL_RETURN" after below line in DefaultProxySelector.c // create an empty LinkedList to add the Proxy objects. + proxyList = (*env)->NewObject(env, list_class, list_ctrID); in windows/native/libnet/DefaultProxySelector.c file you remove the couple of

Re: JDK10 RFR: 8165437 Evaluate the use of gettimeofday in Networking code

the other xxx_close.c classes have the same structure. PlainSocketImpl.c has the same structure The bsd_close.c had the same kind of before and after checking but did previously and conservatively I'd keep that structure though I think it was ineffective in that case too. Thanks, Roger On 4

Re: JDK10 RFR: 8165437 Evaluate the use of gettimeofday in Networking code

On Wednesday 12 April 2017 11:05 PM, Vyom Tewari wrote: Hi Roger, thanks for review, please see my comment inline. Vyom On Wednesday 12 April 2017 08:17 PM, Roger Riggs wrote: Hi Vyom, Thanks for taking this on. I have a few comments and questions. In aix_close.c line 547 The code

JDK10 RFR: 8165437 Evaluate the use of gettimeofday in Networking code

Hi, Please review the code change for below issue. Bug: https://bugs.openjdk.java.net/browse/JDK-8165437 Webrev: http://cr.openjdk.java.net/~vtewari/8165437/webrev0.5/index.html This change will replace the "gettimeofday" to use the monotonic increasing clock(i used the existing

Re: JDK10 RFR: 8165437 Evaluate the use of gettimeofday in Networking code

ot think it is necessary to wrap it with JVM_LEAF, no? Kind Regards, Thomas On Tue, Apr 11, 2017 at 3:04 PM, Vyom Tewari <vyom.tew...@oracle.com <mailto:vyom.tew...@oracle.com>> wrote: Hi, Please review the code change for below issue. Bug: https://bugs.o

Re: JDK10 RFR: 8165437 Evaluate the use of gettimeofday in Networking code

as it is now. Thanks all, and Kind Regards, Thomas On Tue, Apr 25, 2017 at 3:31 PM, Chris Hegarty <chris.hega...@oracle.com <mailto:chris.hega...@oracle.com>> wrote: > On Tue, Apr 18, 2017 at 7:08 AM, Vyom Tewari <vyom.tew...@oracle.com <mailto:vyom.tew.

Re: JDK10 RFR: 8165437 Evaluate the use of gettimeofday in Networking code

alf of Thomas Stüfe <thomas.stu...@gmail.com <mailto:thomas.stu...@gmail.com>> *Sent:* Monday, April 24, 2017 1:07:52 PM *To:* Vyom Tewari *Cc:* net-dev *Subject:* Re: JDK10 RFR: 8165437 Evaluate the use of gettimeofday in Networking code Hi Vyom, sorry for the late response, I had vacat

Re: JDK10 RFR: 8165437 Evaluate the use of gettimeofday in Networking code

Hi David, I will look into the issue. Thanks, Vyom On Thursday 04 May 2017 06:29 AM, David Holmes wrote: please find the updated webrev(http://cr.openjdk.java.net/~vtewari/8165437/webrev0.7/index.html). This change is broken on 32-bit systems - JVM_Nanotime returns a jlong which is

RFR 8179905: Remove the use of gettimeofday in Networking code

Hi , Please review the code change for below issue. Webrev : http://cr.openjdk.java.net/~vtewari/8179905/webrev0.0/index.html BugId : https://bugs.openjdk.java.net/browse/JDK-8179905 This issue is duplicate of "JDK-8165437", where pushed code change failed on 32 bit platforms so we

Re: RFR (xxs): 8180424: Another build issue on AIX after 8034174

Hi Thomas, fix look good to me, but i am not jdk10 reviewer. Thanks, Vyom On Tuesday 16 May 2017 06:20 PM, Thomas Stüfe wrote: Hi all, may I have a review for this tiny fix: Issue: https://bugs.openjdk.java.net/browse/JDK-8180424 webrev:

Re: RFR 8179905: Remove the use of gettimeofday in Networking code

ger number too large: 7fff). Thanks, Vyom On Tuesday 09 May 2017 11:20 PM, Claes Redestad wrote: Hi, doesn't this need to consider numerical overflows, e.g., what happens if someone sets a timeout value near 0x7fffL before and after this change? /Claes On 2017-05-09 11:5

Re: RFR : 8182672: Java 8u121 on Linux intermittently returns null for MAC address

Hi Sean, with your patch as well your test case is failing on my laptop(Ubuntu16.04), when i tried to run on jdk8 i am getting below error. java.net.SocketException: No such device (ioctl(SIOCGIFHWADDR) failed) at java.net.NetworkInterface.getMacAddr0(Native Method) at

Re: RFR : 8182672: Java 8u121 on Linux intermittently returns null for MAC address

ards, Sean. On 22/06/2017 18:50, Vyom Tewari wrote: Hi Sean, with your patch as well your test case is failing on my laptop(Ubuntu16.04), when i tried to run on jdk8 i am getting below error. java.net.SocketException: No such device (ioctl(SIOCGIFHWAD

Re: RFR : 8182672: Java 8u121 on Linux intermittently returns null for MAC address

est output could be improved a bit, e.g. when it comes to an exception, the thread name could be mentioned, too. Best regards Christoph -Original Message- From: net-dev [mailto:net-dev-boun...@openjdk.java.net] On Behalf Of Seán Coffey Sent: Donnerstag, 22. Juni 2017 20:17 To: Vyom Tewari

Re: RFR : 8182672: Java 8u121 on Linux intermittently returns null for MAC address

Hi Chris, test looks good, one minor comment can be ignored, in failing case it print stack and "Exception in thread "main" java.lang.RuntimeException: Failed" both. I can see main is declared to throw Exception. Is is possible to throw exception instead of printing trace or pass this

RFR 8179602: Fix for JDK-8165437 is broken on 32-bit Linux

Hi All, Please review the below change. Webrev: http://cr.openjdk.java.net/~vtewari/8179602/webrev0.0/index.html Bugid: https://bugs.openjdk.java.net/browse/JDK-8179602 This issue is because of side effect of "JDK-8165437" where we are using "JVM_NanoTime" which returns a 64 bit jlong and

Re: JDK10 RFR: 8165437 Evaluate the use of gettimeofday in Networking code

to line 52. Thanks & Best regards Christoph *From:*net-dev [mailto:net-dev-boun...@openjdk.java.net] *On Behalf Of *Vyom Tewari *Sent:* Donnerstag, 27. April 2017 06:16 *To:* Thomas Stüfe <thomas.stu...@gmail.com>; Chris Hegarty <chris.hega...@oracle.com> *Cc:* net-dev <net-d

Re: RFR 8179602: Fix for JDK-8165437 is broken on 32-bit Linux

McMahon wrote: Hi Vyom, I notice this doesn't seem to fix the Mac OS problem. We may have to file a separate issue for that. - Michael On 04/05/2017, 09:50, Vyom Tewari wrote: Hi All, Please review the below change. Webrev: http://cr.openjdk.java.net/~vtewari/8179602/webrev0.0/index.html Bugid

RFR[10]: 8185072 network006 times out in many configs in JDK10-hs nightly

Hi, Please review, small code change below. webrev: http://cr.openjdk.java.net/~vtewari/8185072/webrev0.0/index.html BugId: https://bugs.openjdk.java.net/browse/JDK-8185072 this is regression because of "JDK-8179905". Thanks, Vyom

Re: RFR[10]: 8185072 network006 times out in many configs in JDK10-hs nightly

ping!! Vyom On Friday 15 September 2017 02:59 PM, vyom tewari wrote: Hi, Please review, small code change below. webrev: http://cr.openjdk.java.net/~vtewari/8185072/webrev0.0/index.html BugId:  https://bugs.openjdk.java.net/browse/JDK-8185072 this is regression because of "JDK-81

Re: RFR 8145635 : Add TCP_QUICKACK socket option

ping!! Vyom On Monday 11 September 2017 09:08 PM, 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

Re: RFR 8145635 : Add TCP_QUICKACK socket option

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 <vyom.tew...@oracle.com> wrote: Hi

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

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.

Re: RFR 8145635 : Add TCP_QUICKACK socket option

ready 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

Re: RFR 8145635 : Add TCP_QUICKACK socket option

" 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 <vyom.tew...@oracle.com> wrote: Hi Ch

Re: RFR 8145635 : Add TCP_QUICKACK socket option

). 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 "

Re: RFR 8145635 : Add TCP_QUICKACK socket option

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 Thanks, Vyom On Wednesday 24 February 2016 03:16 PM, Alan

Re: RFR[10]: JDK-8023649 - java.net.NetworkInterface.getInterfaceAddresses() call flow clean up

Hi Mark, Thanks for doing this, i see that "createNetworkInterface" method is getting called from multiple places in NetworkInterface.c there is pending JNI Exception at line 695 in NetworkInterface.c. I am not sure if it is safe to call "(*env)->ReleaseStringUTFChars" even if there is

Re: RFR[10]: 8187658: Bigger buffer for GetAdaptersAddresses

On Tuesday 26 September 2017 02:28 AM, Ivan Gerasimov wrote: Thank you Roger for review! On 9/25/17 11:47 AM, Roger Riggs wrote: Hi Ivan, Looks ok to me. I don't see a reason to skimp on the additional size since it is allocated and then freed immediately. The increment might as well be

Re: RFR[10]: 8185072 network006 times out in many configs in JDK10-hs nightly

will make it "manual" before pushing as we already have similar test at lower tier. Vyom Roger On 9/24/2017 1:15 PM, Chris Hegarty wrote: On 15 Sep 2017, at 10:29, vyom tewari <vyom.tew...@oracle.com> wrote: Hi, Please review, small code change below. webrev: http://cr.

Re: RFR 8145635 : Add TCP_QUICKACK socket option

Hegarty wrote: Vyom, On 11 Sep 2017, at 16:38, vyom tewari <vyom.tew...@oracle.com> 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/~v

Re: RFR:8190843 can not set/get extendedOptions to ServerSocket

Hi Doychin, Thanks for review, i will fix it before pushing. Thanks, Vyom On Thursday 23 November 2017 03:01 PM, Doychin Bondzhev wrote: Hi Vyom, There is a typo in the comment : whis is not applicable Should be "which" On 23.11.2017 г. 11:20, vyom tewari wrote: Hi Chri

Re: RFR:8190843 can not set/get extendedOptions to ServerSocket

wrote: Vyom, On 16/11/17 09:03, vyom tewari wrote: Hi All, Please review the small code change for the below issue. Webrev : http://cr.openjdk.java.net/~vtewari/8190843/webrev0.0/index.html BugId    : https://bugs.openjdk.java.net/browse/JDK-8190843 In this code change, i removed

Re: RFR:8190843 can not set/get extendedOptions to ServerSocket

. Please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8190843/webrev0.2/index.html). Thanks, Vyom On Thursday 23 November 2017 06:04 PM, Chris Hegarty wrote: On 23 Nov 2017, at 09:20, vyom tewari <vyom.tew...@oracle.com> wrote: Hi Chris, Thanks for the review, please

RFR:8190843 can not set/get extendedOptions to ServerSocket

Hi All, Please review the small code change for the below issue. Webrev : http://cr.openjdk.java.net/~vtewari/8190843/webrev0.0/index.html BugId    : https://bugs.openjdk.java.net/browse/JDK-8190843 In this code change, i removed the check(getSocket() == null) which will always be

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

Re: RFR:8194298 Add support for per Socket configuration of TCP keepalive

ns = new HashSet<>();) in ExtendedSocketOptions.java Thanks, Vyom On Sunday 13 May 2018 12:37 PM, Alan Bateman wrote: On 12/05/2018 10:21, vyom tewari wrote: : Thanks for review, please find the updated webrev(http://cr.openjdk.java.net/~vtewari/8194298/webrev0.4/index.html). I've skimmed through this webrev.

Re: RFR(XS): 8202181: Correctly specify size of hostname buffer in Unix Inet*AddressImpl_getLocalHostName implementations

://pubs.opengroup.org/onlinepubs/009695399/functions/gethostname.html [3] http://man7.org/linux/man-pages/man3/getnameinfo.3.html [4] http://pubs.opengroup.org/onlinepubs/9699919799/functions/getnameinfo.html -Original Message- From: vyom tewari [mailto:vyom.tew...@oracle.com] Sent: Freitag, 27. April

Re: RFR(XS): 8202181: Correctly specify size of hostname buffer in Unix Inet*AddressImpl_getLocalHostName implementations

On Friday 27 April 2018 10:58 AM, Thomas Stüfe wrote: On Fri, Apr 27, 2018 at 5:57 AM, vyom tewari <vyom.tew...@oracle.com> wrote: Hi Christoph, On Tuesday 24 April 2018 04:45 PM, Langer, Christoph wrote: Hi Vyom, I think, it is intentional to handle case where return &qu

Re: RFR:8194298 Add support for per Socket configuration of TCP keepalive

April 2018 07:26 PM, Chris Hegarty wrote: On 23/04/18 13:34, Alan Bateman wrote: On 23/04/2018 13:05, vyom tewari wrote: Hi, Please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8194298/webrev0.1/index.html). I incorporated  most of the review comments. This looks much better

Re: RFR:8194298 Add support for per Socket configuration of TCP keepalive

ted "if-else" then linear ifs :)  fixed as well. Nit:  please place the equal sign at line 172 consistently with the other two inits above. fixed. With kind regards, Ivan On 5/11/18 7:43 PM, vyom tewari wrote: thanks all for review, please find the latest webrev(http://cr.op

Re: RFR:8194298 Add support for per Socket configuration of TCP keepalive

sired capacity and then make unmodifiable set with Set.copyOf(list). No further comments from my side :) if no further comment from others as well, i will change it to use default constructor at time of pushing. Thanks, Vyom With kind regards, Ivan On 5/12/18 2:21 AM, vyom tewari wrote: H

Re: RFR:8194298 Add support for per Socket configuration of TCP keepalive

wrote: On 10/05/2018 16:21, vyom tewari wrote: Hi, Please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8194298/webrev0.2/index.html) ... It would be better if the channel implementation didn't static import ExtendedSocketOptions.getInstance as that is a very generic method metho

Re: RFR:8194298 Add support for per Socket configuration of TCP keepalive

Hi, Please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8194298/webrev0.6/index.html). I renamed the macosx files to "MacOSXSocketOptions.java". Our internal tests are clean. Thanks, Vyom On Tuesday 15 May 2018 03:13 PM, Alan Bateman wrote: On 15/05/2018 08:35, Langer,

Re: RFR:8194298 Add support for per Socket configuration of TCP keepalive

On Tuesday 15 May 2018 03:13 PM, Alan Bateman wrote: On 15/05/2018 08:35, Langer, Christoph wrote: I’m asking because I’m planning to add some AIX options and will have to choose a name for this implementation eventually. @Alan: What do you think? Yes, I agree it should be renamed. Vyom

Re: RFR 8203369 : Check for both EAGAIN and EWOULDBLOCK error codes

On Friday 25 May 2018 11:19 AM, Ivan Gerasimov wrote: Hi Wiijun! On 5/24/18 10:13 PM, Weijun Wang wrote: On May 25, 2018, at 11:58 AM, Ivan Gerasimov wrote: I also wonder whether a smart compiler might not flag code where the errors do infact have the same

Re: RFR 8202558 : Access to freed memory in java.base/unix/native/libnet/net_util_md.c

Hi Ivan, the url(http://cr.openjdk.java.net/~igerasim/8202558/00/webrev/ ) is not accessible to me. Thanks, Vyom On Thursday 03 May 2018 01:51 AM, Ivan Gerasimov wrote: I just realized that we've got a similar issue in the same file in the function initLocalIfs(). The webrev was updated

Re: RFR:8194298 Add support for per Socket configuration of TCP keepalive

Original Message- From: net-dev [mailto:net-dev-boun...@openjdk.java.net] On Behalf Of vyom tewari Sent: Montag, 23. April 2018 14:06 To: Chris Hegarty <chris.hega...@oracle.com>; OpenJDK Network Dev list <net-dev@openjdk.java.net> Subject: Re: RFR:8194298 Add support for per Socket config

  1   2   >