RFR(S): 8228960: [TESTBUG] containers/docker/TestJcmdWithSideCar.java: jcmd reports main class as 'Unknown'

Bob Vandette bob.vandette at oracle.com
Tue Aug 13 13:34:01 UTC 2019


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.vandette at 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.seledtsov at 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.seledtsov at 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<sgehwolf at redhat.com>  wrote:
>>>>>>> 
>>>>>>> Hi Misha,
>>>>>>> 
>>>>>>> On Tue, 2019-08-06 at 20:17 -0700, mikhailo.seledtsov at 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
>>>>>>> 
> 



More information about the serviceability-dev mailing list