[ 
https://issues.apache.org/jira/browse/CASSANDRA-4973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13617740#comment-13617740
 ] 

Jeremy Hanna commented on CASSANDRA-4973:
-----------------------------------------

It's worth checking to see if JNA is getting picked up in your startup log.  
For one user, getting the JNA working resolved this problem.
                
> 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

Reply via email to