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

Reply via email to