This looks good to me Patrick.
I'm happy to see that all implementations now have a consistent
and predictable behavior.
Also - as Alan noted - this is not really a behavioral change
as some subclass of IOException (or IOException itself) was
already thrown before.
+1
best regards,
-- daniel
Looks good to me Ivan.
Thanks for this cleanup!
best regards,
-- daniel
On 30/03/2020 03:34, Ivan Gerasimov wrote:
Thank you Alan and Pavel!
My apologies for a wrong link in the initial request.
Here's the new webrev with the changes suggested by Pavel:
http://cr.openjdk.java.net/~igerasi
Hi Alan,
On 27/03/2020 09:06, Alan Bateman wrote:
http://cr.openjdk.java.net/~dfuchs/webrev_8241336/webrev.02/
This mostly looks good except that I'd prefer if the the code in
assertNotSame be moved into testSendNoReceive (it was an oversight in
the original test that testSendNoReceive didn't
Hi Alan.
On 26/03/2020 17:29, Alan Bateman wrote:
NetworkConfiguration.isTestable - is the hardcoded check for "awdl"
needed? I don't think I've seen it with non-link local address so I
can't tell if it is needed. I'm
It might no longer be needed, but we know that awdl is always
the wrong cho
Hi,
Please find below a fix for:
8241336: Some java.net tests failed with NoRouteToHostException on
MacOS with special network configuration
https://bugs.openjdk.java.net/browse/JDK-8241336
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8241336/webrev.01/index.html
The crux of the i
Thanks for jumping on this Julia!
Reviewed. Since this is making some noise in the CI I suggest
to push it asap.
best regards,
-- daniel
On 26/03/2020 14:32, Julia Boes wrote:
Hi,
Could someone please review this small fix of a recently pushed test?
The option to extend the policy file has
OK, thanks for double checking Julia.
Looks good to me then!
best regards,
-- daniel
On 24/03/2020 16:33, Julia Boes wrote:
Hi Daniel,
* @run testng/othervm/java.security.policy=FilePublisherPermsTest1.policy
Does this actually work as expected? I thought the syntax was:
@run testng/other
Hi Julia,
* @run testng/othervm/java.security.policy=FilePublisherPermsTest1.policy
Does this actually work as expected? I thought the syntax was:
@run testng/othervm/policy=
And FWIW there some subtlety with
othervm/policy=
versus
othervm/policy==
and I never remember which one should be
hanks Alan! I'll reorder before pushing.
-- daniel
-Alan
On 23/03/2020 13:22, Daniel Fuchs wrote:
Hi,
Please find below a changeset for:
8241443: Problem list some java.net tests failing with
NoRouteToHostException on macOS with special
network configuration
We are
Hi,
Please find below a changeset for:
8241443: Problem list some java.net tests failing with
NoRouteToHostException on macOS with special
network configuration
We are observing some net/nio tests failing on some of our mac
machines. While we investigate the issue we would lik
Hi Ivan,
Looks good to me. I wonder if you should add
@bug 8044365
to the MulticastSendReceiveTests.java while you're at it.
best regards,
-- daniel
On 20/03/2020 07:19, Ivan Gerasimov wrote:
Hello!
An OOM error is intermittently observed on MacOS when joining a
multicast group.
A workaro
Hi Rahul,
This looks good to me.
Thanks for fixing it!
best regards,
-- daniel
On 19/03/2020 10:29, rahul.r.ya...@oracle.com wrote:
Hello,
Can I please have my fix reviewed for issue JDK-8240921 - Minor
correction to HttpResponse.BodySubscribers example?
The fix updates the incorrect
Hi Jaikiran,
This looks reasonable to me.
I will happily sponsor it - unless there are other takers.
best regards,
-- daniel
On 18/03/2020 11:18, Jaikiran Pai wrote:
Can I please get a review and a sponsor for a patch which fixes the
issue reported in JDK-8241138[1]?
The patch is hosted as a
Hi Xuelei,
HandshakeCompletedEvent.java: typo:
186 "This method has retired, pleaase use the " +
Same in SSLSession.java:
303 "This method has retired, pleaase use the " +
WRT to the HttpClient code I wonder whether the deprecated method
should be kept. On the on
Hi Julia,
I think we need to revisit the
public static FilePublisher create(Path path)
a bit.
We should try to call Path::toFile first - whether there is a security
manager or not. In the case where that succeeds, we can use
new FileInputStream(), otherwise, we use Files.newInputStream.
It's
On 11/03/2020 16:54, Patrick Concannon wrote:
http://cr.openjdk.java.net/~pconcannon/8239355/webrevs/webrev.03/
Looks good to me Patrick!
best regards,
-- daniel
Hi Alan,
On 11/03/2020 12:08, Alan Bateman wrote:
Do we really? I am not sure we do.
We just want to verify that we don't get the "packet too large"
exception caused by the SO_SNDBUF buffer being too small.
It would be great if we had a test to send large datagrams on the
network as that is the
Hi Alan,
On 10/03/2020 19:59, Alan Bateman wrote:
On 10/03/2020 18:32, Patrick Concannon wrote:
http://cr.openjdk.java.net/~pconcannon/8239355/webrevs/webrev.02
Thanks for adding a test for getOption(SO_SNDBUF). That test
(testGetOption) should be checking that SO_SNDBUF is >= expected value
osted the patch to
cr.openjdk.net(http://cr.openjdk.java.net/~vtewari/8237858/webrev/index.html).
Thanks,
Vyom
- Original message -
From: Daniel Fuchs
To: Vyom Tewari26 , net-dev@openjdk.java.net
Cc:
Subject: [EXTERNAL] Re: RFR 8237858: PlainSocketImpl.socketAccept()
Hi Vyom,
I have sent your proposed fix to our test system and observed no
regression. I agree your proposed changes seem to address the
issue adequately. However, I'd like to hear a second opinion on the
possible side effects of this fix, since NET_Timeout may be called
at many other places.
I s
Hi John,
Looks good to me.
best regards,
-- daniel
On 02/03/2020 08:08, sha.ji...@oracle.com wrote:
Hi,
java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/FlowTest.java
would not use a specific TLS protocol, instead just use the default TLS
protocol, exactly TLSv1.3 now.
dif
Hi Alan,
On 09/03/2020 17:01, Alan Bateman wrote:
On 09/03/2020 12:39, Patrick Concannon wrote:
bug: https://bugs.openjdk.java.net/browse/JDK-8239355
webrev:
http://cr.openjdk.java.net/~pconcannon/8239355/webrevs/webrev.00/index.html
This is a change to the DatagramChannel implementation. I
Hi,
Please find below a changeset that adds some more debugging
output to FlowTest.java for better test failure diagnosis.
8240754: Instrument FlowTest.java to provide more debug traces.
https://bugs.openjdk.java.net/browse/JDK-8240754
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8240754/w
Hi Bernd,
On 02/03/2020 20:44, Bernd Eckenfels wrote:
However the question is, if other conditions (address families for
tunnels, x.25 etc) than loopback can also trigger this unsupported case
- but would actually return something in the fallback. So maybe for
compatibility trying the fallback
HttpURLConWithProxy test fails without the fix.
Webrev: http://cr.openjdk.java.net/~pkoppula/8183369/webrev.00/
Issue: https://bugs.openjdk.java.net/browse/JDK-8183369
Thanks,
Ravi
-Original Message-
From: Ravi Reddy
Sent: Thursday, February 13, 2020 10:10 PM
To: Daniel Fuchs ; Vyom Tiwari
Hi Alan,
On 29/02/2020 07:54, Alan Bateman wrote:
On 28/02/2020 22:06, Bernd Eckenfels wrote:
I'm also curious if there are any platforms or configurations where the
loopback has a hardware address. Mostly wondering if this should be
short circuited to consistently return null (I would expect
back interface is being queried or
not - I believe that return 0 when the query is not supported
is the right thing to do here.
best regards,
-- daniel
--
http://bernd.eckenfels.net
--------
*Von:* net-dev im Auftrag von Daniel
F
Hi,
Please find below a fix for:
8059309: network tests fail with "java.net.SocketException:
Couldn't obtain phys addr" when run as "root"
https://bugs.openjdk.java.net/browse/JDK-8059309
http://cr.openjdk.java.net/~dfuchs/webrev_8059309/webrev.00/
Recent reports have shown that the f
Hi Vyom,
I tried out your patch and got no suspicious failures so
you have my review :-)
best regards,
-- daniel
On 15/02/2020 04:14, Vyom Tewari26 wrote:
I'll get back to you when I have managed to find some
cycles to do so.
best regards,
-- daniel
On 14/02/2020 04:57, Vyom Tiwari wrote:
Thanks Chris!
I was going to answer that this was not possible as it requires
multiple return values but I found a way:
http://cr.openjdk.java.net/~dfuchs/webrev_8239052/webrev.02/
best regards,
-- daniel
On 22/02/2020 13:53, Chris Hegarty wrote:
On 21 Feb 2020, at 17:41, Daniel Fuchs
a specific TLS protocol, this configuration
could be removed.
The default TLS protocol, exactly TLSv1.3 now, will be applied.
Best regards,
John Jiang
On 2020/2/21 18:01, Daniel Fuchs wrote:
Hi,
Please find below a test fix for:
8239052: java/net/httpclient/whitebox/SSLEchoTubeTestDriver.java
Hi,
Please find below a test fix for:
8239052: java/net/httpclient/whitebox/SSLEchoTubeTestDriver.java
failed with BufferUnderflowException against TLSv1.3
https://bugs.openjdk.java.net/browse/JDK-8239052
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8239052/webrev.00/
The test th
Hi,
Please find below a fix for:
8238990: java/net/httpclient/HandshakeFailureTest.java failed
against TLSv1.3 on Windows
https://bugs.openjdk.java.net/browse/JDK-8238990
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8238990/webrev.00/
The issue here is that we get a race conditio
Hi Vyom,
On the surface, your patch seems reasonable.
I would be more confident if there was a test, but I understand
it might well be one of these noreg-hard issues.
I've put it on my TODO list to import your patch and
try to test it in our test system.
I'll get back to you when I have managed
Looks good to me too.
best regards,
-- daniel
On 14/02/2020 11:57, Patrick Concannon wrote:
Hi,
With further discussion on this benchmark test with Claes off-list, I've
updated the code to use more descriptive names. The updated webrev can
be found below.
http://cr.openjdk.java.net/~pconc
+1
I thought I had a possible fix for this test, but unfortunately
I couldn't manage to push it yesterday. I still need a bit of time
to experiment with several options.
best regards,
-- daniel
On 13/02/2020 23:06, sha.ji...@oracle.com wrote:
Hi,
java/net/httpclient/HandshakeFailureTest.java
Thanks Vyom.
I was suspecting as much.
Ravi, could you come up with a test that fails without the fix
and pass with it?
best regards,
-- daniel
On 13/02/2020 14:26, Vyom Tiwari wrote:
Hi Ravi/Daniel,
At my local env(REL 7) test is passing without fix as well. Although my
local repo contai
Hi,
On 13/02/2020 10:52, Ravi Reddy wrote:
I notice that the `break` from the original code has not been
reintroduced. I don't think that it is strictly needed, but did you give
it any consideration?
Chris , in original code since we were doing retry with direct
connection and not proceeding
Hi John,
This looks good to me. Thanks for taking care of that and
for logging JDK-8238990!
best regards,
-- daniel
On 13/02/2020 05:23, sha.ji...@oracle.com wrote:
Hi,
java/net/httpclient/HandshakeFailureTest.java should cover TLSv1.3 as well.
java/net/httpclient/ShortResponseBody.java would
On 08/02/2020 07:46, sha.ji...@oracle.com wrote:
Hi Daniel,
I'll do that.
Please review this updated webrev:
http://cr.openjdk.java.net/~jjiang/8238677/webrev.01/
The script, exactly gen-certs.sh, can be used to generate the certs.
Looks good to me John!
best regards,
-- daniel
Hi John,
Looks good to me. Thanks for taking care of this!
I'm glad to see the binary files go away :-)
Would it be possible to include a comment in Cert.java that contains
the command you used to generate the certificates?
That will be a great help to future maintainers if the certificates
eve
On 31/01/2020 20:45, Alan Bateman wrote:
On 31/01/2020 19:42, Daniel Fuchs wrote:
Good, this version is correct. I see that getImpl() is synchronizing on
"this". I guess that is okay but synchronizing on the impl is another
choice here.
Yes. Well I syncronized on `this` because oth
On 31/01/2020 17:47, Alan Bateman wrote:
On 31/01/2020 17:30, Daniel Fuchs wrote:
http://cr.openjdk.java.net/~dfuchs/webrev_8238231/webrev.01
This has the same bug as it reads "created" outside of the synchronized
block. If you change it to volatile then it will fix that issue.
Hi Alan!
On 31/01/2020 17:10, Alan Bateman wrote:
On 31/01/2020 16:46, Daniel Fuchs wrote:
http://cr.openjdk.java.net/~dfuchs/webrev_8238231/webrev.00/
This seems to have a few problems. Consider two threads calling
getImpl() at around the same time. This can only work if "create
Hi,
Please find below a fix for:
8238231: Custom DatagramSocketImpl's create method not called when
with protected constructor
https://bugs.openjdk.java.net/browse/JDK-8238231
This is a behavioral regression introduced by JDK-8236925 [1].
Thanks Alan for providing a suggested fix. I ha
Hi Alan.
Alright. I've transformed the second note in an @see:
http://cr.openjdk.java.net/~dfuchs/webrev_8237896/webrev.02/
best regards,
-- daniel
On 29/01/2020 08:20, Alan Bateman wrote:
If someone has a MulticastSocket then they can't get to a
DatagramChannel to use the alternative join m
Hi Alan,
On 27/01/2020 19:30, Alan Bateman wrote:
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8237896/webrev.00/
The API note for the class description looks good.
I'm less sure about the API notes added ot the joinGroup method because
you can't get a MulticastChannel from a MulticastSo
Hi,
Please find below a doc-only fix for:
8237896: MulticastSocket should link to DatagramChannel as
an alternative for multicasting.
https://bugs.openjdk.java.net/browse/JDK-8237896
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8237896/webrev.00/
best regards,
-- daniel
Hi Pavel,
That looks good to me. Thanks for improving this file!
I didn't know that javadoc tags could be used in plain
HTML files.
Maybe another pair of eyes would be good.
best regards,
-- daniel
On 24/01/2020 12:31, Pavel Rappo wrote:
Hello,
Please review the following change for
https:
Hi Alan,
On 24/01/2020 11:41, Alan Bateman wrote:
CSR: https://bugs.openjdk.java.net/browse/JDK-8237774
webrev: http://cr.openjdk.java.net/~pconcannon/7021373/webrevs/webrev.00/
I just skimmed over this (not a complete review) but getSocketAddress()
throwing IllegalArgumentException doesn't str
Hi,
Please find below a fix for:
8236596: HttpClient leaves HTTP/2 sockets in CLOSE_WAIT, when
using proxy tunnel
https://bugs.openjdk.java.net/browse/JDK-8236596
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8236596/webrev.00/
The issue seems to appear when the client is garbage
Looks good to me Patrick!
Thanks for jumping on this.
best regards,
-- daniel
On 21/01/2020 10:07, Patrick Concannon wrote:
Hi,
Could someone please review my fix for issue JDK-8237571
'java/net/DatagramSocket/SendCheck.java is failing on Solaris' ?
A test case in java/net/DatagramSocket/
Hi Patrick,
DatagramSocket.java:
694 * is not set.
this line needs to be removed.
Otherwise this looks good to me.
A release note might get requested by the CSR lead.
best regards,
-- daniel
On 13/01/2020 16:30, Patrick Concannon wrote:
Hi,
Could someone please review m
Looks good Alan!
best regards.
-- daniel
On 14/01/20 19:23, Alan Bateman wrote:
Thanks for going through this. I tried to keep the changes to
DatagramSocket to a minimum but I don't mind making an exception for
oldImpl. It's a slippery slope as there is a lot of technical debt in
this area.
On 14/01/2020 18:17, Pavel Rappo wrote:
I think the WebSocket part of the changeset look good to me. I have gone through
the non-WebSocket part of the changes shallowly. I'm not an expert.
Thanks!
Your review is appreciated!
I will wait until Michael or Chris review the rest of the changes.
b
Hi Pavel,
On 14/01/2020 17:54, Pavel Rappo wrote:
That changeset applies fine, thanks.
I was wondering what you had in mind when added OpeningHandshake:225.
Was it for general robustness or you ran into something in particular?
More for general robustness. Sometimes assertion errors are fire
Hi Alan,
Globally this looks good to me. One small nit is that the `oldImpl`
field could now also become final (by applying the same trick you
did with createImpl - that is - have oldImpl() return a boolean
rather than set the field and assign the result in the constructor.
I've imported your pa
On 14/01/2020 15:14, Daniel Fuchs wrote:
I wonder if this was causing issue with the import.
(the patch is obtained by hg diff, not hg export)
Yes. Damn. the open.patch generated by webrev renames the files
instead of copying/modifying...
I have added a proper changeset generated with `hg
me
of them could not be compiled. For instance,
java/net/httpclient/websocket/BlowupOutputQueue.java
java/net/httpclient/websocket/PendingPingBinaryClose.java
...
etc.
> On 13 Jan 2020, at 13:06, Daniel Fuchs wrote:
>> http://cr.openjdk.java.net/~dfuchs/webrev_8236859/webrev.00/
On 14/01/2020 11:49, Patrick Concannon wrote:
bug: https://bugs.openjdk.java.net/browse/JDK-8237075
webrev: http://cr.openjdk.java.net/~pconcannon/8237075/webrevs/webrev.00/
Looks good to me as well.
best regards,
-- daniel
Hi Anuuraag, Aleksei,
Looks good to me.
Except that now copyright years must be updated to 2020.
No need for a new webrev if that's the only change!
best regards,
-- daniel
On 09/01/2020 17:17, Aleks Efimov wrote:
Hi Anuuraag,
Latest webrev: http://cr.openjdk.java.net/~aefimov/anuraaga/7006
Hi,
For some time now we've been considering replacing the
implementation of DatagramSocket and MulticastSocket with
something more modern, based on NIO, much similar to what
was done for Socket and ServerSocket in JEP 353 [1].
We have been doing some prototyping, and finally got a
draft JEP wri
Hi,
Please find below a fix for:
8236859: WebSocket over authenticating proxy fails with NPE
https://bugs.openjdk.java.net/browse/JDK-8236859
http://cr.openjdk.java.net/~dfuchs/webrev_8236859/webrev.00/
It happens when we have a TLS tunnel and authentication with the server
fails: in that cas
Looks good to me as well.
Is there a CSR ready to be reviewed too?
best regards,
-- daniel
On 10/01/2020 16:29, Patrick Concannon wrote:
Hi Chris,
Well spotted.
I've made those changes and updated the webrev.
http://cr.openjdk.java.net/~pconcannon/8235783/webrevs/webrev.02/
Kind regards,
Hi,
Two small remarks:
ResolverConfigurationImpl.java:
71 if (!l.contains(s)) {
Maybe empty strings should be skipped here too.
I believe it would be more correct to change this line:
117 if (lastRefresh >= 0) {
to
117 if (lastRefresh != -1) {
as Sy
On 18/12/2019 16:06, Chris Hegarty wrote:
Not withstanding the various different post-close behaviour of the
methods of DatagramSocket ( throw IOException, silently ignore, return a
default value, return last known value ), I think that it would be best
to clarify the specification with the exist
Hi Alan,
On 18/12/2019 11:01, Alan Bateman wrote:
I guess my point here is that UncheckedIOException will never be thrown,
which might be okay if the primary motive is to prepare DatagramSocket
for the new implementation.
We already have two implementations of DatagramSocket: one is the plain
Hi Kiran,
1844 if (result == 0)
1845 return true;
1846 else
1847 return false;
could maybe be simplified into:
return result == 0;
1925 if (s.indexOf('%') < 0) {
1926 return s.compareTo(t);
1927 }
Hi,
Please find below a fix for:
8235925: java/net/Socket/HttpProxy.java fails on IPv4 only hosts
and other small cleanups
https://bugs.openjdk.java.net/browse/JDK-8235925
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8235925/webrev.00/index.html
java/net/Socket/HttpProxy.java f
Hi Kiran,
1926 int sn = s.length();
1927 int tn = t.length();
could be moved before line 1921 which could then become:
if (testForEquality && sn != tn) return sn - tn;
Otherwise looks good.
best regards,
-- daniel
On 13/12/2019 19:28, Kiran Ravikumar wro
Hi,
By default transparent authentication is disabled on windows.
You may have to specify a non-default value for the
jdk.http.ntlm.transparentAuth property [1], or configure
an Authenticator [2] that has the appropriate credentials.
[1] https://bugs.openjdk.java.net/browse/JDK-8225506
[2]
http
Hi Behrang,
net-dev is a better list to discuss networking/http related topics.
On 03/12/2019 12:22, Behrang Saeedzadeh wrote:> Hi all,
>
> Are there any plans to implement a "multipart/form-data" BodyPublisher in
> Java 14 or later?
There are no plans - especially not for 14 since we will be
Updated webrev: http://cr.openjdk.java.net/~jboes/webrevs/8232513/webrev.01/
On 06/12/2019 17:05, Vyom Tewari26 wrote:
Your change looks OK but it will increase the worst case, running time
of test from (2500+1000)ms to (15000 + 1000)ms and this will definitely
decrease the probability of in
Looks good to me Patrick!
I see that you have created a CSR at
https://bugs.openjdk.java.net/browse/JDK-8235423
and that looks good to me too.
best regards,
-- daniel
On 05/12/2019 17:17, Patrick Concannon wrote:
Hi,
Thanks for the feedback. I've made those changes now, and you can find
the
On 05/12/2019 16:14, Alan Bateman wrote:
bug: https://bugs.openjdk.java.net/browse/JDK-8233191
webrev: http://cr.openjdk.java.net/~pconcannon/8233191/webrevs/webrev.00/
Looks good, just a minor comment that "If null is given and no
interface ..." might be a bit better "If {@code null}, and no in
On 05/12/2019 15:44, Chris Hegarty wrote:
LGTM.
-Chris.
+1
-- daniel
This looks good to me Patrick.
With this fix multicast socket options can be set on DatagramSocket,
except on windows when the DualStackPlainDatagramSocketImpl is used.
DualStackPlainDatagramSocketImpl.java:
246 if (isReusePortAvailable())
247 options.add(StandardSocketOpti
Looks good to me Julia!
Best regards,
-- daniel
On 05/12/2019 15:14, Julia Boes wrote:
Hi,
I wonder however if the links to the deprecated setInterface method
should remain in the two args joinGroup/leaveGroup, since the
behavior is still in effect should you call that method.
Agreed, I up
Hi Julia,
Looks good to me.
I wonder however if the links to the deprecated setInterface method
should remain in the two args joinGroup/leaveGroup, since the
behavior is still in effect should you call that method.
best regards
-- daniel
On 04/12/2019 16:40, Julia Boes wrote:
Hi,
Please see
Doh! My mistake. I dropped this part in the test:
http://cr.openjdk.java.net/~dfuchs/webrev_8235141/webrev.02
cheers,
-- daniel
On 04/12/2019 16:42, Chris Hegarty wrote:
Daniel,
On 04/12/2019 14:24, Daniel Fuchs wrote:
This test doesn't test NetworkChannel.
This is what I was referri
Hi Julia,
Looks good to me - but is:
31 * @library /test/lib
actually needed?
best regards,
-- daniel
On 04/12/2019 15:40, Julia Boes wrote:
Hi,
The test PortUnreachable closes a DatagramSocket and tries to rebind it
to the same port, this causes the test to fail rarely with a
BindExcep
This test doesn't test NetworkChannel.
But it does check that the adapters behave consistently with the spec
of their java.net super class. I don't think there's anything
to remove.
best regards,
-- daniel
On 04/12/2019 10:33, Chris Hegarty wrote:
>
> I guess the test is okay but it's not re
Thanks for the review Alan!
new webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8235141/webrev.01/
On 02/12/2019 15:53, Alan Bateman wrote:
8235141: Specify the required standard socket options for the
socket types in the java.net package
https://bugs.openjdk.java.net/browse/JDK-8235
Hi,
Please find below a doc-only fix that specifies, for each
socket type in the java.net package, the minimal set of option
that that type supports.
The doc changes have been largely imported from corresponding
types in java.nio.channels.
8235141: Specify the required standard socket options
Looks good to me Patrick!
Thanks for the test updates :-)
best regards,
-- daniel
On 28/11/2019 13:01, Patrick Concannon wrote:
Hi Chris,
Thanks for your feedback.
I've incorporated your comments into the fix, and the changes can be
found in the updated webrev below.
webrev: http://cr.op
Hi Julia,
Looks good to me!
Good work with the test :-)
best regards,
-- daniel
On 26/11/2019 16:27, Julia Boes wrote:
Hi,
When HttpServer.stop(int delay) is called on the dispatcher thread of
the server, the call blocks indefinitely as the thread is waiting for
itself to die. The propose
Hi Rob,
That looks good to me. I wonder if that should go to corelibs for
review as well.
The underlying issue here is that JarURLConnection open both its
jar file and its jar file entry in its connect() method.
However, it delegates the opening of the jar file to the cache,
when uses cache is t
Hi,
Please find below a trivial fix for:
8231516: network QuickAckTest.java failed due to
"SocketException: maximum number of DatagramSockets reached"
https://bugs.openjdk.java.net/browse/JDK-8231516
The test should be run in /othervm mode to avoid being impacted by
other tests that mig
Thanks Alan!
On 21/11/2019 21:15, Alan Bateman wrote:
I think I would cast to boolean rather than Boolean (because it's
boolean on the LHS) to make it a bit clearer. The rest looks good.
OK - I'll do that before pushing.
Although for me, given an Object obj, it's actually more natural to do:
On 21/11/2019 16:47, Chris Hegarty wrote:
I was kinda suggesting that the explicit no-args constructor is not needed (
but maybe I have missed something? ). Either way ( I’ll leave it to you ), you
have my Review.
Oh - I though you meant the `throws Exception` that the constructor
was declari
On 21/11/2019 15:02, Chris Hegarty wrote:
The source changes look good.
A few minor comments on the test.
You probably don’t need this anymore? ( InetAddress.getLoopbackAddress() does
not throw )
63 SetLoopbackOption() throws Exception {
64 }
You could also push the main entry
Hi Anton,
That looks fine to me.
best regards,
-- daniel
On 21/11/2019 15:28, Anton Litvinov wrote:
Hello,
Could you please review the following fix for the bug. The bug consists
in a deadlock introduced by the fix for the bug JDK-8032832, which
introduced locking on the thread context cla
Hi,
Please find below a fix for:
8233296: MulticastSocket getOption/setOption inverts the value
of IP_MULTICAST_LOOP
https://bugs.openjdk.java.net/browse/JDK-8233296
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8233296/webrev.00/
I am not sure whether a CSR was strictly needed bu
Hi Patrick,
This looks good to me!
best regards,
-- daniel
On 14/11/2019 12:19, Patrick Concannon wrote:
Hi,
Could someone please review my fix for issue JDK-8233018 'Add a new test
to verify that DatagramSocket is not interruptible'?
This fix adds a test to check the interruptability of
On 14/11/2019 12:24, Patrick Concannon wrote:
Hi Daniel,
I've added the comment, and you can find it in the new webrev below.
webrev: http://cr.openjdk.java.net/~pconcannon/8234103/webrevs/webrev.01/
Looks good Patrick - I think we could push that if you can generate
a properly formatted cha
://bernd.eckenfels.net
*Von:* net-dev im Auftrag von Daniel
Fuchs
*Gesendet:* Freitag, November 15, 2019 5:18 PM
*An:* Nicolas Henneaux
*Cc:* OpenJDK Network Dev list
*Betreff:* Re: [java.net.http.HttpClient] Active
Hi Nicolas,
Sorry for the late reply...
On 07/11/2019 17:13, Pavel Rappo wrote:
On 7 Nov 2019, at 14:24, Nicolas Henneaux wrote:
Hi,
*I am trying to build an HTTP client based on java.net.http.HttpClient and
I would like to have some control on the IP addresses resolved under the
hood.*
I w
Hi,
Please find below a fix (and CSR) for:
8233141 DatagramSocket.send doesn't specify exception thrown when
no target address
https://bugs.openjdk.java.net/browse/JDK-8233141
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8233141/webrev.00/
CSR
https://bugs.openjdk.java.net/browse/
Hi Patrick,
Thanks for helping getting rid of this old technical debt!
In DualStackPlainDatagramSocketImpl.java:
64 DualStackPlainDatagramSocketImpl(boolean exclBind) {
65 super(false);
Maybe add a comment to clarify the meaning of `false`:
65 super(false); // DualSt
Thanks Patrick!
I'll push that for you later today, alongside with 8233989 once you
have generated a changeset for that one too.
best regards,
-- daniel
On 14/11/2019 10:55, Patrick Concannon wrote:
Hi Vyom,
Thanks for your feedback.
That's a good suggestion, and I've incorporated it into
901 - 1000 of 1478 matches
Mail list logo
