[
https://issues.apache.org/jira/browse/LUCENE-5786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14040655#comment-14040655
]
Dawid Weiss commented on LUCENE-5786:
-------------------------------------
I think this may actually be a bug in RR code. Here's why -- writing is done
via RandomAccessFile and it used to have flush() method but at some point it
was commented out:
{code}
@Override
public void flush() throws IOException {
- raf.getChannel().force(true);
+ // This was causing intermittent channel invalidations on Windows for
+ // no apparent reason. Also, it shouldn't be a problem if we don't sync
+ // with the disk (and use OS cache only)?
+ // raf.getChannel().force(true);
}
{code}
So it either randomly fails on Windows or it will not sync properly on FreeBSD.
Nice. I'll revert to simple FileOutputStream and see if this improves things.
> Unflushed/ truncated events file (hung testing subprocess)
> ----------------------------------------------------------
>
> Key: LUCENE-5786
> URL: https://issues.apache.org/jira/browse/LUCENE-5786
> Project: Lucene - Core
> Issue Type: Bug
> Components: general/test
> Reporter: Dawid Weiss
> Assignee: Dawid Weiss
>
> This has happened several times on Jenkins, typically on
> SSLMigrationTest.testDistribSearch, but probably on other tests as well.
> The symptom is: the test framework never terminates, it also reports an
> incorrect (?) hung test.
> The problem is that the actual forked JVM is hung on reading stdin, waiting
> for the next test suite (no test thread is present); the master process is
> hung on receiving data from the forked jvm (both the events file and stdout
> spill is truncated in the middle of a test). The last output is:
> {code}
> [
> "APPEND_STDERR",
> {
> "chunk": "612639 T30203 oasu.DefaultSolrCoreState.doRecovery Running
> recovery - first canceling any ongoing recovery%0A"
> }
> ]
> [
> "APPEND_STDERR"
> {code}
> Overall, it looks insane -- there are flushes after each test completes
> (normally or not), there are tests *following* the one that last reported
> output and before dynamic suites on stdin.
> I have no idea. The best explanation is insane -- looks like the test thread
> just died in the middle of executing Java code...
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
