RFR(S): 8238375: JFR Test TestJcmdStartFlushInterval is not run

[mikhailo.seledtsov at oracle.com]

+1

Thanks for fixing this.

On 2/2/20 8:30 AM, Erik Gahlin wrote:
> Hi,
>
> I should get my Eclipse workspace in order :)
>
> We removed getFlushInterval/setFlushInterval from the API because we didn’t think the methods were needed [1]. JFR has a flush interval of 1 s by default. Initially we had a higher number.
>
> We kept the options for -XX:StartFlightRecording and jcmd, so users would have a workaround if they would run into performance issues.
>
> Change looks good, but could you modify the interval to 2s, so the test verifies that a change has actually occurred.
+1, no need for additional webrev for change from 1s to 2s
>
> No need to send out new webrev.
>
> Thanks
> Erik
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8236264
>
>
>> On 2 Feb 2020, at 16:47, Langer, Christoph <christoph.langer at sap.com> wrote:
>>
>> Hi,
>>
>> when culling errors in my Eclipse IDE, I found an issue with JFR test TestJcmdStartFlushInterval. It can never have been run at all, because it contains the jtreg annotation "@run main/othervm jdk.jfr.jcmd.TestJcmdStartReadOnlyFile" and hence runs a different test.
>>
>> The wrong run directive shadows an actual compile time error in the test. The method jdk.jfr.Recording::getFlushInterval is package private, so to be able to invoke it in the test that obviously lives in another package, it has to be made accessible via reflection. Here would be the fix. I, however, don't know why getFlushInterval is package private and whether it couldn't/shouldn't be made a public API.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8238375
>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8238375.0/
>>
>> Cheers
>> Christoph
>>