Hello!
ReferenceQueue.remove(timeout) may return too early, i.e. before the
specified timeout has elapsed.
Would you please review the fix?
The change also includes a regression test, which can be used to
demonstrate the issue.
BUGURL: https://bugs.openjdk.java.net/browse/JDK-6853696
WEBREV
I am ok with this unfix for now. Martin. And thank you for bringing the
improvement to jsr166 CVS.
Regards
Tristan
发件人: Martin Buchholz [mailto:marti...@google.com]
发送时间: Monday, February 24, 2014 10:59 AM
收件人: Tristan Yan
抄送: core-libs-dev
主题: Re: 答复: 答复: RFR for JDK-8031374:
java/util/co
Hi Tristan,
I don't think we should change the test without a sufficiently solid
reason, which usually means reproducing the failure, even if e.g. only once
in 1000 times. Here we don't know which queue implementation is causing
the failure, and we don't know what chunk size was being used, which
Hi Martin
This test failed once in our nightly test. So this is a real case failure. But
unfortunately we couldn’t know more except the log we had.
10 extra seconds may need serve 1024 loop totally, also in windows
Thread.yield() doesn’t give up CPU most of times, then we can may have the
situ
I may very well be missing something, but the actual extra timeout for
threads to finish is 10 whole seconds, which should be long enough to
process a single chunk, even on Windows.
If you can repro this consistently, try to find out which queue
implementation is affected.
We can also shrink max
I'm doing some independent cleanup and checking into jsr166 CVS:
This gets rid of the Thread.stop and introduces a Semaphore that can be
waited on instead of spinning. Try to work from this new version. If you
can never reproduce the failure to verify a fix, I suggest leaving the bug
unfixed unti
Thank you for reviewing this. Martin
The original bug report is here:
https://bugs.openjdk.java.net/browse/JDK-8031374.
I haven’t reproduced this bug but I can simulate to reproduce this failure by
changing yield() in remover thread to Thread.sleep(20).
You have commented “You've comple
Hi Tristan,
I don't have time to analyse the original failure mode nor your proposed
changes but ...
On 23/02/2014 7:40 PM, Tristan Yan wrote:
Hi All
Could you please help to review fix for JDK-803174.
http://cr.openjdk.java.net/~tyan/JDK-8031374/webrev.00/
Description:
There are a couple o
On 23/02/2014 17:04, Mark Sheppard wrote:
Hi
please oblige and review the following changes
http://cr.openjdk.java.net/~msheppar/8033075/webrev/
which address the issue raised in
https://bugs.openjdk.java.net/browse/JDK-8033075
summary:
a number of HREFs to CORBA specification exist in th
Hi
please oblige and review the following changes
http://cr.openjdk.java.net/~msheppar/8033075/webrev/
which address the issue raised in
https://bugs.openjdk.java.net/browse/JDK-8033075
summary:
a number of HREFs to CORBA specification exist in the CORBA api docs
these now have dead URLs.
Hi All
Could you please help to review fix for JDK-803174.
http://cr.openjdk.java.net/~tyan/JDK-8031374/webrev.00/
Description:
There are a couple of code change for this code.
1. Original code has used known problematic Thread.stop. Which could cause
ThreadDeath as all we know. I change it to a
On 20/02/2014 16:59, Peter Levart wrote:
:
Hi Alan,
I made another webrev with minor changes based on your feedback...
http://cr.openjdk.java.net/~plevart/jdk9-dev/DirectBufferAlloc/webrev.03/
Thanks for the updates, this is good work and I think this is good to go.
No System.exit in this
12 matches
Mail list logo
