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 >>>>>>
