RFR [XS]: 8229370: make jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable
David Holmes
david.holmes at oracle.com
Tue Aug 27 07:55:54 UTC 2019
Hi Matthias,
On 27/08/2019 5:41 pm, Baesken, Matthias wrote:
> Hello, any reviews for this small change ?
I missed the initial request - sorry.
Seems we have a double up of effort here as we also have JDK-8228990 for
the exact same problem that we see on some of our test machines.
Our analysis suggests that this test often passes by accident due to
incidental activity on the real network interface when the logic
intended to generate that activity (the packet sent to 10.0.0.0:12345)
actually had no affect (unreachable address). If there is no incidental
network activity then the real network interface is not seen and so the
test fails.
David
> Thanks , Matthias
>
> From: Baesken, Matthias
> Sent: Montag, 12. August 2019 14:33
> To: 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>; 'hotspot-jfr-dev at openjdk.java.net' <hotspot-jfr-dev at openjdk.java.net>
> Subject: RFR [XS]: 8229370: make jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable
>
> Hello, please review this small test enhancement.
>
> We noticed that on some of our Linux machines (SLES12 based) the TestNetworkUtilizationEvent.java test reported just 1 interface
> (the test TestNetworkUtilizationEvent.java expects more than 1 on Linux).
>
> Looking into the HS code , os_perf_linux.cpp collects the interfaces + additional information about bytes read/written (by looking at /sys/class/net/eth<X>/statistics/<countername> )
> and this info is given to JFR .
>
> However it seems to need (at least on some machines / setups) more packet send operations / potential retries to really get counter updates (and without updates in the counters, no interfaces are found).
> So I adjusted the test accordingly.
>
>
> Bug/webrev :
>
> https://bugs.openjdk.java.net/browse/JDK-8229370
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8229370.0/
>
>
> Best regards, Matthias
>
More information about the hotspot-jfr-dev
mailing list