cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ben Chan (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-7000) Assertion in SSTableReader during repair.
Date Tue, 08 Apr 2014 23:14:14 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-7000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Ben Chan updated CASSANDRA-7000:
--------------------------------

    Description: 
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}}).


  was:
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?



> 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)

Mime
View raw message