Good. :-) Learn something new today. Thanks!
Xuelei
On 7/6/2013 9:18 AM, Brad Wetmore wrote:
>
>
> On 7/2/2013 8:29 PM, Xuelei Fan wrote:
>> On 7/3/2013 8:30 AM, Brad Wetmore wrote:
>>> http://cr.openjdk.java.net/~wetmore/8019341/webrev.01/
>>
>> 261 // If both failed, return the curth
On 7/2/2013 8:29 PM, Xuelei Fan wrote:
On 7/3/2013 8:30 AM, Brad Wetmore wrote:
http://cr.openjdk.java.net/~wetmore/8019341/webrev.01/
261 // If both failed, return the curthread's exception.
262 local.initCause(remote);
The mix the initial cause of the exception would make it ha
On 7/3/2013 8:30 AM, Brad Wetmore wrote:
> http://cr.openjdk.java.net/~wetmore/8019341/webrev.01/
261 // If both failed, return the curthread's exception.
262 local.initCause(remote);
The mix the initial cause of the exception would make it hard to parse
the real cause of a exception. I
Michael wrote:
> I'd agree with this. If the exception is being swallowed now, how
> will we know when the test fails?
The "peer" thread saves off any Exceptions into {server,client}Exception
volatile variable, which is then examined by the main thread at the end,
and the stacktrace would be s
On 28/06/13 02:38, Stuart Marks wrote:
On 6/27/13 4:58 PM, Brad Wetmore wrote:
Chris (and Michael),
As my part of the "intermittently failing test cleanup," I'm looking
into a
test of yours that has been intermittently failing.
It's bug:
https://jbs.oracle.com/bugs/browse/JDK-8017333
On 6/27/13 4:58 PM, Brad Wetmore wrote:
Chris (and Michael),
As my part of the "intermittently failing test cleanup," I'm looking into a
test of yours that has been intermittently failing.
It's bug:
https://jbs.oracle.com/bugs/browse/JDK-8017333
The open URL to view this bug is:
ht
Chris (and Michael),
As my part of the "intermittently failing test cleanup," I'm looking
into a test of yours that has been intermittently failing.
It's bug:
https://jbs.oracle.com/bugs/browse/JDK-8017333
which is failing the regression test you added for:
http://hg.openjdk.java.ne
