RFR(M): 8221711: [TESTBUG] create more tests for JFR in container environment

[Erik Gahlin]

Hi Misha,

I'm a bit confused. I thought the purpose of JFrReporter was to write 
out the result of a recording in a container and let TestJFREvents do 
the actual verification by looking at the result from standard out.

This doesn't seem to be the case with testEnvironmentVariables. It seems 
like it is doing both, or am I missing something?

Would it be possible to simplify the JFrReporter into something like this:

public class JfrReporter {

   public static void main(String[] args) throws Exception {
     String eventName = args[1];
     try(Recording r = new Recording()) {
       r.enable(eventName);
       r.start();
       r.stop();
       Path p = Paths.get("tmp", eventName + ".jfr");
       r.dump(p);
       for (RecordedEvent e : RecordingFile.readAllEvents(p)) {
         for (ValueDescriptor v : e.getEventType().getFields()) {
           System.out.println(v.getName() + " = " + 
e.getValue(v.getName()));
         }
       }
     }
   }
}

and move all the logic into TestJFREvents? Maybe there is an argument 
against this, but I'm curious.

In JfrNetwork.java, you wait for 5 seconds for a join. It seems brittle 
to depend on a thread getting  scheduled or not. Could we create 
something more deterministic, and not depend on something happening 
within a specific time?

Thanks
Erik

>
>
> On 4/8/19 8:28 PM, mikhailo.seledtsov at oracle.com wrote:
>> Please review this change that adds two more test cases for JFR 
>> events in the container environment:
>>   - making sure environment variables are reported correctly inside 
>> the container
>>   - host info is reported correctly inside the container
>>
>>     JBS: https://bugs.openjdk.java.net/browse/JDK-8221711
>>     Webrev: http://cr.openjdk.java.net/~mseledtsov/8221711.01/
>>     Testing:
>>       Ran the affected tests on a single host - PASS
>>       On multiple host variety - In PROGRESS
>>
>>
>> Thank you,
>> Misha
>>
>