Hmm, I took a quick look at this and the only non-CDCR places that call this method test for null on return. They also drop into exceptions which looks like a different code path than expected for EOF, see UpdateLog#LogReplayer#doReplay (lines 1,337 and 1,347 in trunk).
I've put in a _very_ simple patch in TransactionLog.next() to wrap the Object o = codec.readVal() and catch EOFException, returning null in that case and I'm running tests now. Looks like a JIRA to me. I wonder how this is affecting tlog replays? On Fri, Nov 13, 2015 at 9:03 AM, Renaud Delbru <[email protected]> wrote: > Dear all, > > in one of the unit tests of CDCR, we stumble upon the following issue: > > [junit4] 2> java.io.EOFException > [junit4] 2> at > org.apache.solr.common.util.FastInputStream.readByte(FastInputStream.java:208) > [junit4] 2> at > org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:198) > [junit4] 2> at > org.apache.solr.update.TransactionLog$LogReader.next(TransactionLog.java:641) > [junit4] 2> at > org.apache.solr.update.CdcrTransactionLog$CdcrLogReader.next(CdcrTransactionLog.java:154) > > From the comment of the LogReader#next() method, the contract should have > been to return null if EOF is reached. However, this does not seem to be > respected as per stack trace. Is it a bug and should I open an issue to fix > it ? Or is it just the method comment that is not up to date (and should be > probably fixed as well) ? > > Thanks > -- > Renaud Delbru --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
