You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Sylvain Lebresne (JIRA)" <ji...@apache.org> on 2015/09/30 20:39:04 UTC

[jira] [Commented] (CASSANDRA-9774) fix sstableverify dtest

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