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