[jira] [Created] (CASSANDRA-3932) schema IAE and read path NPE after cluster re-deploy

2012-02-18 Thread Peter Schuller (Created) (JIRA) 
schema IAE and read path NPE after cluster re-deploy


 Key: CASSANDRA-3932
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3932
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Peter Schuller
Assignee: Peter Schuller
 Fix For: 1.1.0


On the same cluster (but later) as the one where we observed CASSANDRA-3931 we 
were running some performance/latency testing. ycsb reads, plus a separate 
little python client. All was fine.

I then did a fast re-deploy for changed GC settings, which would have let to a 
complete cluster restart almost simultaneously (triggering races?). When I 
re-ran my Python client, I suddenly got an error saying Keyspace1 did not 
exist. On re-run I started getting timeouts. Looking at the endpoints of the 
key that I was getting a timeout for, the first error ever seen is:

{code}
java.lang.IllegalArgumentException: Unknown ColumnFamily Standard1 in keyspace 
Keyspace1
at org.apache.cassandra.config.Schema.getComparator(Schema.java:234)
at 
org.apache.cassandra.db.ColumnFamily.getComparatorFor(ColumnFamily.java:312)
at 
org.apache.cassandra.db.ReadCommand.getComparator(ReadCommand.java:94)
at 
org.apache.cassandra.db.SliceByNamesReadCommand.(SliceByNamesReadCommand.java:44)
at 
org.apache.cassandra.db.SliceByNamesReadCommandSerializer.deserialize(SliceByNamesReadCommand.java:113)
at 
org.apache.cassandra.db.SliceByNamesReadCommandSerializer.deserialize(SliceByNamesReadCommand.java:81)
at 
org.apache.cassandra.db.ReadCommandSerializer.deserialize(ReadCommand.java:134)
at 
org.apache.cassandra.db.ReadVerbHandler.doVerb(ReadVerbHandler.java:53)
at 
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
{code}

And later in the read path NPE:s like these:

{code}
java.lang.NullPointerException
at 
org.apache.cassandra.db.Table.createReplicationStrategy(Table.java:321)
at org.apache.cassandra.db.Table.(Table.java:277)
at org.apache.cassandra.db.Table.open(Table.java:120)
at org.apache.cassandra.db.Table.open(Table.java:103)
at 
org.apache.cassandra.db.ReadVerbHandler.doVerb(ReadVerbHandler.java:54)
at 
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
{code}


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

[jira] [Assigned] (CASSANDRA-3931) gossipers notion of schema differs from reality as reported by the nodes in question

2012-02-18 Thread Peter Schuller (Assigned) (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-3931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Peter Schuller reassigned CASSANDRA-3931:
-

Assignee: Peter Schuller

> gossipers notion of schema differs from reality as reported by the nodes in 
> question
> 
>
> Key: CASSANDRA-3931
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3931
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Peter Schuller
>Assignee: Peter Schuller
> Fix For: 1.1.0
>
>
> On a 1.1 cluster we happened to notice that {{nodetool gossipinfo | grep 
> SCHEMA}} reported disagreement:
> {code}
>   SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
>   SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
>   SCHEMA:b0d7bab7-c13c-37d9-9adb-8ab8a5b7215d
>   SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
>   SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
>   SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
>   SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
>   SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
>   SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
>   SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
>   SCHEMA:bcdbd318-82df-3518-89e3-6b72227b3f66
>   SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
>   SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
>   SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
>   SCHEMA:bcdbd318-82df-3518-89e3-6b72227b3f66
>   SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
>   SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
>   SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
>   SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
>   SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
> {code}
> However, the result of a thrift {{describe_ring}} on the cluster claims they 
> all agree and that {{b0d7bab7-c13c-37d9-9adb-8ab8a5b7215d}} is the schema 
> they have.
> The schemas seem to "actually" propagate; e.g. dropping a keyspace actually 
> drops the keyspace.

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

[Cassandra Wiki] Trivial Update of "GettingStarted" by MakiWatanabe

2012-02-18 Thread Apache Wiki 
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for 
change notification.

The "GettingStarted" page has been changed by MakiWatanabe:
http://wiki.apache.org/cassandra/GettingStarted?action=diff&rev1=60&rev2=61

Comment:
fix remaining reference to SVN checkout

  == Step 2: Running a single node ==
  Cassandra is meant to run on a cluster of nodes, but will run equally well on 
a single machine. This is a handy way of getting familiar with the software 
while avoiding the complexities of a larger system.
  
- Since there isn't currently an installation method per se, the easiest 
solution is to simply run Cassandra from an extracted archive<>> or SVN 
checkout (see: [[#picking_a_version|Picking a version]]). Also, unless you've 
downloaded a binary distribution, you'll need to compile the software by 
invoking `ant` from the top-level directory.
+ Since there isn't currently an installation method per se, the easiest 
solution is to simply run Cassandra from an extracted archive<>> or Git 
checkout (see: [[#picking_a_version|Picking a version]]). Also, unless you've 
downloaded a binary distribution, you'll need to compile the software by 
invoking `ant` from the top-level directory.
  
  The distribution's sample configuration `conf/cassandra.yaml` contains 
reasonable defaults for single node operation, but you will need to make sure 
that the paths exist for `data_file_directories`, `commitlog_directory`, and 
`saved_caches_directory`. Additionally, take a minute now to look over the 
logging configuration in `conf/log4j.properties` and make sure that directories 
exist for the configured log file(s) as well.

[jira] [Commented] (CASSANDRA-3931) gossipers notion of schema differs from reality as reported by the nodes in question

2012-02-18 Thread Peter Schuller (Commented) (JIRA) 

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

Peter Schuller commented on CASSANDRA-3931:
---

I forgot to mention that {{describe_ring}} is using a piece of code that 
actually sends messages to other nodes asking for their schema, while 
{{gossipinfo}} is giving the information contained in the Gossiper's endpoint 
state map.

Given that the schema seems to *actually* be propagated, I suspect this is only 
a gossiping propagation bug but that is not confirmed.

> gossipers notion of schema differs from reality as reported by the nodes in 
> question
> 
>
> Key: CASSANDRA-3931
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3931
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Peter Schuller
> Fix For: 1.1.0
>
>
> On a 1.1 cluster we happened to notice that {{nodetool gossipinfo | grep 
> SCHEMA}} reported disagreement:
> {code}
>   SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
>   SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
>   SCHEMA:b0d7bab7-c13c-37d9-9adb-8ab8a5b7215d
>   SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
>   SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
>   SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
>   SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
>   SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
>   SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
>   SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
>   SCHEMA:bcdbd318-82df-3518-89e3-6b72227b3f66
>   SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
>   SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
>   SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
>   SCHEMA:bcdbd318-82df-3518-89e3-6b72227b3f66
>   SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
>   SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
>   SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
>   SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
>   SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
> {code}
> However, the result of a thrift {{describe_ring}} on the cluster claims they 
> all agree and that {{b0d7bab7-c13c-37d9-9adb-8ab8a5b7215d}} is the schema 
> they have.
> The schemas seem to "actually" propagate; e.g. dropping a keyspace actually 
> drops the keyspace.

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

[jira] [Created] (CASSANDRA-3931) gossipers notion of schema differs from reality as reported by the nodes in question

2012-02-18 Thread Peter Schuller (Created) (JIRA) 
gossipers notion of schema differs from reality as reported by the nodes in 
question


 Key: CASSANDRA-3931
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3931
 Project: Cassandra
  Issue Type: Bug
Reporter: Peter Schuller
 Fix For: 1.1.0


On a 1.1 cluster we happened to notice that {{nodetool gossipinfo | grep 
SCHEMA}} reported disagreement:

{code}
  SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
  SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
  SCHEMA:b0d7bab7-c13c-37d9-9adb-8ab8a5b7215d
  SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
  SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
  SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
  SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
  SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
  SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
  SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
  SCHEMA:bcdbd318-82df-3518-89e3-6b72227b3f66
  SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
  SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
  SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
  SCHEMA:bcdbd318-82df-3518-89e3-6b72227b3f66
  SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
  SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
  SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
  SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
  SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
{code}

However, the result of a thrift {{describe_ring}} on the cluster claims they 
all agree and that {{b0d7bab7-c13c-37d9-9adb-8ab8a5b7215d}} is the schema they 
have.

The schemas seem to "actually" propagate; e.g. dropping a keyspace actually 
drops the keyspace.

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

[jira] [Commented] (CASSANDRA-3910) make phi_convict_threshold Float

2012-02-18 Thread Radim Kolar (Commented) (JIRA) 

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

Radim Kolar commented on CASSANDRA-3910:


Yes, there is traffic between nodes and its not benchmark.

What about to gossip via UDP?

> make phi_convict_threshold Float
> 
>
> Key: CASSANDRA-3910
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3910
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 1.0.7
>Reporter: Radim Kolar
>
> I would like to have phi_convict_threshold floating point number instead of 
> integer. Value 8 is too low for me and value 9 is too high. With converting 
> to floating point, it can be better fine tuned.

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

[jira] [Resolved] (CASSANDRA-3511) Supercolumn key caches are not saved

2012-02-18 Thread Jonathan Ellis (Resolved) (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-3511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Ellis resolved CASSANDRA-3511.
---

Resolution: Cannot Reproduce

> Supercolumn key caches are not saved
> 
>
> Key: CASSANDRA-3511
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3511
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.0.2, 1.0.3
>Reporter: Radim Kolar
>Priority: Minor
>  Labels: supercolumns
> Attachments: failed-to-save-after-load-KeyCache, 
> rapidshare-resultcache-KeyCache
>
>
> cache saving seems to be broken in 1.0.2 and 1.0.3 i have 2 CF in keyspace 
> with enabled cache saving and only one gets its key cache saved. It worked 
> perfectly in 0.8, both were saved.
> This one works:
> create column family query2
>   with column_type = 'Standard'
>   and comparator = 'AsciiType'
>   and default_validation_class = 'BytesType'
>   and key_validation_class = 'UTF8Type'
>   and rows_cached = 500.0
>   and row_cache_save_period = 0
>   and row_cache_keys_to_save = 2147483647
>   and keys_cached = 20.0
>   and key_cache_save_period = 14400
>   and read_repair_chance = 1.0
>   and gc_grace = 864000
>   and min_compaction_threshold = 5
>   and max_compaction_threshold = 10
>   and replicate_on_write = false
>   and row_cache_provider = 'ConcurrentLinkedHashCacheProvider'
>   and compaction_strategy = 
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'
> This does not
> create column family dkb13
>   with column_type = 'Super'
>   and comparator = 'LongType'
>   and subcomparator = 'AsciiType'
>   and default_validation_class = 'BytesType'
>   and key_validation_class = 'UTF8Type'
>   and rows_cached = 600.0
>   and row_cache_save_period = 0
>   and row_cache_keys_to_save = 2147483647
>   and keys_cached = 20.0
>   and key_cache_save_period = 14400
>   and read_repair_chance = 1.0
>   and gc_grace = 864000
>   and min_compaction_threshold = 5
>   and max_compaction_threshold = 10
>   and replicate_on_write = false
>   and row_cache_provider = 'ConcurrentLinkedHashCacheProvider'
>   and compaction_strategy = 
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'
> in second test system i created these 2 column families and none of them got 
> single cache key saved. Both have save period 30 seoonds - their cache should 
> save often. Its not that standard column family works while super does not.
> create column family test1
>   with column_type = 'Standard'
>   and comparator = 'BytesType'
>   and default_validation_class = 'BytesType'
>   and key_validation_class = 'BytesType'
>   and rows_cached = 0.0
>   and row_cache_save_period = 0
>   and row_cache_keys_to_save = 2147483647
>   and keys_cached = 20.0
>   and key_cache_save_period = 30
>   and read_repair_chance = 1.0
>   and gc_grace = 864000
>   and min_compaction_threshold = 4
>   and max_compaction_threshold = 32
>   and replicate_on_write = true
>   and row_cache_provider = 'SerializingCacheProvider'
>   and compaction_strategy = 
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy';
> create column family test2
>   with column_type = 'Standard'
>   and comparator = 'BytesType'
>   and default_validation_class = 'BytesType'
>   and key_validation_class = 'BytesType'
>   and rows_cached = 0.0
>   and row_cache_save_period = 0
>   and row_cache_keys_to_save = 2147483647
>   and keys_cached = 20.0
>   and key_cache_save_period = 30
>   and read_repair_chance = 1.0
>   and gc_grace = 864000
>   and min_compaction_threshold = 4
>   and max_compaction_threshold = 32
>   and replicate_on_write = true
>   and row_cache_provider = 'SerializingCacheProvider'
>   and compaction_strategy = 
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy';
> If this is done on purpose for example cassandra 1.0 is doing some heuristic 
> decision if cache should be saved or not then it should be removed. Saving 
> cache is fast.

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

[jira] [Commented] (CASSANDRA-3511) Supercolumn key caches are not saved

2012-02-18 Thread Radim Kolar (Commented) (JIRA) 

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

Radim Kolar commented on CASSANDRA-3511:


i can not reproduce this problem any more at 1.0.7

> Supercolumn key caches are not saved
> 
>
> Key: CASSANDRA-3511
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3511
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.0.2, 1.0.3
>Reporter: Radim Kolar
>Priority: Minor
>  Labels: supercolumns
> Attachments: failed-to-save-after-load-KeyCache, 
> rapidshare-resultcache-KeyCache
>
>
> cache saving seems to be broken in 1.0.2 and 1.0.3 i have 2 CF in keyspace 
> with enabled cache saving and only one gets its key cache saved. It worked 
> perfectly in 0.8, both were saved.
> This one works:
> create column family query2
>   with column_type = 'Standard'
>   and comparator = 'AsciiType'
>   and default_validation_class = 'BytesType'
>   and key_validation_class = 'UTF8Type'
>   and rows_cached = 500.0
>   and row_cache_save_period = 0
>   and row_cache_keys_to_save = 2147483647
>   and keys_cached = 20.0
>   and key_cache_save_period = 14400
>   and read_repair_chance = 1.0
>   and gc_grace = 864000
>   and min_compaction_threshold = 5
>   and max_compaction_threshold = 10
>   and replicate_on_write = false
>   and row_cache_provider = 'ConcurrentLinkedHashCacheProvider'
>   and compaction_strategy = 
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'
> This does not
> create column family dkb13
>   with column_type = 'Super'
>   and comparator = 'LongType'
>   and subcomparator = 'AsciiType'
>   and default_validation_class = 'BytesType'
>   and key_validation_class = 'UTF8Type'
>   and rows_cached = 600.0
>   and row_cache_save_period = 0
>   and row_cache_keys_to_save = 2147483647
>   and keys_cached = 20.0
>   and key_cache_save_period = 14400
>   and read_repair_chance = 1.0
>   and gc_grace = 864000
>   and min_compaction_threshold = 5
>   and max_compaction_threshold = 10
>   and replicate_on_write = false
>   and row_cache_provider = 'ConcurrentLinkedHashCacheProvider'
>   and compaction_strategy = 
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'
> in second test system i created these 2 column families and none of them got 
> single cache key saved. Both have save period 30 seoonds - their cache should 
> save often. Its not that standard column family works while super does not.
> create column family test1
>   with column_type = 'Standard'
>   and comparator = 'BytesType'
>   and default_validation_class = 'BytesType'
>   and key_validation_class = 'BytesType'
>   and rows_cached = 0.0
>   and row_cache_save_period = 0
>   and row_cache_keys_to_save = 2147483647
>   and keys_cached = 20.0
>   and key_cache_save_period = 30
>   and read_repair_chance = 1.0
>   and gc_grace = 864000
>   and min_compaction_threshold = 4
>   and max_compaction_threshold = 32
>   and replicate_on_write = true
>   and row_cache_provider = 'SerializingCacheProvider'
>   and compaction_strategy = 
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy';
> create column family test2
>   with column_type = 'Standard'
>   and comparator = 'BytesType'
>   and default_validation_class = 'BytesType'
>   and key_validation_class = 'BytesType'
>   and rows_cached = 0.0
>   and row_cache_save_period = 0
>   and row_cache_keys_to_save = 2147483647
>   and keys_cached = 20.0
>   and key_cache_save_period = 30
>   and read_repair_chance = 1.0
>   and gc_grace = 864000
>   and min_compaction_threshold = 4
>   and max_compaction_threshold = 32
>   and replicate_on_write = true
>   and row_cache_provider = 'SerializingCacheProvider'
>   and compaction_strategy = 
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy';
> If this is done on purpose for example cassandra 1.0 is doing some heuristic 
> decision if cache should be saved or not then it should be removed. Saving 
> cache is fast.

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