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
