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

Nice suggestion Mark - I've taken that on board with latest webrev. http://cr.openjdk.java.net/~coffeys/webrev.8182672.jdk10.v3/webrev/ There was an issue with the hasHardwareAddress method also. A 'return false' was missing in the exception block. Vyom - I discussed your suggestion with

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

a minor observation: perhaps a slight modification to the test to allow adaptation to jdk8 (the genesis of the reported problem) replacing the NetworkInterface.networkInterfaces() with static method which encapsulates the Stream creation public static Stream

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

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

Thanks all. There were a few shouts from Chris in the office when he saw my Enumeration code ;) I'm running this through our test system again and will push if I get green results. Regards, Sean. On 23/06/17 14:40, Langer, Christoph wrote: Hi, looks like a great piece of modern concurrent

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

Hi, looks like a great piece of modern concurrent Java coding :) Well done! +1 Best regards Christoph > -Original Message- > From: Chris Hegarty [mailto:chris.hega...@oracle.com] > Sent: Freitag, 23. Juni 2017 15:28 > To: Seán Coffey ; Langer, Christoph >

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

On 23/06/17 10:56, Seán Coffey wrote: Thanks to Christoph, Vyom and Mark for the reviews. I've improved the testcase as per feedback. Hope this meets all requests : http://cr.openjdk.java.net/~coffeys/webrev.8182672.jdk10.v2/webrev/ The change looks good. Sean and I did a live coding

Re: RFR 8178699/10, Fail to send async requests if server doesn't response the first one

Hi Daniel， thread dump can be found in JBS attachment . Thanks -Felix Sent from my iphone > 在 2017年6月23日，18:40，Daniel Fuchs 写道： > > Hi Felix, > > Looks good to me. > > +1 for removing unnecessary calls that need synchronization and > cause deadlocks. > > If

Re: RFR 8178699/10, Fail to send async requests if server doesn't response the first one

Hi Felix, Looks good to me. +1 for removing unnecessary calls that need synchronization and cause deadlocks. If you still have the full thread-dump where the issue could be observed it might be good to record it in JDK-8178699 (if you no longer have it then don't bother). best regards, --

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

Hi Sean, latest test code looks good, one minor bit, in MT program "ex.printStackTrace();" will not help as output will be screwed. I will suggested to pass the original exception to line 106. throw new RuntimeException(originalException); Thanks, Vyom On Friday 23 June 2017 03:26 PM,

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

Hi Seán, this looks very good. I've got a few minor points: 1. In line 65 where you catch a possible unexpected exception, you could also mention the thread name in the output. 2. I would check for failure condition at the end of each test loop(line 91, for (NetworkInterface ni : toTest)... )

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

Thanks to Christoph, Vyom and Mark for the reviews. I've improved the testcase as per feedback. Hope this meets all requests : http://cr.openjdk.java.net/~coffeys/webrev.8182672.jdk10.v2/webrev/ Regards, Sean. On 22/06/17 22:36, Langer, Christoph wrote: Hi Sean, I played with it a bit more

RFR 8178699/10, Fail to send async requests if server doesn't response the first one

Hi all, please review the following patch to API in jdk.incubator.httpclient. The patch is more like a clean-up: * With current RequestProcessor implementation, constructing multiple HTTP Exchange may be blocked if the first request doesn't response by server side. This is