RFR [XS]: 8229370: make jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable

[Baesken, Matthias]

Hi David /  Mikhailo ,  I  adjusted the test a bit more , and also  added   (+enabled) UL-based   jfr,event  tracing  in src/hotspot/share/jfr/periodic/jfrNetworkUtilization.cpp
  to better see  the recorded event information .  

The current revision

http://cr.openjdk.java.net/~mbaesken/webrevs/8229370.3/

sends   DatagramPackets   to     all     InetAddresses     of    all   network interfaces  of the machine  .
I observed  that on our "problematic" machine  where the test  fails  we still need a little  delay   to see the   read / write   counters   (fetched by os_perf and then used in the JFR)
   increase on the machine ( that’s why I wait a bit before every send operation).

Could you  please  check   8229370.3    also in your infrastructure where you noticed   sporadic failures   in  jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java   and tell me
 about the results ?


Best regards, Matthias


> Subject: Re: RFR [XS]: 8229370: make
> jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable
> 
> Hi Matthias,
> 
> On 24/09/2019 12:23 am, Baesken, Matthias wrote:
> > Hi David /  Mikhailo , I was busy with other tasks  but today  got back to
> 8229370 .
> >
> > I noticed that in the meantime,   the test was excluded  with
> >
> > https://bugs.openjdk.java.net/browse/JDK-8230115
> >
> > "Problemlist JFR TestNetworkUtilization test"
> >
> >
> > Do you think we still should  rely  on the OS counters , and expect to get  2+
> network interfaces,  or  keep  the test excluded (or just relax  the check and
> check for 1+  network interfaces on Linux)  ?
> 
> Exclusion is just a temporary measure to clean up the testing results,
> so this still needs to be fixed. I have nothing further to add from my
> comments in the bug:
> 
>  > So it should be as simple as changing 10.0.0.0:12345 into something
>  > guaranteed to work?
>  >
>  > I think this needs to be looked at by the JFR folk and net-dev folk to
>  > come up with a valid testing scenario.
> 
> It's not the number of interfaces that is the issue, it is generating
> traffic on the real interface.
> 
> Thanks,
> David
> 
> >
> > Best regards, Matthias
> >
> >
> >
> >>
> >> On 29/08/2019 12:24 am, Baesken, Matthias wrote:
> >>> Hi David ,   I could  add some  optional  UL logging  to see   what happens.
> >>
> >> I just want to see more visibility at the test level to ensure it is
> >> finding the interfaces and addresses I would expect it to find.
> >>
> >> David
> >>
> >>> Maybe the  OS counters   that are fetched by   os_perf    are not that
> >> reliable on some  kernels .
> >>>
> >>>
> >>> Best regards, Matthias
> >>>
> >