Re: [PATCH] SOCK_CLOEXEC for opening sockets
> On 19 Jul 2018, at 18:41, Andrew Luo > wrote: > > Just checking - is there any other changes that I should make to the patch, > or anything else you guys need me to do? A webrev genderated from Andrew’s patch along with: 1) some additional includes of “net_util_md.h” in several missing places in the jdk.net module’s source, as well as the appropriate make change: EXTRA_HEADER_DIRS := \ java.base:libnet, 2) simplified the ifdef structure for NET_Socket and NET_SocketPair in net_util_md.c, and some comment updates, to make it more readable. http://cr.openjdk.java.net/~chegar/8207335/webrev.00/ This successfully passes some preliminary testing, but I will need someone to build / test on AIX. -Chris. P.S. The mailing list seems to have dropped the initial space on the context lines of Andrew’s patch, which I had to restore before it would apply cleanly.
Connection timeouts in JEP 321 (HTTP Client)
Somebody pointed me at the upcoming HTTP client implementation, and I'm sad to see that connection timeouts are missing from the implementation (the old HTTP API). Is the absence of connection timeouts intended or an oversight? I'd like to see it added, and it looks like a simple change to me. http://openjdk.java.net/jeps/321 http://mail.openjdk.java.net/pipermail/jdk-dev/2018-March/000996.html There are some environments (such as AWS VPCs), where connection failures are only indicated by a connection timeout. This is because ICMP 'Destination Unreachable' packets are often not forwarded to the client (by load balancers, private links, etc) and there are supposedly some security concerns with allowing them by default. Those ICMP packets give immediate failures (net/host/protocol/port unreachable), but timeouts are slow. The default timeout is unbounded in Java, though the TCP implementation of the OS times-out connection establishment to around 130 seconds. It looks like the implementation uses SocketChannel, which still supports timeouts via chan.socket().connect(addr, timeout). Markus
Re: RFR : 8205959 : Do not restart close if errno is EINTR
According to http://man7.org/linux/man-pages/man2/close.2.html it is currently platform-dependent whether close() must or must not (seems to be no middle ground) be retried. Might have to do some #ifdef guarding? -- - DML > On Jun 27, 2018, at 6:15 PM, 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 because close() is not > restartable. > > The `man 2 close` states: > """ > ... close() should not be retried after an EINTR since this may cause a > reused descriptor from another thread to be closed. > """ > > Would you please help review a trivial fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8205959 > WEBREV: http://cr.openjdk.java.net/~igerasim/8205959/00/webrev/ > > Thanks in advance! > > -- > With kind regards, > Ivan Gerasimov >
Re: HttpURLConnection throws SunCertPathBuilderException in jdk11
This should be fixed in JDK 11 b23. Please try again. See
https://bugs.openjdk.java.net/browse/JDK-8199779 for more info.
--Sean
On 6/25/18 12:28 AM, Jaikiran Pai wrote:
I couldn't locate this bug in the JIRA nor the bugs.java.net, to see if
it's acknowledged as an issue. So FWIW - I can reproduce this even on
MacOS (so it isn't just specific to Windows OS). This is the code:
import java.net.URL;
import java.io.InputStream;
public class CertTest {
public static void main(final String[] args) throws Exception {
final URL targetURL = new URL("https://api.vk.com/";);
try (final InputStream is =
targetURL.openConnection().getInputStream()) {
is.read();
}
}
}
-Jaikiran
On 16/06/18 12:51 AM, Andrey Turbanov wrote:
Thank you for response.
I submitted bug to bugtracker. Iinternal review ID : 9055666
Didn't find a way to attach files there, but program example is short
and can be easily run by anyone.
Andrey Turbanov.
2018-06-15 16:58 GMT+03:00 Sean Mullan >:
The 2nd (good) logfile looks like it is from a completely
different program - are you sure you are using the same code?
If it is, please rerun again and also add -Djavax.net.debug=all to
the command-line which should give a bit more debug info as to
where the issue is occurring in the TLS handshake.
I would also recommend filing a bug and attaching the logfiles so
that this is tracked and evaluated more formally:
https://bugreport.java.com/bugreport/
>>:
Please add -Djava.security.debug=certpath to the java
command line
and attach the log file. Preferably, attach 2 log files,
one for a
good run and one for a bad run. This should help show what the
problem is.
--Sean
On 6/11/18 7:59 PM, Андрей Турбанов wrote:
Hello.
I tried to use early jdk11 build
(http://jdk.java.net/11/) -
Oracle JDK build for Windows.
I got exception when my program tries to connect (via
HttpURLConnection) to https://api.vk.com/
sun.security.provider.certpath.SunCertPathBuilderException:
unable to find valid certification path to requested
target
at
sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
~[?:?]
at
sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
~[?:?]
at
java.security.cert.CertPathBuilder.build(CertPathBuilder.java:297)
~[?:?]
at
sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:380)
~[?:?]
at
sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:290)
~[?:?]
at
sun.security.validator.Validator.validate(Validator.java:264)
~[?:?]
at
sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:343)
~[?:?]
Same code works well with JDK 10.
Does JDK11 have different set of SSL certificates? Is
there any
way to allow connection to vk.com
?
Andrey Turbanov
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/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. Is this defensive coding really needed here, given that the class is internal and only ever used by the FTP URL protocol handler? It is good to have but i agree with you as class is internal and part of non-exported package so it is not really needed. If it is not really needed, then maybe we just close the bug as ‘not an issue’. -Chris.
Re: RFR: 8172346 sun.net.ftp.FtpDirEntry.setCreated(Date) may expose internal represent
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/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. Is this defensive coding really needed here, given that the class is internal and only ever used by the FTP URL protocol handler? If it is not really needed, then maybe we just close the bug as ‘not an issue’. -Chris.
Re: RFR [11] 8207960: Non-negative WINDOW_UPDATE increments may leave the stream window size negative
Looks good Chris - Michael. On 24/07/2018, 10:23, Chris Hegarty wrote: The stream window size can correctly become negative after processing the initial SETTINGS_INITIAL_WINDOW_SIZE. Stream specific WINDOW_UPDATE's should not cause a stream reset if the current window size is negative before the positive increment amount is added. http://cr.openjdk.java.net/~chegar/8207960/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8207960 -Chris.
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
RFR [11] 8207960: Non-negative WINDOW_UPDATE increments may leave the stream window size negative
The stream window size can correctly become negative after processing the initial SETTINGS_INITIAL_WINDOW_SIZE. Stream specific WINDOW_UPDATE's should not cause a stream reset if the current window size is negative before the positive increment amount is added. http://cr.openjdk.java.net/~chegar/8207960/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8207960 -Chris.
Re: RFR [11 8207959 The initial value of SETTINGS_MAX_CONCURRENT_STREAMS should have no limit
This looks fine, Chris. - Michael. On 23/07/2018, 11:43, Chris Hegarty wrote: The initial value for the directional parameter SETTINGS_MAX_CONCURRENT_STREAMS, in the direction from the server to the client, max concurrent client-initiated streams, is incorrectly limited to 100, when there should be no initial limit. Note, the client retains its, configurable, limit of 100 server-initiated streams.. From section 6.5.2. Defined SETTINGS Parameters: SETTINGS_MAX_CONCURRENT_STREAMS (0x3): Indicates the maximum number of concurrent streams that the sender will allow. This limit is directional: it applies to the number of streams that the sender permits the receiver to create. *** Initially, there is no limit to this value***. It is recommended that this value be no smaller than 100, so as to not unnecessarily limit parallelism. … https://bugs.openjdk.java.net/browse/JDK-8207959 http://cr.openjdk.java.net/~chegar/8207959/webrev.00/ A few methods have been renamed in the webrev, to improve readability. -Chris.
