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 exceptio

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

. 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/webrev.02/ Thanks,

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 fd

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, T

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 02/03/2016 06:47, vyom wrote:

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 wrote: please find the updated webrev http://cr.openjdk.java.net/~nkumar/vyom/8148609/webrev0.2/ <http://cr.openjdk.java.

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 wrote: incorporated the review comment, updated webrev in place. http://cr.openjdk.java.net/~nkumar/vyom/8150521/webrev0.1/index.html <http://cr.openjdk.java.

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 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

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: Hi

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 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. Than

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

ping! On Saturday 11 June 2016 10:34 AM, vyom wrote: Hi All, Please review the below fix. Bug : JDK-8114860 Behavior of java.net.URLPermission.getActions() contradicts spec Webrev : http://cr.openjdk.java.net/~vtewari/8114860/webrev0.0/index.html

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

nes commented 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

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

longer be tested. What was the problem with these hashCodes? Did they become different after the fix? If so, let's address it. As I understand the original issue, values do not matter, what matters is that there's no NPE thrown in these cases. Thanks, -Pavel On 20 Jun 20

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 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

Vyom Tewari wrote: 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

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

se minor things, looks good. Thanks, -Pavel On 20 Jun 2016, at 12:36, Daniel Fuchs 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/%7Evtewari/8071660/webrev0.3/index.

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

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 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 wrote: Hi All,

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

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 colo

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 SocketInputS

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 8075484:SocketInputStream.socketRead0 can hang even with soTimeout set

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

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

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

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

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

stent with the existing code. Thanks, Vyom On Friday 02 September 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 o

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 wrote: Hi, Please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.2/index.html <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.2/index.html>).

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 wrote: Hi, Please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.2/index.html <http://cr.openjdk

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/

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

n 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 Cc: net-dev@openjdk.java.net Subject: Re: RFR 80

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

ph -Original Message- From: Vyom Tewari [mailto:vyom.tew...@oracle.com] Sent: Mittwoch, 7. September 2016 18:31 To: Langer, Christoph Cc: net-dev@openjdk.java.net; Chris Hegarty Subject: Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with soTimeout set Hi Chris, Sorry I

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

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

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 "get/setReuseAd

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

any comment on latest webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.5/index.html <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.5/index.html>) ? Vyom On Thursday 08 September 2016 03:13 PM, Vyom Tewari wrote: On Thursday 08 September 2016 02:50 PM, Langer, Chr

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

pushed. http://hg.openjdk.java.net/jdk9/dev/jdk/rev/af17b6bc08dd Vyom On Tuesday 13 September 2016 02:17 PM, Chris Hegarty wrote: Vyom, On 13 Sep 2016, at 04:00, Vyom Tewari wrote: any comment on latest webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.5/index.html) ? I am

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 8153674: Expected SocketException not thrown when calling bind() with setReuseAddress(false)

om has proposed, in the webrev. I would like to explore an alternative, so see what it would look like. -Chris. regards Mark 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:

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

at 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, September 28, 2016 1:26 AM

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 a

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

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: RFR 8168840: InetAddress.getByName() throws java.net.UnknownHostException no such interface when used with virtual interfaces on Solaris

if (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. Deze

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

- From: net-dev [mailto:net-dev-boun...@openjdk.java.net] On Behalf Of Vyom Tewari Sent: Mittwoch, 21. Dezember 2016 09:51 Cc: net-dev Subject: Re: RFR 8168840: InetAddress.getByName() throws java.net.UnknownHostException no such interface when used with virtual interfaces on Solaris Hi All, Ple

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

rkInterface.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 Decemb

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

es sense. Your 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 followin

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 "CHE

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 should

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 "NET_GetCurr

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:* net-dev@openjdk.jav

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 --- a/src/java.naming/share/classes/javax/naming/Compo

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 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 depend on it. I will file a CCC

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 functio

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

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

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

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

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 <mailto:vyom.tew...@oracle.com>> wrote: Hi, Please review the code change for below issue. Bug: https://bugs.openjdk.java.net/browse/JDK-8165437 &l

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

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

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

.@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 vacation. Thanks for taking my suggestions! Here some remarks: --- I

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 ; Chris Hegarty *Cc:* net-dev *Subject:* Re: JDK10 RFR: 8165437 Evaluate the use of gettimeofday in N

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 alwa

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

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

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 rever

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

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: http://cr.openjdk.java.net/~stuefe/webrevs/8180424-

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 java.net.Netwo

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

x27;ll take another look. regards, 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 (i

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

Furthermore, the test 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 2

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 except

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 Ba

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 pendin

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[10]: 8185072 network006 times out in many configs in JDK10-hs nightly

ew, i 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 wrote: Hi, Please review, small code change below. webrev: http://cr.openjdk.java.net/~vtewari/81

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 8145635 : Add TCP_QUICKACK socket option

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

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

ot;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,

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 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

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 th

Re: RFR 8145635 : Add TCP_QUICKACK socket option

ve 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

Re: RFR 8145635 : Add TCP_QUICKACK socket option

eviewed from my end. No need for further webrev... Best regards Christoph -Original Message- From: net-dev [mailto:net-dev-boun...@openjdk.java.net] On Behalf Of vyom tewari Sent: Dienstag, 17. Oktober 2017 10:37 To: net-dev@openjdk.java.net Subject: Re: RFR 8145635 : Add TCP_QUICKACK sock

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: 8189366: SocketInputStream.available() should check for eof

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: 8

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 t

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

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 Chris,

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 wrote: Hi Chris, Thanks for the review, please find the latest w

RFR: 8194676 NullPointerException is thrown if ipaddress is not set

Hi, Please review below code change for simple fix. Webrev: http://cr.openjdk.java.net/~vtewari/8194676/webrev0.0/index.html BudID: https://bugs.openjdk.java.net/browse/JDK-8194676 The code change will fix the unintentional NullPointerException. If ip address is not set, while de-serializatio

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

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 Currently Java supports SO_KEEPALIVE, whose default value is 7200 seconds which is too long for most of the applications.

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

ALIVE_VALS* for a socket, MSDN says that WSAIoctl output buffer is not used. Thanks, Vyom Gruss Bernd Gruss Bernd -- http://bernd.eckenfels.net *From:* net-dev on behalf of vyom tewari *Sent:* Friday, April 13, 2018 11:50

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

On Sunday 15 April 2018 01:33 PM, Alan Bateman wrote: On 14/04/2018 08:09, Alan Bateman wrote: : Can you update SocketChannel/SocketOptionTests.java to ensure that SocketChannel is test? We also need to ensure that the new options don't show up in the supportedOptions returned by the channe

  1   2   >