[
https://issues.apache.org/jira/browse/CASSANDRA-4973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13619781#comment-13619781
]
Alexei Bakanov edited comment on CASSANDRA-4973 at 4/2/13 1:19 PM:
-------------------------------------------------------------------
Enabling JNA didn't make any difference to the test I made. What did make the
difference was running my test with latest C* version like this:
$ CASSANDRA_VERSION=1.2.3 nosetests secondary_index_rowcache_restart_test.py
While running the test with C* 1.2.1 and 1.2.2 randomly passed and failed, the
1.2.3 version passes every time I run it. What exactly was fixed in 1.2.3 that
makes the test pass every time is hard for me to tell:)
was (Author: alexeibakanov):
Enabling JNA didn't make any difference to the test. What made the
difference was running my test with latest C* like this:
> Secondary Index stops returning rows when caching=ALL
> -----------------------------------------------------
>
> Key: CASSANDRA-4973
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4973
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.1.2, 1.1.6
> Environment: Centos 6.3, Java 1.6.0_35, cass. 1.1.2 upgraded to 1.1.6
> Reporter: Daniel Strawson
> Attachments: secondary_index_rowcache_restart_test.py
>
>
> I've been using cassandra on a project for a little while in development and
> have recently suddenly started having an issue where the secondary index
> stops working, this is happening on my new production system, we are not yet
> live. Things work ok one moment, then suddenly queries to the cf through
> the secondary index stop returning data. I've seen it happen on 3 CFs. I've
> tried:
> - various nodetools repair / scrub / rebuild_indexes options, none seem to
> make a difference.
> - Doing a 'update column family <whatever> with column_metadata=[]' then
> repeating with my correct column_metadata definition. This seems to fix the
> problem (temporarily) until it comes back.
> The last time it happened I had just restarted cassandra, so it could be that
> which is causing the issue, I've got the production system ok at the moment,
> I will try restarting a bit later when its not being used and if I can get
> the issue to reoccur I will add more information.
> The problem first manifested itself in 1.1.2, so I upgraded to 1.1.6, this
> has not fixed it.
> Here is an example of the create column family I'm using for one of the CFs
> that affected:
> create column family region
> with column_type = 'Standard'
> and comparator = 'UTF8Type'
> and default_validation_class = 'BytesType'
> and key_validation_class = 'UTF8Type'
> and read_repair_chance = 0.1
> and dclocal_read_repair_chance = 0.0
> and gc_grace = 864000
> and min_compaction_threshold = 4
> and max_compaction_threshold = 32
> and replicate_on_write = true
> and compaction_strategy =
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'
> and caching = 'KEYS_ONLY'
> and column_metadata = [
>
> {column_name : 'label',
> validation_class : UTF8Type},
>
> {column_name : 'countryCode',
> validation_class : UTF8Type,
> index_name : 'region_countryCode_idx',
> index_type : 0},
>
> ]
> and compression_options = {'sstable_compression' :
> 'org.apache.cassandra.io.compress.SnappyCompressor'};
> I've noticed that CASSANDRA-4785 looks similar, in my case once the system
> has the problem, it doesn't go away until I fix it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
