Hi, Jay. On 24/04/2018 23:27, Jayathirth D V wrote:
I went through the changes done in JDK-8175968 and I can understand why you would have added creation of multiple CustomFileSystemView like stress test scenario. But as you have mentioned in highly loaded systems there can sometimes be problem with CleanerFactory clearing all listeners on time under GC.
Correct.
1) Instead of decreasing the number of CustomFileSystemView to 1, can we add some wait after we generate OOM in test case and check for number of listeners later.
The problem here is that there is no reliable ways to know when all listeners(allocated in 30 seconds) will be cleaned, and how many time we can spent on wait. I tried to generate OOM a few times, or set an additional delay to 5 seconds but it fails time to time(Ofcourse I can change it to 30 seconds and more, but I am not sure that it will be enough for all configurations). I assume in such cases this test was executed on the test systems in parallel with some other heavyweight tests. Since it is enough to check only one instance of FileSystemView to reproduce the bug for which this test was created, I have changed the test this way.
2) Also adding jtreg @summary tag would help to understand the basic functionality of test case.
webrev is updated: http://cr.openjdk.java.net/~serb/8198342/webrev.01 -- Best regards, Sergey.
