Re: Code Review Request: 7197662: (prefs) java/util/prefs/AddNodeChangeListener.java fails by timeout or by couldn't get file lock

2012-11-30 Thread Alan Bateman
On 30/11/2012 02:04, Kurchi Hazra wrote: Apologies for the extreme delay. I added the bug id, and checked that setting the userRoot=. will result in the JTwork/scratch directory being used to store the preferences. I think we had concluded that othervm is the correct choice for running a test

Re: Code Review Request: 7197662: (prefs) java/util/prefs/AddNodeChangeListener.java fails by timeout or by couldn't get file lock

2012-11-29 Thread Kurchi Hazra
Apologies for the extreme delay. I added the bug id, and checked that setting the userRoot=. will result in the JTwork/scratch directory being used to store the preferences. I think we had concluded that othervm is the correct choice for running a test when setting the

Re: Code Review Request: 7197662: (prefs) java/util/prefs/AddNodeChangeListener.java fails by timeout or by couldn't get file lock

2012-09-22 Thread Alan Bateman
On 22/09/2012 00:12, Weijun Wang wrote: I think jtreg would automatically reset any changed system property so othervm is not necessary. Have you tried running it with other tests in agentvm mode? Thanks Max There are many areas in the JDK where system properties are read once during

Re: Code Review Request: 7197662: (prefs) java/util/prefs/AddNodeChangeListener.java fails by timeout or by couldn't get file lock

2012-09-22 Thread Weijun Wang
Correct, so it depends on how the system properties are used. In my area, sometimes a system property is always re-read so it's safe to run related tests in agentvm. Sometimes it's read at initialization time and a static field is set, if there is no way to reset that static field, your tests

Re: Code Review Request: 7197662: (prefs) java/util/prefs/AddNodeChangeListener.java fails by timeout or by couldn't get file lock

2012-09-21 Thread Chris Hegarty
On 21/09/12 01:12, Dan Xu wrote: Kurchi, Can you append bug number 7197662 to @bug field in each test so that it is easy to check its history? Yes, this is always a good idea. For your changes, I wonder why you choose to run these tests in othervm mode. Thanks! The tests need to run in

Re: Code Review Request: 7197662: (prefs) java/util/prefs/AddNodeChangeListener.java fails by timeout or by couldn't get file lock

2012-09-21 Thread Kurchi Hazra
On 21.09.2012 02:03, Chris Hegarty wrote: On 21/09/12 01:12, Dan Xu wrote: Kurchi, Can you append bug number 7197662 to @bug field in each test so that it is easy to check its history? Yes, this is always a good idea. Sure, I missed adding the bug id. For your changes, I wonder why you

Re: Code Review Request: 7197662: (prefs) java/util/prefs/AddNodeChangeListener.java fails by timeout or by couldn't get file lock

2012-09-21 Thread Weijun Wang
I think jtreg would automatically reset any changed system property so othervm is not necessary. Have you tried running it with other tests in agentvm mode? Thanks Max 在 Sep 22, 2012,2:49 AM,Kurchi Hazra kurchi.subhra.ha...@oracle.com 写道: On 21.09.2012 02:03, Chris Hegarty wrote: On

Code Review Request: 7197662: (prefs) java/util/prefs/AddNodeChangeListener.java fails by timeout or by couldn't get file lock

2012-09-20 Thread Kurchi Hazra
Hi, The tests in java/util/prefs creates new nodes under the user's home directory. This causes the tests to start out with pre-existing preferences and sometimes leads to interference between the tests. This fix is to change the userRoot property for each of these tests so these tests create

Re: Code Review Request: 7197662: (prefs) java/util/prefs/AddNodeChangeListener.java fails by timeout or by couldn't get file lock

2012-09-20 Thread Dan Xu
Kurchi, Can you append bug number 7197662 to @bug field in each test so that it is easy to check its history? For your changes, I wonder why you choose to run these tests in othervm mode. Thanks! -Dan On Thu 20 Sep 2012 02:22:15 PM PDT, Kurchi Hazra wrote: Hi, The tests in