Fix and disable masterfs lockfile test which is failing since 17u18 #9178
Conversation
this test was patched in past for similar reasons and can start failing again when the JDK updates. testLockFile() is now disabled in CI
mbien
force-pushed
the
fix-lockfile-test-again
branch
from
32dfae6 to
53fc45b
Compare
|
If this happened and patched in the past, do we have a reference on that? |
|
|
||
| @Override | ||
| protected void setUp() throws java.lang.Exception { | ||
| GraphicsEnvironment.isHeadless(); // may cause file reads in a static initializer on linux |
There was a problem hiding this comment.
A little more info would be good to be provided in this issue at least.
There was a problem hiding this comment.
those tests monitor file IO by counting reads/writes. This calls something directly and eagerly which also does file IO. This method would have been called later indirectly by unrelated JDK API which would fail the tests - or worse - fail tests based on JDK update release or order of execution
the hg archive repo seems to be down atm? |
|
merging to delivery so that we have CI again |
lahodaj
left a comment
lahodaj
left a comment
There was a problem hiding this comment.
I think I can live with this. (I would be completely OK with the isHeadless(), counting file accesses inevitably will be tricky and will need some code to warm up - alternative would be to trial-run one or more tests to warm up, and then do the real test run, but that's a bit tricky as well. So the @RandomlFails, well, it is what it is.)
|
we can revisit those test after #9151 is merged, because this will: a) reduce the testing range and we can remove some of the patches again (e.g sections like b) we will have a list of tests which need to be migrated away from SM to JFR or other IO tracing methods and can handle them one by one. |
3 participants
this test was patched in past for similar reasons and can start failing again when the JDK updates.
testLockFile()is now disabled in CI