[
https://issues.apache.org/jira/browse/SOLR-8292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated SOLR-8292:
---------------------------------
Description:
This came to light in CDCR testing, which stresses this code a lot, there's a
stack trace showing this line (641 trunk) throwing an EOF exception:
o = codec.readVal(fis);
At first I thought to just wrap reading fis in a try/catch and return null, but
looking at the code a bit more I'm not so sure, that seems like it'd mask what
looks at first glance like a bug in the logic.
A few lines earlier (633-4) there's these lines:
// shouldn't currently happen - header and first record are currently written
at the same time
if (fis.position() >= fos.size()) {
Why are we comparing the the input file position against the size of the output
file? Maybe because the 'i' key is right next to the 'o' key? The comment hints
that it's checking for the ability to read the first record in input stream
along with the header. And perhaps there's a different issue here because the
expectation clearly is that the first record should be there if the header is.
So what's the right thing to do? Wrap in a try/catch and return null for EOF?
Change the test? Do both?
I can take care of either, but wanted a clue whether the comparison of fis to
fos is intended.
was:
This came to light in CDCR testing, which stresses this code a lot, there's a
stack trace showing this line (641 trunk) throwing an EOF exception:
o = codec.readVal(fis);
At first I thought to just wrap reading fis in a try/catch and return null, but
looking at the code a bit more I'm not so sure, that seems like it'd mask what
looks at first glance like a bug in the logic.
A few lines earlier (633-4) there's these lines:
// shouldn't currently happen - header and first record are currently written
at the same time
if (fis.position() >= fos.size()) {
Why are we comparing the position of the input file position against the size
of the output file? Maybe because the 'i' key is right next to the 'o' key? The
comment hints that it's checking for the ability to read the first record in
input stream along with the header. And perhaps there's a different issue here
because the expectation clearly is that the first record should be there if the
header is.
So what's the right thing to do? Wrap in a try/catch and return null for EOF?
Change the test? Do both?
I can take care of either, but wanted a clue whether the comparison of fis to
fos is intended.
> TransactionLog.next() does not honor contract and return null for EOF
> ---------------------------------------------------------------------
>
> Key: SOLR-8292
> URL: https://issues.apache.org/jira/browse/SOLR-8292
> Project: Solr
> Issue Type: Bug
> Reporter: Erick Erickson
>
> This came to light in CDCR testing, which stresses this code a lot, there's a
> stack trace showing this line (641 trunk) throwing an EOF exception:
> o = codec.readVal(fis);
> At first I thought to just wrap reading fis in a try/catch and return null,
> but looking at the code a bit more I'm not so sure, that seems like it'd mask
> what looks at first glance like a bug in the logic.
> A few lines earlier (633-4) there's these lines:
> // shouldn't currently happen - header and first record are currently written
> at the same time
> if (fis.position() >= fos.size()) {
> Why are we comparing the the input file position against the size of the
> output file? Maybe because the 'i' key is right next to the 'o' key? The
> comment hints that it's checking for the ability to read the first record in
> input stream along with the header. And perhaps there's a different issue
> here because the expectation clearly is that the first record should be there
> if the header is.
> So what's the right thing to do? Wrap in a try/catch and return null for EOF?
> Change the test? Do both?
> I can take care of either, but wanted a clue whether the comparison of fis to
> fos is intended.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
