Hi Tristan,
Thanks for the updates. Pushed:
http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d24297425fd0
It's good to see all that unnecessary thread creation stuff removed.
s'marks
On 2/14/14 6:53 PM, Tristan Yan wrote:
Thank you Stuart
This is nice. I thought two variables were weird but I
Hi Tristan,
OK, we're getting close. Just a couple things about ShutdownGracefully.java.
It's a bit clumsy to have both a boolean and a message string to keep track of
the state of the test, but by itself this isn't such a big deal.
A bigger deal is the lack of exception chaining. If we
Thank you Stuart
This is nice. I thought two variables were weird but I didn’t figure out the
right solution. Also I wasn’t so sure why we print out so many messages now
it’s clear to me.
http://cr.openjdk.java.net/~tyan/JDK-8032050/webrev.05/
I’m sorry I have to ask you review this again.
Thank you Stuart
I have fixed comment in JavaVM.java. Dealing with different cases in
ShutdownGracefully.java, two variables were added. One is a flag
indicate test passed or not. Other variable keeps the error message when
test failed. I put TestLibrary.bomb in the bottom of the main method
Hi Tristan,
JavaVM.waitFor looks mostly fine. The indentation of the start of the
waitFor(timeout) javadoc comment is a bit off, though; please fix.
There are still some adjustments that need to be made in
ShutdownGracefully.java. Both have to do with the case where the last
registration
Thank you for your thorough mail. This is very educational. I took you advice
and generated a new webrev for this.
http://cr.openjdk.java.net/~tyan/JDK-8032050/webrev.03/
I appreciate you can review this again.
Regards
Tristan
On Feb 11, 2014, at 8:32 AM, Stuart Marks stuart.ma...@oracle.com
Hi Stuart
Could you help to review this.
Thank you
Tristan
On Jan 31, 2014, at 4:36 PM, Tristan Yan tristan@oracle.com wrote:
Thank you for fixing JDK-8023541. Then I leave ActivationLibrary.java for now.
I still did some clean up following your suggestion.
1. I changed waitFor(long
Hi Tristan,
Sorry about my recurring delays.
Several comments on these changes.
JavaVM.java --
The waitFor(timeout) method is mostly ok. The new thread started at line 208 and
following seems unnecessary, though. This code is reached when a timeout occurs,
so throwing TimeoutException is
Thank you for fixing JDK-8023541. Then I leave ActivationLibrary.java
for now.
I still did some clean up following your suggestion.
1. I changed waitFor(long timeout) method, this method is going to use
code like Process.waitFor(timeout, unit). This can be backported to
JDK7. Also exitValue is
Hi Tristan,
I don't want to put the workaround into ActivationLibrary.rmidRunning() for a
null return from the lookup, because this is only a workaround for an actual bug
in rmid initialization. See the review I just posted for JDK-8023541.
Adding JavaVM.waitFor(timeout) is something that
Hi Stuart
Thank you for your review and suggestion.
Yes, since this failure mode is very hard to be reproduced. I guess it's
make sense to do some hack. And I also noticed in
ActivationLibrary.rmidRunning. It does try to look up ActivationSystem
but doesn't check if it's null. So I add the
On 1/23/14 10:34 PM, Tristan Yan wrote:
Hi All
Could you review the bug fix for JDK-8032050.
http://cr.openjdk.java.net/~tyan/JDK-8032050/webrev.00/
Description:
This rare happened failure caused because when RMID starts. It don't guarantee
sun.rmi.server.Activation.startActivation finishes.
Hi All
Could you review the bug fix for JDK-8032050.
http://cr.openjdk.java.net/~tyan/JDK-8032050/webrev.00/
Description:
This rare happened failure caused because when RMID starts. It don't
guarantee sun.rmi.server.Activation.startActivation finishes.
Fix by adding a iterative getSystem with
13 matches
Mail list logo
