[
https://issues.apache.org/jira/browse/CASSANDRA-9774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14938242#comment-14938242
]
Sylvain Lebresne commented on CASSANDRA-9774:
---------------------------------------------
I had a look at this dtest and I'm pretty convinced it's the test that is
broken and I've pushed changes (of the dtest) to fix it
[here|https://github.com/pcmanus/cassandra-dtest/commits/9774]. The break down
of the problems is:
# I'm not really sure why the test is checking the log for "was not released
before the reference was garbage collected", there is no particular reason to
check for it at that particular place (what could make sense is to have all the
offline test check for errors in the log, which would catch this in particular,
but that's a different issue). But if anything, getting that message is a bug,
not a feature, so not getting it for 3.0 is good and certainly not something
that "blocks" RC2. So anyway, I've removed that check from the test. I'll note
that the fact this does happen in 2.2 warrants a look, and I'll finish tracking
that down tomorrow and create a proper ticket for it (but again, it's a 2.2
issue).
# The whole part about the test deleting a sstable and expecting sstableverify
to detect it is bogus since sstableverify is not able to detect such thing. In
fact, the comment in the test saying that it "ensure the missing table is
found" is inconsistent with the fact the test expects a return of {{0}} from
the next call. So anyway, I think we can/should remove that part of the test.
# we seems to send a slightly different message in 2.2 and 3.0 when a corrupted
sstable is found, so even with the changes above the test doesn't pass on 3.0.
And as the message is imo better in 3.0, I've just made the test last assertion
be version dependent.
Overall, I don't think there is a problem with sstableverify itself and the
attached dtest branch makes the test pass.
> fix sstableverify dtest
> -----------------------
>
> Key: CASSANDRA-9774
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9774
> Project: Cassandra
> Issue Type: Bug
> Reporter: Jim Witschey
> Assignee: Jeff Jirsa
> Priority: Blocker
> Fix For: 3.0.0 rc2
>
>
> One of our dtests for {{sstableverify}}
> ({{offline_tools_test.py:TestOfflineTools.sstableverify_test}}) is failing
> hard on trunk ([cassci
> history|http://cassci.datastax.com/view/trunk/job/trunk_dtest/lastCompletedBuild/testReport/offline_tools_test/TestOfflineTools/sstableverify_test/history/])
> The way the test works is by deleting an SSTable, then running
> {{sstableverify}} on its table. In earlier versions, it successfully detects
> this problem and outputs that it "was not released before the reference was
> garbage collected". The test no longer finds this string in the output;
> looking through the output of the test, it doesn't look like it reports any
> problems at all.
> EDIT: After digging into the C* source a bit, I may have misattributed the
> problem to {{sstableverify}}; this could be a more general memory management
> problem, as the error text expected in the dtest is emitted by part of the
> {{Ref}} implementation:
> https://github.com/apache/cassandra/blob/075ff5000ced24b42f3b540815cae471bee4049d/src/java/org/apache/cassandra/utils/concurrent/Ref.java#L187
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)