Hi Bob,
The workdir (JTwork/scratch) is created with the "test user"
permissions. Let me try to place the "signal" file in /tmp instead,
since /tmp should normally have a 777 permission on Linux.
If this works, I will have to add some unique number to the file name,
perhaps a PID of a child process.
I will try this, and let you know how it works.
Thank you,
Misha
On 8/13/19 6:34 AM, Bob Vandette wrote:
Sorry, I just looked at the webrev and you are trying the approach I suggested.
I thought you
were trying to use file change notification.
Where does the workdir get created? Does it have 777 permissions?
Bob.
On Aug 13, 2019, at 9:29 AM, Bob Vandette <bob.vande...@oracle.com> wrote:
What if you just poll for the creation of the file waiting some small amount of
time between polling with a maximum timeout.
Bob.
On Aug 12, 2019, at 8:22 PM, mikhailo.seledt...@oracle.com wrote:
Unfortunately, this approach does not seem to work on many of our test cluster machines. The
creation of a "signal" file results in "PermissionDenied".
The possible reason is the selinux configuration, or some other permission
related stuff. The container tries to create a new file on a mounted volume on
a host system, but host system denies it. I will look a bit deeper into this,
but I think this type of issue can be encountered on any automated test system.
Hence, we may have to abandon this approach.
Thanks,
Misha
On 8/12/19 3:59 PM, mikhailo.seledt...@oracle.com wrote:
Here is an updated webrev: http://cr.openjdk.java.net/~mseledtsov/8228960.01/
I am using a simple file-based mechanism to communicate between the processes. The
"EventGeneratorLoop" process creates a specific "signal" file on a shared
mounted volume, while the main test process waits for the file to exist before running the test
cases.
Passes on Linux-x64 Docker-enabled host. Testing in the test cluster is in
progress.
Thank you,
Misha
On 8/7/19 5:11 PM, David Holmes wrote:
On 8/08/2019 9:04 am, Mikhailo Seledtsov wrote:
Hi Severin, Bob,
Thank you for reviewing the code.
On 8/7/19, 11:38 AM, Bob Vandette wrote:
Can’t you come up with a better way of synchronizing the test by possibly
writing a
file and waiting for it to exist with a timeout?
I will try out this approach.
This seems like a fundamental problem with jcmd - so cc'ing serviceability-dev.
But I'm pretty sure they recently addressed a similar issue with the premature
sending of the attach signal?
David
-----
Thanks,
Misha
Isn’t there a shared volume between the two
processes?
We’ve been fighting test reliability for a while now. I can only hope we’re
getting
to the end.
Bob.
On Aug 7, 2019, at 2:18 PM, Severin Gehwolf<sgehw...@redhat.com> wrote:
Hi Misha,
On Tue, 2019-08-06 at 20:17 -0700, mikhailo.seledt...@oracle.com wrote:
Please review this change that fixes a container test TestJcmdWithSideCar.
My investigation indicated that a root cause for this failure is:
JCMD -l shows 'Unknown' for class name because the main class has not
been loaded yet.
The target test JVM has started, it is initializing, but has not loaded
the main test class.
That's what I've found too.
The proposed solution is to try 'jcmd -l' several times, with a short
sleep in between.
Thread.sleep() isn't great, but I'm not sure there is an alternative.
Also I have commented out the testCase02() due to another bug:
"JDK-8228850: jhsdb jinfo fails with ClassCastException:
s.j.h.oops.TypeArray cannot be cast to s.j.h.oops.Instance",
which is not a test bug. IMO, it is better to run the test and skip a
sub-case than to skip the entire test.
JBS: https://bugs.openjdk.java.net/browse/JDK-8228960
Webrev: http://cr.openjdk.java.net/~mseledtsov/8228960.00/
Looks OK to me.
Thanks,
Severin
