Ben Chan created CASSANDRA-7000:
-----------------------------------
Summary: Assertion in SSTableReader during repair.
Key: CASSANDRA-7000
URL: https://issues.apache.org/jira/browse/CASSANDRA-7000
Project: Cassandra
Issue Type: Bug
Reporter: Ben Chan
Attachments: sstablereader-assertion-bisect-helper,
sstablereader-assertion.patch
I ran a {{git bisect run}} using the attached bisect script. Repro code:
{noformat}
# 5dfe241: trunk as of my git bisect run
# 345772d: empirically determined "good" commit.
git bisect start 5dfe241 345772d
git bisect run ./sstablereader-assertion-bisect-helper
{noformat}
The first failing commit is 5ebadc1 (first parent of {{refs/bisect/bad}}).
Prior to 5ebadc1, SSTableReader#close() never checked reference count. After
5ebadc1, there was an assertion for {{references.get() == 0}}. However, since
the reference count is initialized to 1, a SSTableReader#close() was always
guaranteed to either throw an AssertionError or to be a second call to
SSTableReader#tidy() on the same SSTableReader.
The attached patch chooses an in-between behavior. It requires the reference
count to match the initialization value of 1 for SSTableReader#close(), and the
same behavior as 5ebadc1 otherwise.
This allows repair to finish successfully, but I'm not 100% certain what the
desired behavior is for SSTableReader#close(). Should it close without regard
to reference count, as it did pre-5ebadc1?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
