[ 
https://issues.apache.org/jira/browse/CASSANDRA-7000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13965530#comment-13965530
 ] 

Tyler Hobbs commented on CASSANDRA-7000:
----------------------------------------

bq.  While doing so, validation compaction does not acquire reference since 
SSTables are from snapshot.

Opening the SSTableReader implicitly involves acquiring a reference (they 
always start with a reference count of 1)

bq. Shouldn't SSTableReader be closable regardless of reference acuired?

I don't think so, but perhaps I'm missing a case where it would make sense to 
close an SSTable with a non-zero reference count.  I believe the correct patch 
would be to release the reference on the SSTableReaders after the validation 
compaction has completed instead of directly calling close().

> 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
>            Assignee: Ben Chan
>         Attachments: sstablereader-assertion-bisect-helper, 
> sstablereader-assertion-bisect-helper-v2, 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-v2
> {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?
> Edit: accidentally uploaded a flawed version of 
> {{sstablereader-assertion-bisect-helper}} (doesn't work out-of-the-box with 
> {{git bisect}}).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to