Re: RFR: 8287237: (fs) Files.probeContentType returns null if filename contains hash mark on Linux [v4]

On Tue, 31 May 2022 18:29:30 GMT, Brian Burkhalter wrote: >> Modify `sun.net.www.MimeTable.findByFileName(String)` to attempt to find the >> file extension in the entire file name if it is not found in the portion of >> the name preceding the optional fragment beginning with a hash (`#`). > > B

Re: RFR: JDK-8243376: java.net.SocketPermission.implies(Permission p) spec is mismatching with implementation [v9]

On Wed, 10 Mar 2021 17:32:30 GMT, Jayashree S Kumar wrote: >> Issue >> >> https://bugs.openjdk.java.net/browse/JDK-8243376 >> >> Problem >> >> The scenario is: >> - Some specified target hostname resolves to two IP addresses (always the >> same address pair). >> - The DNS resolved order of

Re: RFR: 8260428: Drop support for pre JDK 1.4 DatagramSocketImpl implementations [v3]

On Thu, 21 Oct 2021 16:47:44 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my changes (and CSR) to drop support for pre JDK >> 1.4 `DatagramSocketImpl` implementations? >> >> These changes propose to drop support for `DatagramSocketImpls` that were >> compiled with J

Re: RFR: 8274779: HttpURLConnection: HttpClient and HttpsClient incorrectly check request method when set to POST [v4]

On Tue, 19 Oct 2021 13:48:24 GMT, Evan Whelan wrote: >> Hi, >> >> Please review my fix for JDK-8274779 which changes how HttpClient and >> HttpsClient checks for equality when comparing request methods. >> >> When `HttpURLConnection.setRequestMethod` is passed `new String("POST")` >> rather

Re: RFR: 8260428: Drop support for pre JDK 1.4 DatagramSocketImpl implementations

On Mon, 11 Oct 2021 09:42:12 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my changes (and CSR) to drop support for pre JDK > 1.4 `DatagramSocketImpl` implementations? > > These changes propose to drop support for `DatagramSocketImpls` that were > compiled with JDK 1.3

Re: RFR: 8274949: Use String.contains() instead of String.indexOf() in java.base

On Fri, 17 Sep 2021 08:56:47 GMT, Andrey Turbanov wrote: > String.contains was introduced in Java 5. > Some code in java.base still uses old approach with `String.indexOf` to check > if String contains specified substring. > I propose to migrate such usages. Makes code shorter and easier to rea

Re: RFR: 8270903: sun.net.httpserver.HttpConnection: Improve toString

On Thu, 29 Jul 2021 10:22:51 GMT, Julia Boes wrote: > This is a minor change that updates > `sun.net.httpserver.HttpConnection::toString` to never return null. > > Testing: tier 1-3 all clear Looks good. - Marked as reviewed by vtewari (Committer). PR: https://git.openjdk.java.n

Re: RFR: 8263531: Remove unused buffer int

On Mon, 12 Jul 2021 20:39:53 GMT, Christoph Langer wrote: > The change for JDK-8257001 left an obsolete int field. Remove it. Marked as reviewed by vtewari (Committer). - PR: https://git.openjdk.java.net/jdk/pull/4759

Re: RFR: 8269993: [Test]: java/net/httpclient/DigestEchoClientSSL.java contains redundant @run tags

On Wed, 7 Jul 2021 09:34:13 GMT, Thejasvi Voniadka wrote: > Hi, > > Please review this simple change to remove redundancy of @run tags. The test > "java/net/httpclient/DigestEchoClientSSL.java" contains a couple of redundant > @run tags: > > * @run main/othervm/timeout=300 > * DigestEchoCl

Re: [jdk17] RFR: 8269772: [macos-aarch64] test compilation failed with "SocketException: No buffer space available"

On Mon, 5 Jul 2021 11:21:39 GMT, Daniel Fuchs wrote: > Please find here a trivial fix for: > > 8269772: [macos-aarch64] test compilation failed with "SocketException: No > buffer space available" > > Running several of the websocket tests concurrently on some of the CI > machines is causing r

Re: RFR: 8267938: (sctp) SCTP channel factory methods should check platform support

On Fri, 28 May 2021 13:11:43 GMT, Chris Hegarty wrote: > The SCTP channel factory methods, namely SctpChannel::open, > SctpServerChannel::open, and SctpMultiChannel::open, are specified to throw > UnsupportedOperationException, if the SCTP protocol is not supported. > Currently, underlying pla

Re: RFR: 8264824: java/net/Inet6Address/B6206527.java doesn't close ServerSocket properly [v2]

On Tue, 13 Apr 2021 10:30:18 GMT, Conor Cleary wrote: >> ### Description >> `Inet6Address/B6206527.java` test creates two instances of ServerSocket, >> both of which are explicity bound to a Link-Local address. Neither of the >> ServerSocket instances are explicitly closed meaning there is no g

Re: RFR: 8263905: Remove finalize methods for SocketInput/OutputStream

On Mon, 22 Mar 2021 06:02:37 GMT, Kim Barrett wrote: > Please review this change to java.net.SocketInputStream and > java.net.SocketOutputStream, removing their "finalize" methods. These > methods are empty. Their purpose is to override and suppress the finalize > methods of their superclasses

Re: RFR: JDK-8243376: java.net.SocketPermission.implies(Permission p) spec is mismatching with implementation [v6]

On Fri, 5 Mar 2021 15:08:10 GMT, Michael McMahon wrote: >> Jayashree S Kumar has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Code Review: Incorporated Indention correction, added getIP and updated >> try-catch inside for loop > > Change

Integrated: JDK-8260925: HttpsURLConnection does not work with other JSSE provider.

On Tue, 16 Feb 2021 07:50:05 GMT, Vyom Tewari wrote: > HttpsURLConnection, works with SunJSSE provider but does not work with other > JSSE provider. In case of SunJSSE , HttpsURLConnection set the host name as > follows > > s = (SSLSocket)serverSocket; >if (s instan

Re: RFR: JDK-8260925: HttpsURLConnection does not work with other JSSE provider. [v5]

On Thu, 4 Mar 2021 00:27:52 GMT, Xue-Lei Andrew Fan wrote: >> Vyom Tewari has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - resolve jcheck issue. >> - put if block which will prevent host being set twic

Re: RFR: JDK-8260925: HttpsURLConnection does not work with other JSSE provider.

On Wed, 3 Mar 2021 15:20:29 GMT, Vyom Tewari wrote: >> Vyom, can you provide, or point to a test that exercises the code paths that >> have been changed? And also some new test that would fail before the fix and >> pass after? >> >> best regards, >> >

Re: RFR: JDK-8260925: HttpsURLConnection does not work with other JSSE provider. [v6]

tImpl)s).setHost(host); >} > > But in case of other providers(BouncyCastleProvider ) host will not get set > and "java.security.cert.CertificateException: No subject alternative name > found matching IP address" exception will be thrown. Vyom Tewari has updated the pull req

Re: RFR: JDK-8260925: HttpsURLConnection does not work with other JSSE provider. [v4]

On Wed, 3 Mar 2021 16:16:48 GMT, Xue-Lei Andrew Fan wrote: >> Vyom Tewari has updated the pull request incrementally with one additional >> commit since the last revision: >> >> reverted the overly deleted else block > > src/java.base/share/classes/sun/net/www/p

Re: RFR: JDK-8260925: HttpsURLConnection does not work with other JSSE provider. [v5]

tImpl)s).setHost(host); >} > > But in case of other providers(BouncyCastleProvider ) host will not get set > and "java.security.cert.CertificateException: No subject alternative name > found matching IP address" exception will be thrown. Vyom Tewari has updated the pull requ

Re: RFR: JDK-8260925: HttpsURLConnection does not work with other JSSE provider.

On Wed, 3 Mar 2021 10:09:34 GMT, Daniel Fuchs wrote: > Vyom, can you provide, or point to a test that exercises the code paths that > have been changed? And also some new test that would fail before the fix and > pass after? > > best regards, > > -- daniel Hi Daniel, there are multiple test

Re: RFR: JDK-8260925: HttpsURLConnection does not work with other JSSE provider. [v4]

tImpl)s).setHost(host); >} > > But in case of other providers(BouncyCastleProvider ) host will not get set > and "java.security.cert.CertificateException: No subject alternative name > found matching IP address" exception will be thrown. Vyom Tewari has updated the pull req

Re: RFR: JDK-8260925: HttpsURLConnection does not work with other JSSE provider. [v2]

On Wed, 3 Mar 2021 11:36:19 GMT, Vyom Tewari wrote: >> src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java line >> 454: >> >>> 452: s = (SSLSocket)factory.createSocket(serverSocket, >>> 453:

Re: RFR: JDK-8260925: HttpsURLConnection does not work with other JSSE provider. [v2]

On Wed, 3 Mar 2021 10:05:24 GMT, Daniel Fuchs wrote: >> Vyom Tewari has updated the pull request incrementally with one additional >> commit since the last revision: >> >> used List.of instead of Collections.singletonList > > src/java.base/share/clas

Re: RFR: JDK-8260925: HttpsURLConnection does not work with other JSSE provider. [v3]

tImpl)s).setHost(host); >} > > But in case of other providers(BouncyCastleProvider ) host will not get set > and "java.security.cert.CertificateException: No subject alternative name > found matching IP address" exception will be thrown. Vyom Tewari has updated the pull req

Re: RFR: JDK-8260925: HttpsURLConnection does not work with other JSSE provider.

On Wed, 3 Mar 2021 05:01:13 GMT, Vyom Tewari wrote: >>> HttpsURLConnection, works with SunJSSE provider but does not work with >>> other JSSE provider. In case of SunJSSE , HttpsURLConnection set the host >>> name as follows >>> >>> s =

Re: RFR: JDK-8260925: HttpsURLConnection does not work with other JSSE provider.

On Wed, 3 Mar 2021 04:38:47 GMT, Xue-Lei Andrew Fan wrote: > > HttpsURLConnection, works with SunJSSE provider but does not work with > > other JSSE provider. In case of SunJSSE , HttpsURLConnection set the host > > name as follows > > s = (SSLSocket)serverSocket; > > if (s instanceof SSLSocket

Re: RFR: JDK-8260925: HttpsURLConnection does not work with other JSSE provider. [v2]

On Tue, 2 Mar 2021 20:17:25 GMT, Xue-Lei Andrew Fan wrote: >> Vyom Tewari has updated the pull request incrementally with one additional >> commit since the last revision: >> >> used List.of instead of Collections.singletonList > > src/java.base/share/clas

Re: RFR: JDK-8260925: HttpsURLConnection does not work with other JSSE provider. [v2]

tImpl)s).setHost(host); >} > > But in case of other providers(BouncyCastleProvider ) host will not get set > and "java.security.cert.CertificateException: No subject alternative name > found matching IP address" exception will be thrown. Vyom Tewari has updated the pull req

Re: RFR: JDK-8260925: HttpsURLConnection does not work with other JSSE provider.

On Tue, 2 Mar 2021 15:56:35 GMT, Daniel Fuchs wrote: >> i ran tests, it looks >> clean(https://github.com/vyommani/jdk/actions/runs/612949667) > > As far as I know this is only tier1 - so none of the network tests have been > run. I ran tier1 & tier2 tests locally on my linux vm, it was clear.

Re: RFR: JDK-8260925: HttpsURLConnection does not work with other JSSE provider.

On Tue, 2 Mar 2021 15:03:47 GMT, Daniel Fuchs wrote: >> May be i am not sure, we may need this code change to review by security >> expert. I am setting "SNIHostName" only if "isDefaultHostnameVerifier" is >> true(If the HNV is the default from HttpsURLConnection) so there should not >> be pro

Re: RFR: JDK-8260925: HttpsURLConnection does not work with other JSSE provider.

On Tue, 2 Mar 2021 12:43:27 GMT, Daniel Fuchs wrote: >> HttpsURLConnection, works with SunJSSE provider but does not work with other >> JSSE provider. In case of SunJSSE , HttpsURLConnection set the host name as >> follows >> >> s = (SSLSocket)serverSocket; >>if (s instanceof SSLSocketImpl

Re: RFR: 8252831: Correct "no comment" warnings in jdk.net module

On Tue, 2 Mar 2021 10:15:13 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my changeset that fixes the "no comment" warnings > generated by `javadoc -Xdoclint` for `java.base/jdk.net`? > > Kind regards, > Patrick LGTM - Marked as reviewed by vtewari (Commit

RFR: JDK-8260925: HttpsURLConnection does not work with other JSSE provider.

HttpsURLConnection, works with SunJSSE provider but does not work with other JSSE provider. In case of SunJSSE , HttpsURLConnection set the host name as follows s = (SSLSocket)serverSocket; if (s instanceof SSLSocketImpl) { ((SSLSocketImpl)s).setHost(host); } But in case of oth

Re: RFR:8046500 GetIpAddrTable function failed on Pure Ipv6 environment

, vyom tewari wrote: Hi Chris, Thanks for review, please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8046500/webrev0.1/index.html) where i incorporated your suggestion. Now i am returning the different error code(-2) if IP Helper Library function GetIfTable fails. I checked the all

Re: RFR:8046500 GetIpAddrTable function failed on Pure Ipv6 environment

reseeding again,  looks like some problem with my email client. Vyom On 13/11/18 6:05 PM, vyom tewari wrote: Hi Chris, Thanks for review, please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8046500/webrev0.1/index.html) where i incorporated your suggestion. Now i am returning

Re: RFR:8046500 GetIpAddrTable function failed on Pure Ipv6 environment

sites and we don't need to do any additional changes. Thanks, Vyom On 08/11/18 6:19 PM, Chris Hegarty wrote: Hi Vyom, On 08/11/18 09:22, vyom tewari wrote: Hi, Please review the below code change. Webrev: http://cr.openjdk.java.net/~vtewari/8046500/webrev0.0/index.html enumInterface

RFR:8046500 GetIpAddrTable function failed on Pure Ipv6 environment

Hi, Please review the below code change. Webrev: http://cr.openjdk.java.net/~vtewari/8046500/webrev0.0/index.html BugId:  https://bugs.openjdk.java.net/browse/JDK-8046500 This issue is specific to pure ipv6 environment, In pure ipv6 environment  if "enumInterface" fails,  i am clearing th

RFR:8212114 Reconsider the affect on closed streams resulting from 8189366

Hi All, Please review the below fix. Webrev: http://cr.openjdk.java.net/~vtewari/8212114/webrev0.0/index.html bugId: https://bugs.openjdk.java.net/browse/JDK-8212114 this change the revert the effect of JDK-8189366,  restore the existing(SocketInputStream:available() will throw the socketExce

Re: RFR: 8189366: SocketInputStream.available() should check for eof

sure, i will send the webrev  soon. Vyom On Wednesday 17 October 2018 04:31 PM, Chris Hegarty wrote: On 12/10/18 12:58, Daniel Fuchs wrote: ... int available = impl.available(); return eof ? 0 : available; addresses the issue of available potentially returning garbage after EOF wh

Re: RFR: 8189366: SocketInputStream.available() should check for eof

s correct. While not intuitive, I don't propose that we change this. ( if this were a new implementation then I think it should throw IOE for this scenario, but we are where we are ). -Chris. best regards, -- daniel On 12/10/2018 09:55, Chris Hegarty wrote: On 12/10/18 08:29, Alan Batema

Re: [12] RFR 8187522: sun/net/ftp/FtpURLConnectionLeak.Java timed out

On Thursday 11 October 2018 02:15 PM, Chris Yin wrote: Please review below small change to fix test sun/net/ftp/FtpURLConnectionLeak.Java, thanks Besides the original timeout issue, looks like the test not working as expected even the results is pass. Per test description, we expect FileNot

Re: RFR: 8189366: SocketInputStream.available() should check for eof

Hi Chris, Thanks for review, please find the updated webrev(http://cr.openjdk.java.net/~vtewari/8189366/webrev0.1/index.html) where i included the test. Thanks, Vyom On Wednesday 10 October 2018 09:50 PM, Chris Hegarty wrote: Vyom, On 10/10/18 14:16, vyom tewari wrote: Hi All, Please

Re: RFR: 8189366: SocketInputStream.available() should check for eof

Hi All, Please provide your review comments on below fix. Thanks, Vyom On Friday 27 October 2017 11:31 AM, vyom tewari wrote: 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

Re: [openjdk-x] Bind to a multicast address fails

Hi Alan,Chris, I imported the Andre's patch and our all existing internal tests are clean. Thanks, Vyom On Monday 10 September 2018 10:58 PM, Chris Hegarty wrote: On 10/09/18 15:35, Chris Hegarty wrote: ... Maybe the native implementation of these methods can be updated to accept a scope,

Re: [openjdk-x] Bind to a multicast address fails

On Monday 10 September 2018 12:28 PM, Andre Naujoks wrote: On 9/9/18 9:16 AM, Alan Bateman wrote: On 07/09/2018 13:22, Andre Naujoks wrote: : I have not tried joining IPv4 groups on an IPv6 socket through java, since we do not use IPv4 at all in this particular environment. I have tried sett

Re: RFR: 8172346 sun.net.ftp.FtpDirEntry.setCreated(Date) may expose internal represent

Hi Chris, Thanks for review, please find my comment inline. Thanks, Vyom On Tuesday 24 July 2018 06:54 PM, Chris Hegarty wrote: On 24 Jul 2018, at 10:55, vyom tewari wrote: Hi All, Please review below a trivial fix. Webrev : http://cr.openjdk.java.net/~vtewari/8172346/webrev0.0

RFR: 8172346 sun.net.ftp.FtpDirEntry.setCreated(Date) may expose internal represent

Hi All, Please review below a trivial fix. Webrev : http://cr.openjdk.java.net/~vtewari/8172346/webrev0.0/index.html BugID: https://bugs.openjdk.java.net/browse/JDK-8172346 The above code change will avoid storing the externally mutable object reference into FtpDirEntry. Thanks, Vyom

Re: RFR : 8205959 : Do not restart close if errno is EINTR

Hi Ivan, code changes looks good to me, although i am not the official reviewer. Thanks, Vyom On Thursday 28 June 2018 04:45 AM, Ivan Gerasimov wrote: Hello! When closing a socket via NET_SocketClose(int fd), a close(fd) is called. The later is wrapped in a retry-loop, which is wrong becaus

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 value: if (errno == 11 || e

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&MacOSXSocketOptions.c". Our internal tests are clean. Thanks, Vyom On Tuesday 15 May 2018 03:13 PM, Alan Bateman wrote: On 15/05/201

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:8194298 Add support for per Socket configuration of TCP keepalive

dSocketOptions.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. The spec fo

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

ity 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: Hi Ivan,

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

omplex nested "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(ht

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

, 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 method name. As I ment

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 but

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(XS): 8202181: Correctly specify size of hostname buffer in Unix Inet*AddressImpl_getLocalHostName implementations

http://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.

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 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 "hostname" is to large to fit in

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

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 "hostname" is to large to fit in  array.  if you see the man page(http://man7.org/linux/man- pages/man2/gethostname.2.html) it says that it is unspecified

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 ; OpenJDK Network Dev list Subject: Re: RFR:8194298 Add support for per Socket configuration of TCP keepalive Hi, Please find t

Re: RFR 8202154 : Remove unused code in java.base/windows/native/libnet

On Tuesday 24 April 2018 10:12 PM, Ivan Gerasimov wrote: Hi Vyom! On 4/23/18 11:29 PM, vyom tewari wrote: Hi Ivan, code looks good to me, thanks for doing this cleanup. One minor comment, in PortConfig.java you can make defaultUpper& defaultLower as final. Yes, of course,

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

Hi Alan, Thanks for review comments, please find my answers inline. Vyom On Monday 23 April 2018 06:04 PM, 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

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

On Tuesday 24 April 2018 03:08 PM, Langer, Christoph wrote: Hi, please help reviewing a small change that I stumbled over when looking into the getLocalHostName implementation. I found that the length of the hostname buffer is not correctly passed to sub functions. The buffer size is speci

Re: RFR 8202154 : Remove unused code in java.base/windows/native/libnet

Hi Ivan, code looks good to me, thanks for doing this cleanup. One minor comment, in PortConfig.java you can make defaultUpper& defaultLower as final.I see that Microsoft changed dynamic port range recently do we need to put some comment in PortConfig.java ? Thanks, Vyom On Tuesday 24 Apri

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.1/index.html). I incorporated  most of the review comments. Thanks, Vyom 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

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

Re: RFR 8194260, Point-to-point interface should be excluded from java/net/ipv6tests/*

Hi Felix, latest code looks good to me, personally i prefer to throw exception instead returning null, but i can see that old code was also returning null. Hopping the code which invokes getFirstLocalIPv4Address, getFirstLocalIPv6Addres already taken care of null. Thanks, Vyom On Wednesda

Re: RFR 8194260, Point-to-point interface should be excluded from java/net/ipv6tests/*

Hi Felix, Looks good to me, minor bit, please fix the tag order in all the tests, @summary should come immediately after @bug. In Tests.java there are unused imports(import java.net.*, java.io.*) can you please change it to use explicit classes. Thanks, Vyom On Tuesday 17 April 2018 09:04 A

Re: RFR(XS): 8201369: Inet4AddressImpl_getLocalHostName reverse lookup on Solaris only

looks good to me, As Christoph already mentioned just update the copyright date. Vyom On Monday 16 April 2018 02:14 PM, Srividya Shamaiah wrote: Hi Chris, Please review the attached patch in http://cr.openjdk.java.net/~mhorie/8201369/webrev/

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1   2   >