[
https://issues.apache.org/jira/browse/CASSANDRA-3444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13145637#comment-13145637
]
Jonathan Ellis commented on CASSANDRA-3444:
-------------------------------------------
Where I'm going is that if we've invalidated an index manager, destroying the
record of what columns it indexed feels like the wrong kind of cleanup. Most
often this is going to be called when the parent CF is dropped, so the index is
never actually deleted from the schema (which is what clearing indexesByColumn
implies) just excised as part of the drop.
TLDR: invalidate != removeIndexedColumn.
> Secondary Index doesn't clean up indexed CFS on remove and Streaming test
> failure.
> ----------------------------------------------------------------------------------
>
> Key: CASSANDRA-3444
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3444
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.0
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Priority: Trivial
> Fix For: 1.0.3
>
> Attachments: 0001-clean-indexes-post-remove-and-streaming-tests.patch
>
>
> The initial reason for that issue is because StreamingTransferTest is broken
> in trunk. It has been broken by CASSANDRA-3116 because the latter is too
> efficient. More precisely StreamingTransferTest create a CF with an index,
> then it calls unreferenceSSTables() on that CF to remove all sstable, and
> then try a transfer (that recreate the file and index basically). But when
> unreferenceSSTables() is called, it does fully remove the indexes in that the
> CFS object for the indexes stays. Post CASSANDRA-3116, this is problem
> because that CFS has been invalidated and thus nothing can be added back to
> it.
> Long story short, I believe that the fact that
> SecondaryIndexManager.removeAllIndex doesn't really unreference the CFS
> objects is not expected in the first place. The patch fixes that and update
> the StreamingTransferTest accordingly (fixing it as far as trunk is
> concerned).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
