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