[jira] [Comment Edited] (CASSANDRA-13127) Materialized Views: View row expires too soon

[ZhaoYang (JIRA)]

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

ZhaoYang edited comment on CASSANDRA-13127 at 6/27/17 4:36 AM:
---

|| source || junit-result || dtest-result||
| [3.11|https://github.com/jasonstack/cassandra/commits/CASSANDRA-13127-trunk] 
| [utest|https://circleci.com/gh/jasonstack/cassandra/62] | |
| [dtest| https://github.com/jasonstack/cassandra-dtest/commits/CASSANDRA-13127 
 ] | \ | \ |

1. View.mayBeAffectedBy  will return true as long as view-key-values are not 
filtered

2. LivenessInfo.supersedes(another) will check localDeletionTime if timestamps 
are the same. greater localDeletionTimestamp supersedes. 
 



was (Author: jasonstack):
|| source || junit-result || dtest-result||
| [3.11|https://github.com/jasonstack/cassandra/commits/CASSANDRA-13127-trunk] 
| [utest|https://circleci.com/gh/jasonstack/cassandra/59] | |
| [dtest| https://github.com/jasonstack/cassandra-dtest/commits/CASSANDRA-13127 
 ] | \ | \ |

1. View.mayBeAffectedBy  will return true as long as view-key-values are not 
filtered

2. LivenessInfo.supersedes(another) will check localDeletionTime if timestamps 
are the same. greater localDeletionTimestamp supersedes. 
 


> Materialized Views: View row expires too soon
> -
>
> Key: CASSANDRA-13127
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13127
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths, Materialized Views
>Reporter: Duarte Nunes
>Assignee: ZhaoYang
>
> Consider the following commands, ran against trunk:
> {code}
> echo "DROP MATERIALIZED VIEW ks.mv; DROP TABLE ks.base;" | bin/cqlsh
> echo "CREATE TABLE ks.base (p int, c int, v int, PRIMARY KEY (p, c));" | 
> bin/cqlsh
> echo "CREATE MATERIALIZED VIEW ks.mv AS SELECT p, c FROM base WHERE p IS NOT 
> NULL AND c IS NOT NULL PRIMARY KEY (c, p);" | bin/cqlsh
> echo "INSERT INTO ks.base (p, c) VALUES (0, 0) USING TTL 10;" | bin/cqlsh
> # wait for row liveness to get closer to expiration
> sleep 6;
> echo "UPDATE ks.base USING TTL 8 SET v = 0 WHERE p = 0 and c = 0;" | bin/cqlsh
> echo "SELECT p, c, ttl(v) FROM ks.base; SELECT * FROM ks.mv;" | bin/cqlsh
>  p | c | ttl(v)
> ---+---+
>  0 | 0 |  7
> (1 rows)
>  c | p
> ---+---
>  0 | 0
> (1 rows)
> # wait for row liveness to expire
> sleep 4;
> echo "SELECT p, c, ttl(v) FROM ks.base; SELECT * FROM ks.mv;" | bin/cqlsh
>  p | c | ttl(v)
> ---+---+
>  0 | 0 |  3
> (1 rows)
>  c | p
> ---+---
> (0 rows)
> {code}
> Notice how the view row is removed even though the base row is still live. I 
> would say this is because in ViewUpdateGenerator#computeLivenessInfoForEntry 
> the TTLs are compared instead of the expiration times, but I'm not sure I'm 
> getting that far ahead in the code when updating a column that's not in the 
> view.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Comment Edited] (CASSANDRA-11947) Ability to create a Materialized View without primary key column that has '=' relation

[ZhaoYang (JIRA)]

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

ZhaoYang edited comment on CASSANDRA-11947 at 6/27/17 4:11 AM:
---

How about trying following schema? basically the same query as you want.
{code}
cqlsh:jira> CREATE MATERIALIZED VIEW analytics_ww AS
...SELECT * FROM analytics
...WHERE date IS NOT NULL AND resourceId IS NOT NULL AND 
country IS NOT NULL AND country = 'WW' 
...PRIMARY KEY (resourceId, date, country);

{code}

The original idea to stop `collapsing` data in MV (part of base primary key 
columns in view) is to protect user from unexpected tombstones.. But in this 
case, if the `missing primary key in the view` is guarded by a filter 
condition, it should be safe.

If your use case can be done via above example, I suggest won'tfix. 


was (Author: jasonstack):
How about trying following schema? basically the same query as you want.
{code}
cqlsh:jira> CREATE MATERIALIZED VIEW analytics_ww AS
...SELECT * FROM analytics
...WHERE date IS NOT NULL AND resourceId IS NOT NULL AND 
country IS NOT NULL AND country = 'WW' 
...PRIMARY KEY (resourceId, date, country);

{code}

The original idea to stop `collapsing` data in MV (part of base primary key 
columns in view) is to protect user from tombstones.. I think in this case, if 
the `missing primary key in the view` is guarded by a filter condition, it's 
safe.

If your use case can be done via above example, I suggest won'tfix. 

> Ability to create a Materialized View without primary key column that has '=' 
> relation
> --
>
> Key: CASSANDRA-11947
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11947
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Nimi Wariboko Jr.
>
> I have a use case where I'd like to create a materialized view where one of 
> the columns is filtered on a '=' relation and the primary key for that 
> materialized view doesn't include that column.
> Example:
> {code}
> CREATE TABLE analytics (
>   resourceId text,
>   country text,
>   date timestamp,
>   clicks int,
>   PRIMARY KEY(resourceId, date, country)
> );
> CREATE MATERIALIZED VIEW analytics_ww AS
>SELECT * FROM analytics
>WHERE country = 'WW'
>PRIMARY KEY (resourceId, date);
> {code}
> This way I can have a table filtered on a high cardinality column, and I 
> don't also have to specify that column, even though I already know thats the 
> only value in the view.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-11947) Ability to create a Materialized View without primary key column that has '=' relation

[ZhaoYang (JIRA)]

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

ZhaoYang commented on CASSANDRA-11947:
--

How about trying following schema? basically the same query as you want.
{code}
cqlsh:jira> CREATE MATERIALIZED VIEW analytics_ww AS
...SELECT * FROM analytics
...WHERE date IS NOT NULL AND resourceId IS NOT NULL AND 
country IS NOT NULL AND country = 'WW' 
...PRIMARY KEY (resourceId, date, country);

{code}

The original idea to stop `collapsing` data in MV (part of base primary key 
columns in view) is to protect user from tombstones.. I think in this case, if 
the `missing primary key in the view` is guarded by a filter condition, it's 
safe.

If your use case can be done via above example, I suggest won'tfix. 

> Ability to create a Materialized View without primary key column that has '=' 
> relation
> --
>
> Key: CASSANDRA-11947
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11947
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Nimi Wariboko Jr.
>
> I have a use case where I'd like to create a materialized view where one of 
> the columns is filtered on a '=' relation and the primary key for that 
> materialized view doesn't include that column.
> Example:
> {code}
> CREATE TABLE analytics (
>   resourceId text,
>   country text,
>   date timestamp,
>   clicks int,
>   PRIMARY KEY(resourceId, date, country)
> );
> CREATE MATERIALIZED VIEW analytics_ww AS
>SELECT * FROM analytics
>WHERE country = 'WW'
>PRIMARY KEY (resourceId, date);
> {code}
> This way I can have a table filtered on a high cardinality column, and I 
> don't also have to specify that column, even though I already know thats the 
> only value in the view.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13464) Failed to create Materialized view with a specific token range

[Nate McCall (JIRA)]

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

Nate McCall commented on CASSANDRA-13464:
-

bq. So the recommended fix would be to restrict CQL syntax to not use token 
functions in where clause and throw a proper error message (like its currently 
done if functions are used in select clause ) ?

Yeah, that's totally fair. 

> Failed to create Materialized view with a specific token range
> --
>
> Key: CASSANDRA-13464
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13464
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Natsumi Kojima
>Assignee: Krishna Dattu Koneru
>Priority: Minor
>  Labels: materializedviews
>
> Failed to create Materialized view with a specific token range.
> Example :
> {code:java}
> $ ccm create "MaterializedView" -v 3.0.13
> $ ccm populate  -n 3
> $ ccm start
> $ ccm status
> Cluster: 'MaterializedView'
> ---
> node1: UP
> node3: UP
> node2: UP
> $ccm node1 cqlsh
> Connected to MaterializedView at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.0.13 | CQL spec 3.4.0 | Native protocol v4]
> Use HELP for help.
> cqlsh> CREATE KEYSPACE test WITH replication = {'class':'SimpleStrategy', 
> 'replication_factor':3};
> cqlsh> CREATE TABLE test.test ( id text PRIMARY KEY , value1 text , value2 
> text, value3 text);
> $ccm node1 ring test 
> Datacenter: datacenter1
> ==
> AddressRackStatus State   LoadOwns
> Token
>   
> 3074457345618258602
> 127.0.0.1  rack1   Up Normal  64.86 KB100.00% 
> -9223372036854775808
> 127.0.0.2  rack1   Up Normal  86.49 KB100.00% 
> -3074457345618258603
> 127.0.0.3  rack1   Up Normal  89.04 KB100.00% 
> 3074457345618258602
> $ ccm node1 cqlsh
> cqlsh> INSERT INTO test.test (id, value1 , value2, value3 ) VALUES ('aaa', 
> 'aaa', 'aaa' ,'aaa');
> cqlsh> INSERT INTO test.test (id, value1 , value2, value3 ) VALUES ('bbb', 
> 'bbb', 'bbb' ,'bbb');
> cqlsh> SELECT token(id),id,value1 FROM test.test;
>  system.token(id) | id  | value1
> --+-+
>  -4737872923231490581 | aaa |aaa
>  -3071845237020185195 | bbb |bbb
> (2 rows)
> cqlsh> CREATE MATERIALIZED VIEW test.test_view AS SELECT value1, id FROM 
> test.test WHERE id IS NOT NULL AND value1 IS NOT NULL AND TOKEN(id) > 
> -9223372036854775808 AND TOKEN(id) < -3074457345618258603 PRIMARY KEY(value1, 
> id) WITH CLUSTERING ORDER BY (id ASC);
> ServerError: java.lang.ClassCastException: 
> org.apache.cassandra.cql3.TokenRelation cannot be cast to 
> org.apache.cassandra.cql3.SingleColumnRelation
> {code}
> Stacktrace :
> {code:java}
> INFO  [MigrationStage:1] 2017-04-19 18:32:48,131 ColumnFamilyStore.java:389 - 
> Initializing test.test
> WARN  [SharedPool-Worker-1] 2017-04-19 18:44:07,263 FBUtilities.java:337 - 
> Trigger directory doesn't exist, please create it and try again.
> ERROR [SharedPool-Worker-1] 2017-04-19 18:46:10,072 QueryMessage.java:128 - 
> Unexpected error during query
> java.lang.ClassCastException: org.apache.cassandra.cql3.TokenRelation cannot 
> be cast to org.apache.cassandra.cql3.SingleColumnRelation
>   at 
> org.apache.cassandra.db.view.View.relationsToWhereClause(View.java:275) 
> ~[apache-cassandra-3.0.13.jar:3.0.13]
>   at 
> org.apache.cassandra.cql3.statements.CreateViewStatement.announceMigration(CreateViewStatement.java:219)
>  ~[apache-cassandra-3.0.13.jar:3.0.13]
>   at 
> org.apache.cassandra.cql3.statements.SchemaAlteringStatement.execute(SchemaAlteringStatement.java:93)
>  ~[apache-cassandra-3.0.13.jar:3.0.13]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:206)
>  ~[apache-cassandra-3.0.13.jar:3.0.13]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:237) 
> ~[apache-cassandra-3.0.13.jar:3.0.13]
>   at 
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:222) 
> ~[apache-cassandra-3.0.13.jar:3.0.13]
>   at 
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:115)
>  ~[apache-cassandra-3.0.13.jar:3.0.13]
>   at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:513)
>  [apache-cassandra-3.0.13.jar:3.0.13]
>   at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:407)
>  [apache-cassandra-3.0.13.jar:3.0.13]
>   at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [netty-all-4.0.44.Final.jar:4.0.44.Final]
>   at 
> 

[jira] [Commented] (CASSANDRA-13565) Materialized view usage of commit logs requires large mutation but commitlog_segment_size_in_mb=2048 causes exception

[Tania S Engel (JIRA)]

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

Tania S Engel commented on CASSANDRA-13565:
---

To make an unwieldy "wide" partition, is the problem that we have too many 
columns with potentially large varchar data? I am not sure how changing the key 
to LogDay or LogHour would change the "width" of the partition. 

> Materialized view usage of commit logs requires large mutation but 
> commitlog_segment_size_in_mb=2048 causes exception
> -
>
> Key: CASSANDRA-13565
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13565
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration, Materialized Views, Streaming and 
> Messaging
> Environment: Cassandra 3.9.0, Windows 
>Reporter: Tania S Engel
> Attachments: CQLforTable.png
>
>
> We will be upgrading to 3.10 for CASSANDRA-11670. However, there is another 
> scenario (not applyunsafe during JOIN) which leads to :
>   java.lang.IllegalArgumentException: Mutation of 525.847MiB is too large 
> for the maximum size of 512.000MiB
>       at 
> org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:262) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.db.Keyspace.apply(Keyspace.java:493) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.db.Keyspace.apply(Keyspace.java:396) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:215) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.db.Mutation.apply(Mutation.java:227) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.batchlog.BatchlogManager.store(BatchlogManager.java:147) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.service.StorageProxy.mutateMV(StorageProxy.java:797) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.db.view.ViewBuilder.buildKey(ViewBuilder.java:96) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.db.view.ViewBuilder.run(ViewBuilder.java:165) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.db.compaction.CompactionManager$14.run(CompactionManager.java:1591)
>  [apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_66]
>       at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> [na:1.8.0_66]
>       at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_66]
>       at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_66]
>       at java.lang.Thread.run(Thread.java:745) [na:1.8.0_66] 
> Due to the relationship of max_mutation_size_in_kb and 
> commitlog_segment_size_in_mb, we increased commitlog_segment_size_in_mb and 
> left Cassandra to calculate max_mutation_size_in_kb as half the size 
> commitlog_segment_size_in_mb * 1024.
>  However, we have found that if we set commitlog_segment_size_in_mb=2048 we 
> get an exception upon starting Cassandra, when it is creating a new commit 
> log.
> ERROR [COMMIT-LOG-ALLOCATOR] 2017-05-31 17:01:48,005 
> JVMStabilityInspector.java:82 - Exiting due to error while processing commit 
> log during initialization.
> org.apache.cassandra.io.FSWriteError: java.io.IOException: An attempt was 
> made to move the file pointer before the beginning of the file
> Perhaps the index you are using is not big enough and it goes negative.
> Is the relationship between max_mutation_size_in_kb and 
> commitlog_segment_size_in_mb important to preserve? In our limited stress 
> test we are finding mutation size already over 512mb and we expect more data 
> in our sstables and associated materialized views.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13547) Filtered materialized views missing data

[Krishna Dattu Koneru (JIRA)]

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

Krishna Dattu Koneru commented on CASSANDRA-13547:
--

Hey [~jasonstack] I saw that you are working on related issue 
https://issues.apache.org/jira/browse/CASSANDRA-13127 . Could you have a look 
at this patch as well ?

||Patch||testall||
|[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...krishna-koneru:cassandra-3.11-13547]|[testall|https://circleci.com/gh/kgreav/cassandra/5]|



> Filtered materialized views missing data
> 
>
> Key: CASSANDRA-13547
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13547
> Project: Cassandra
>  Issue Type: Bug
>  Components: Materialized Views
> Environment: Official Cassandra 3.10 Docker image (ID 154b919bf8ce).
>Reporter: Craig Nicholson
>Assignee: Krishna Dattu Koneru
>Priority: Blocker
>  Labels: materializedviews
> Fix For: 3.11.x
>
>
> When creating a materialized view against a base table the materialized view 
> does not always reflect the correct data.
> Using the following test schema:
> {code:title=Schema|language=sql}
> DROP KEYSPACE IF EXISTS test;
> CREATE KEYSPACE test
>   WITH REPLICATION = { 
>'class' : 'SimpleStrategy', 
>'replication_factor' : 1 
>   };
> CREATE TABLE test.table1 (
> id int,
> name text,
> enabled boolean,
> foo text,
> PRIMARY KEY (id, name));
> CREATE MATERIALIZED VIEW test.table1_mv1 AS SELECT id, name, foo
> FROM test.table1
> WHERE id IS NOT NULL 
> AND name IS NOT NULL 
> AND enabled = TRUE
> PRIMARY KEY ((name), id);
> CREATE MATERIALIZED VIEW test.table1_mv2 AS SELECT id, name, foo, enabled
> FROM test.table1
> WHERE id IS NOT NULL 
> AND name IS NOT NULL 
> AND enabled = TRUE
> PRIMARY KEY ((name), id);
> {code}
> When I insert a row into the base table the materialized views are updated 
> appropriately. (+)
> {code:title=Insert row|language=sql}
> cqlsh> INSERT INTO test.table1 (id, name, enabled, foo) VALUES (1, 'One', 
> TRUE, 'Bar');
> cqlsh> SELECT * FROM test.table1;
>  id | name | enabled | foo
> +--+-+-
>   1 |  One |True | Bar
> (1 rows)
> cqlsh> SELECT * FROM test.table1_mv1;
>  name | id | foo
> --++-
>   One |  1 | Bar
> (1 rows)
> cqlsh> SELECT * FROM test.table1_mv2;
>  name | id | enabled | foo
> --++-+-
>   One |  1 |True | Bar
> (1 rows)
> {code}
> Updating the record in the base table and setting enabled to FALSE will 
> filter the record from both materialized views. (+)
> {code:title=Disable the row|language=sql}
> cqlsh> UPDATE test.table1 SET enabled = FALSE WHERE id = 1 AND name = 'One';
> cqlsh> SELECT * FROM test.table1;
>  id | name | enabled | foo
> +--+-+-
>   1 |  One |   False | Bar
> (1 rows)
> cqlsh> SELECT * FROM test.table1_mv1;
>  name | id | foo
> --++-
> (0 rows)
> cqlsh> SELECT * FROM test.table1_mv2;
>  name | id | enabled | foo
> --++-+-
> (0 rows)
> {code}
> However a further update to the base table setting enabled to TRUE should 
> include the record in both materialzed views, however only one view 
> (table1_mv2) gets updated. (-)
> It appears that only the view (table1_mv2) that returns the filtered column 
> (enabled) is updated. (-)
> Additionally columns that are not part of the partiion or clustering key are 
> not updated. You can see that the foo column has a null value in table1_mv2. 
> (-)
> {code:title=Enable the row|language=sql}
> cqlsh> UPDATE test.table1 SET enabled = TRUE WHERE id = 1 AND name = 'One';
> cqlsh> SELECT * FROM test.table1;
>  id | name | enabled | foo
> +--+-+-
>   1 |  One |True | Bar
> (1 rows)
> cqlsh> SELECT * FROM test.table1_mv1;
>  name | id | foo
> --++-
> (0 rows)
> cqlsh> SELECT * FROM test.table1_mv2;
>  name | id | enabled | foo
> --++-+--
>   One |  1 |True | null
> (1 rows)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13565) Materialized view usage of commit logs requires large mutation but commitlog_segment_size_in_mb=2048 causes exception

[ZhaoYang (JIRA)]

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

ZhaoYang commented on CASSANDRA-13565:
--

there is only 1 partition key: LogMonth...Maybe you can consider change it 
to LogDay or LogHour depending on your use case..

> Materialized view usage of commit logs requires large mutation but 
> commitlog_segment_size_in_mb=2048 causes exception
> -
>
> Key: CASSANDRA-13565
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13565
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration, Materialized Views, Streaming and 
> Messaging
> Environment: Cassandra 3.9.0, Windows 
>Reporter: Tania S Engel
> Attachments: CQLforTable.png
>
>
> We will be upgrading to 3.10 for CASSANDRA-11670. However, there is another 
> scenario (not applyunsafe during JOIN) which leads to :
>   java.lang.IllegalArgumentException: Mutation of 525.847MiB is too large 
> for the maximum size of 512.000MiB
>       at 
> org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:262) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.db.Keyspace.apply(Keyspace.java:493) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.db.Keyspace.apply(Keyspace.java:396) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:215) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.db.Mutation.apply(Mutation.java:227) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.batchlog.BatchlogManager.store(BatchlogManager.java:147) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.service.StorageProxy.mutateMV(StorageProxy.java:797) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.db.view.ViewBuilder.buildKey(ViewBuilder.java:96) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.db.view.ViewBuilder.run(ViewBuilder.java:165) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.db.compaction.CompactionManager$14.run(CompactionManager.java:1591)
>  [apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_66]
>       at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> [na:1.8.0_66]
>       at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_66]
>       at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_66]
>       at java.lang.Thread.run(Thread.java:745) [na:1.8.0_66] 
> Due to the relationship of max_mutation_size_in_kb and 
> commitlog_segment_size_in_mb, we increased commitlog_segment_size_in_mb and 
> left Cassandra to calculate max_mutation_size_in_kb as half the size 
> commitlog_segment_size_in_mb * 1024.
>  However, we have found that if we set commitlog_segment_size_in_mb=2048 we 
> get an exception upon starting Cassandra, when it is creating a new commit 
> log.
> ERROR [COMMIT-LOG-ALLOCATOR] 2017-05-31 17:01:48,005 
> JVMStabilityInspector.java:82 - Exiting due to error while processing commit 
> log during initialization.
> org.apache.cassandra.io.FSWriteError: java.io.IOException: An attempt was 
> made to move the file pointer before the beginning of the file
> Perhaps the index you are using is not big enough and it goes negative.
> Is the relationship between max_mutation_size_in_kb and 
> commitlog_segment_size_in_mb important to preserve? In our limited stress 
> test we are finding mutation size already over 512mb and we expect more data 
> in our sstables and associated materialized views.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[10/15] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0

[mshuler]

Merge branch 'cassandra-2.2' into cassandra-3.0


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/5aec8349
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/5aec8349
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/5aec8349

Branch: refs/heads/cassandra-3.0
Commit: 5aec8349aacee0df70acf7ae55587a82d68f01c0
Parents: 000381a 0163b97
Author: Michael Shuler 
Authored: Mon Jun 26 18:51:10 2017 -0500
Committer: Michael Shuler 
Committed: Mon Jun 26 18:51:10 2017 -0500

--

--



-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[01/15] cassandra git commit: Increment to version 2.2.11

[mshuler]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.2 082af0a9b -> 0163b9744
  refs/heads/cassandra-3.0 57c590f6f -> 5aec8349a
  refs/heads/cassandra-3.11 eaa3da1d1 -> bb7e522b4
  refs/heads/trunk 977363e15 -> 26e025804


Increment to version 2.2.11


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0163b974
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0163b974
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0163b974

Branch: refs/heads/cassandra-2.2
Commit: 0163b97449e8a0cb03cdddc435b0c2997aeca992
Parents: 082af0a
Author: Michael Shuler 
Authored: Mon Jun 26 18:46:28 2017 -0500
Committer: Michael Shuler 
Committed: Mon Jun 26 18:46:28 2017 -0500

--
 NEWS.txt | 8 
 build.xml| 2 +-
 debian/changelog | 6 ++
 3 files changed, 15 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/0163b974/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index abc1bf5..37ffb8b 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -13,6 +13,14 @@ restore snapshots created with the previous major version 
using the
 'sstableloader' tool. You can upgrade the file format of your snapshots
 using the provided 'sstableupgrade' tool.
 
+2.2.11
+==
+
+Upgrading
+-
+- Nothing specific to this release, but please see 2.2 if you are upgrading
+  from a previous version.
+
 2.2.10
 ==
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/0163b974/build.xml
--
diff --git a/build.xml b/build.xml
index b302b5b..ea71e6e 100644
--- a/build.xml
+++ b/build.xml
@@ -25,7 +25,7 @@
 
 
 
-
+
 
 
 http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=tree"/>

http://git-wip-us.apache.org/repos/asf/cassandra/blob/0163b974/debian/changelog
--
diff --git a/debian/changelog b/debian/changelog
index a291da3..c626325 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+cassandra (2.2.11) unstable; urgency=medium
+
+  * New release
+
+ -- Michael Shuler   Mon, 26 Jun 2017 18:45:38 -0500
+
 cassandra (2.2.10) unstable; urgency=medium
 
   * New release


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[14/15] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11

[mshuler]

Merge branch 'cassandra-3.0' into cassandra-3.11


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/bb7e522b
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/bb7e522b
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/bb7e522b

Branch: refs/heads/cassandra-3.11
Commit: bb7e522b472821d7297b944c5270054231876bc5
Parents: 24389f4 5aec834
Author: Michael Shuler 
Authored: Mon Jun 26 18:57:11 2017 -0500
Committer: Michael Shuler 
Committed: Mon Jun 26 18:57:11 2017 -0500

--

--



-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[06/15] cassandra git commit: Increment to version 3.0.15

[mshuler]

Increment to version 3.0.15


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/000381ab
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/000381ab
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/000381ab

Branch: refs/heads/trunk
Commit: 000381ab12584a613aa2d4bec48cb1dc1816bae8
Parents: 57c590f
Author: Michael Shuler 
Authored: Mon Jun 26 18:50:40 2017 -0500
Committer: Michael Shuler 
Committed: Mon Jun 26 18:50:40 2017 -0500

--
 NEWS.txt | 11 ---
 build.xml|  2 +-
 debian/changelog |  6 ++
 3 files changed, 15 insertions(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/000381ab/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index 00ec48d..bb5fdfe 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -13,6 +13,14 @@ restore snapshots created with the previous major version 
using the
 'sstableloader' tool. You can upgrade the file format of your snapshots
 using the provided 'sstableupgrade' tool.
 
+3.0.15
+=
+
+Upgrading
+-
+   - Nothing specific to this release, but please see previous upgrading 
sections,
+ especially if you are upgrading from 2.2.
+
 3.0.14
 ==
 
@@ -45,9 +53,6 @@ Upgrading
  by a bug with the schema digest calculation in 3.0.13. This will cause 
unnecessary
  but otherwise harmless schema updates, see CASSANDRA-13559 for more 
details.
 
-   - Nothing else specific to this release, but please see previous versions 
upgrading section,
- especially if you are upgrading from 2.2.
-
 3.0.13
 ==
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/000381ab/build.xml
--
diff --git a/build.xml b/build.xml
index 80fe472..5eb6572 100644
--- a/build.xml
+++ b/build.xml
@@ -25,7 +25,7 @@
 
 
 
-
+
 
 
 http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=tree"/>

http://git-wip-us.apache.org/repos/asf/cassandra/blob/000381ab/debian/changelog
--
diff --git a/debian/changelog b/debian/changelog
index 34b27c7..f3745e6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+cassandra (3.0.15) unstable; urgency=medium
+
+  * New release
+
+ -- Michael Shuler   Mon, 26 Jun 2017 18:47:08 -0500
+
 cassandra (3.0.14) unstable; urgency=medium
 
   * New release


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[03/15] cassandra git commit: Increment to version 2.2.11

[mshuler]

Increment to version 2.2.11


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0163b974
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0163b974
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0163b974

Branch: refs/heads/cassandra-3.0
Commit: 0163b97449e8a0cb03cdddc435b0c2997aeca992
Parents: 082af0a
Author: Michael Shuler 
Authored: Mon Jun 26 18:46:28 2017 -0500
Committer: Michael Shuler 
Committed: Mon Jun 26 18:46:28 2017 -0500

--
 NEWS.txt | 8 
 build.xml| 2 +-
 debian/changelog | 6 ++
 3 files changed, 15 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/0163b974/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index abc1bf5..37ffb8b 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -13,6 +13,14 @@ restore snapshots created with the previous major version 
using the
 'sstableloader' tool. You can upgrade the file format of your snapshots
 using the provided 'sstableupgrade' tool.
 
+2.2.11
+==
+
+Upgrading
+-
+- Nothing specific to this release, but please see 2.2 if you are upgrading
+  from a previous version.
+
 2.2.10
 ==
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/0163b974/build.xml
--
diff --git a/build.xml b/build.xml
index b302b5b..ea71e6e 100644
--- a/build.xml
+++ b/build.xml
@@ -25,7 +25,7 @@
 
 
 
-
+
 
 
 http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=tree"/>

http://git-wip-us.apache.org/repos/asf/cassandra/blob/0163b974/debian/changelog
--
diff --git a/debian/changelog b/debian/changelog
index a291da3..c626325 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+cassandra (2.2.11) unstable; urgency=medium
+
+  * New release
+
+ -- Michael Shuler   Mon, 26 Jun 2017 18:45:38 -0500
+
 cassandra (2.2.10) unstable; urgency=medium
 
   * New release


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[04/15] cassandra git commit: Increment to version 2.2.11

[mshuler]

Increment to version 2.2.11


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0163b974
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0163b974
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0163b974

Branch: refs/heads/cassandra-3.11
Commit: 0163b97449e8a0cb03cdddc435b0c2997aeca992
Parents: 082af0a
Author: Michael Shuler 
Authored: Mon Jun 26 18:46:28 2017 -0500
Committer: Michael Shuler 
Committed: Mon Jun 26 18:46:28 2017 -0500

--
 NEWS.txt | 8 
 build.xml| 2 +-
 debian/changelog | 6 ++
 3 files changed, 15 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/0163b974/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index abc1bf5..37ffb8b 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -13,6 +13,14 @@ restore snapshots created with the previous major version 
using the
 'sstableloader' tool. You can upgrade the file format of your snapshots
 using the provided 'sstableupgrade' tool.
 
+2.2.11
+==
+
+Upgrading
+-
+- Nothing specific to this release, but please see 2.2 if you are upgrading
+  from a previous version.
+
 2.2.10
 ==
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/0163b974/build.xml
--
diff --git a/build.xml b/build.xml
index b302b5b..ea71e6e 100644
--- a/build.xml
+++ b/build.xml
@@ -25,7 +25,7 @@
 
 
 
-
+
 
 
 http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=tree"/>

http://git-wip-us.apache.org/repos/asf/cassandra/blob/0163b974/debian/changelog
--
diff --git a/debian/changelog b/debian/changelog
index a291da3..c626325 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+cassandra (2.2.11) unstable; urgency=medium
+
+  * New release
+
+ -- Michael Shuler   Mon, 26 Jun 2017 18:45:38 -0500
+
 cassandra (2.2.10) unstable; urgency=medium
 
   * New release


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[08/15] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0

[mshuler]

Merge branch 'cassandra-2.2' into cassandra-3.0


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/5aec8349
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/5aec8349
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/5aec8349

Branch: refs/heads/trunk
Commit: 5aec8349aacee0df70acf7ae55587a82d68f01c0
Parents: 000381a 0163b97
Author: Michael Shuler 
Authored: Mon Jun 26 18:51:10 2017 -0500
Committer: Michael Shuler 
Committed: Mon Jun 26 18:51:10 2017 -0500

--

--



-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[12/15] cassandra git commit: Increment to version 3.11.1

[mshuler]

Increment to version 3.11.1


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/24389f48
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/24389f48
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/24389f48

Branch: refs/heads/cassandra-3.11
Commit: 24389f4809dced8ed8895efe4bd72f6203412a98
Parents: eaa3da1
Author: Michael Shuler 
Authored: Mon Jun 26 18:56:43 2017 -0500
Committer: Michael Shuler 
Committed: Mon Jun 26 18:56:43 2017 -0500

--
 NEWS.txt | 7 ++-
 build.xml| 2 +-
 debian/changelog | 6 ++
 3 files changed, 13 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/24389f48/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index 6bc3388..10f631f 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -13,11 +13,16 @@ restore snapshots created with the previous major version 
using the
 'sstableloader' tool. You can upgrade the file format of your snapshots
 using the provided 'sstableupgrade' tool.
 
-3.11.0
+3.11.1
 ==
 
 Upgrading
 -
+- Nothing specific to this version but please see previous upgrading 
sections,
+  especially if you are upgrading from 2.2.
+
+3.11.0
+==
 
 Upgrading
 -

http://git-wip-us.apache.org/repos/asf/cassandra/blob/24389f48/build.xml
--
diff --git a/build.xml b/build.xml
index 497165b..c643b50 100644
--- a/build.xml
+++ b/build.xml
@@ -25,7 +25,7 @@
 
 
 
-
+
 
 
 http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=tree"/>

http://git-wip-us.apache.org/repos/asf/cassandra/blob/24389f48/debian/changelog
--
diff --git a/debian/changelog b/debian/changelog
index 57c8b04..d8be158 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+cassandra (3.11.1) unstable; urgency=medium
+
+  * New release
+
+ -- Michael Shuler   Mon, 26 Jun 2017 18:51:37 -0500
+
 cassandra (3.11.0) unstable; urgency=medium
 
   * New release


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[02/15] cassandra git commit: Increment to version 2.2.11

[mshuler]

Increment to version 2.2.11


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0163b974
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0163b974
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0163b974

Branch: refs/heads/trunk
Commit: 0163b97449e8a0cb03cdddc435b0c2997aeca992
Parents: 082af0a
Author: Michael Shuler 
Authored: Mon Jun 26 18:46:28 2017 -0500
Committer: Michael Shuler 
Committed: Mon Jun 26 18:46:28 2017 -0500

--
 NEWS.txt | 8 
 build.xml| 2 +-
 debian/changelog | 6 ++
 3 files changed, 15 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/0163b974/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index abc1bf5..37ffb8b 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -13,6 +13,14 @@ restore snapshots created with the previous major version 
using the
 'sstableloader' tool. You can upgrade the file format of your snapshots
 using the provided 'sstableupgrade' tool.
 
+2.2.11
+==
+
+Upgrading
+-
+- Nothing specific to this release, but please see 2.2 if you are upgrading
+  from a previous version.
+
 2.2.10
 ==
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/0163b974/build.xml
--
diff --git a/build.xml b/build.xml
index b302b5b..ea71e6e 100644
--- a/build.xml
+++ b/build.xml
@@ -25,7 +25,7 @@
 
 
 
-
+
 
 
 http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=tree"/>

http://git-wip-us.apache.org/repos/asf/cassandra/blob/0163b974/debian/changelog
--
diff --git a/debian/changelog b/debian/changelog
index a291da3..c626325 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+cassandra (2.2.11) unstable; urgency=medium
+
+  * New release
+
+ -- Michael Shuler   Mon, 26 Jun 2017 18:45:38 -0500
+
 cassandra (2.2.10) unstable; urgency=medium
 
   * New release


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[05/15] cassandra git commit: Increment to version 3.0.15

[mshuler]

Increment to version 3.0.15


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/000381ab
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/000381ab
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/000381ab

Branch: refs/heads/cassandra-3.0
Commit: 000381ab12584a613aa2d4bec48cb1dc1816bae8
Parents: 57c590f
Author: Michael Shuler 
Authored: Mon Jun 26 18:50:40 2017 -0500
Committer: Michael Shuler 
Committed: Mon Jun 26 18:50:40 2017 -0500

--
 NEWS.txt | 11 ---
 build.xml|  2 +-
 debian/changelog |  6 ++
 3 files changed, 15 insertions(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/000381ab/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index 00ec48d..bb5fdfe 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -13,6 +13,14 @@ restore snapshots created with the previous major version 
using the
 'sstableloader' tool. You can upgrade the file format of your snapshots
 using the provided 'sstableupgrade' tool.
 
+3.0.15
+=
+
+Upgrading
+-
+   - Nothing specific to this release, but please see previous upgrading 
sections,
+ especially if you are upgrading from 2.2.
+
 3.0.14
 ==
 
@@ -45,9 +53,6 @@ Upgrading
  by a bug with the schema digest calculation in 3.0.13. This will cause 
unnecessary
  but otherwise harmless schema updates, see CASSANDRA-13559 for more 
details.
 
-   - Nothing else specific to this release, but please see previous versions 
upgrading section,
- especially if you are upgrading from 2.2.
-
 3.0.13
 ==
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/000381ab/build.xml
--
diff --git a/build.xml b/build.xml
index 80fe472..5eb6572 100644
--- a/build.xml
+++ b/build.xml
@@ -25,7 +25,7 @@
 
 
 
-
+
 
 
 http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=tree"/>

http://git-wip-us.apache.org/repos/asf/cassandra/blob/000381ab/debian/changelog
--
diff --git a/debian/changelog b/debian/changelog
index 34b27c7..f3745e6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+cassandra (3.0.15) unstable; urgency=medium
+
+  * New release
+
+ -- Michael Shuler   Mon, 26 Jun 2017 18:47:08 -0500
+
 cassandra (3.0.14) unstable; urgency=medium
 
   * New release


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[13/15] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11

[mshuler]

Merge branch 'cassandra-3.0' into cassandra-3.11


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/bb7e522b
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/bb7e522b
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/bb7e522b

Branch: refs/heads/trunk
Commit: bb7e522b472821d7297b944c5270054231876bc5
Parents: 24389f4 5aec834
Author: Michael Shuler 
Authored: Mon Jun 26 18:57:11 2017 -0500
Committer: Michael Shuler 
Committed: Mon Jun 26 18:57:11 2017 -0500

--

--



-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[11/15] cassandra git commit: Increment to version 3.11.1

[mshuler]

Increment to version 3.11.1


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/24389f48
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/24389f48
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/24389f48

Branch: refs/heads/trunk
Commit: 24389f4809dced8ed8895efe4bd72f6203412a98
Parents: eaa3da1
Author: Michael Shuler 
Authored: Mon Jun 26 18:56:43 2017 -0500
Committer: Michael Shuler 
Committed: Mon Jun 26 18:56:43 2017 -0500

--
 NEWS.txt | 7 ++-
 build.xml| 2 +-
 debian/changelog | 6 ++
 3 files changed, 13 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/24389f48/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index 6bc3388..10f631f 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -13,11 +13,16 @@ restore snapshots created with the previous major version 
using the
 'sstableloader' tool. You can upgrade the file format of your snapshots
 using the provided 'sstableupgrade' tool.
 
-3.11.0
+3.11.1
 ==
 
 Upgrading
 -
+- Nothing specific to this version but please see previous upgrading 
sections,
+  especially if you are upgrading from 2.2.
+
+3.11.0
+==
 
 Upgrading
 -

http://git-wip-us.apache.org/repos/asf/cassandra/blob/24389f48/build.xml
--
diff --git a/build.xml b/build.xml
index 497165b..c643b50 100644
--- a/build.xml
+++ b/build.xml
@@ -25,7 +25,7 @@
 
 
 
-
+
 
 
 http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=tree"/>

http://git-wip-us.apache.org/repos/asf/cassandra/blob/24389f48/debian/changelog
--
diff --git a/debian/changelog b/debian/changelog
index 57c8b04..d8be158 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+cassandra (3.11.1) unstable; urgency=medium
+
+  * New release
+
+ -- Michael Shuler   Mon, 26 Jun 2017 18:51:37 -0500
+
 cassandra (3.11.0) unstable; urgency=medium
 
   * New release


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[09/15] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0

[mshuler]

Merge branch 'cassandra-2.2' into cassandra-3.0


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/5aec8349
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/5aec8349
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/5aec8349

Branch: refs/heads/cassandra-3.11
Commit: 5aec8349aacee0df70acf7ae55587a82d68f01c0
Parents: 000381a 0163b97
Author: Michael Shuler 
Authored: Mon Jun 26 18:51:10 2017 -0500
Committer: Michael Shuler 
Committed: Mon Jun 26 18:51:10 2017 -0500

--

--



-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[15/15] cassandra git commit: Merge branch 'cassandra-3.11' into trunk

[mshuler]

Merge branch 'cassandra-3.11' into trunk


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/26e02580
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/26e02580
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/26e02580

Branch: refs/heads/trunk
Commit: 26e025804c6777a0d124dbc257747cba85b18f37
Parents: 977363e bb7e522
Author: Michael Shuler 
Authored: Mon Jun 26 18:57:37 2017 -0500
Committer: Michael Shuler 
Committed: Mon Jun 26 18:57:37 2017 -0500

--

--



-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[07/15] cassandra git commit: Increment to version 3.0.15

[mshuler]

Increment to version 3.0.15


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/000381ab
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/000381ab
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/000381ab

Branch: refs/heads/cassandra-3.11
Commit: 000381ab12584a613aa2d4bec48cb1dc1816bae8
Parents: 57c590f
Author: Michael Shuler 
Authored: Mon Jun 26 18:50:40 2017 -0500
Committer: Michael Shuler 
Committed: Mon Jun 26 18:50:40 2017 -0500

--
 NEWS.txt | 11 ---
 build.xml|  2 +-
 debian/changelog |  6 ++
 3 files changed, 15 insertions(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/000381ab/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index 00ec48d..bb5fdfe 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -13,6 +13,14 @@ restore snapshots created with the previous major version 
using the
 'sstableloader' tool. You can upgrade the file format of your snapshots
 using the provided 'sstableupgrade' tool.
 
+3.0.15
+=
+
+Upgrading
+-
+   - Nothing specific to this release, but please see previous upgrading 
sections,
+ especially if you are upgrading from 2.2.
+
 3.0.14
 ==
 
@@ -45,9 +53,6 @@ Upgrading
  by a bug with the schema digest calculation in 3.0.13. This will cause 
unnecessary
  but otherwise harmless schema updates, see CASSANDRA-13559 for more 
details.
 
-   - Nothing else specific to this release, but please see previous versions 
upgrading section,
- especially if you are upgrading from 2.2.
-
 3.0.13
 ==
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/000381ab/build.xml
--
diff --git a/build.xml b/build.xml
index 80fe472..5eb6572 100644
--- a/build.xml
+++ b/build.xml
@@ -25,7 +25,7 @@
 
 
 
-
+
 
 
 http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=tree"/>

http://git-wip-us.apache.org/repos/asf/cassandra/blob/000381ab/debian/changelog
--
diff --git a/debian/changelog b/debian/changelog
index 34b27c7..f3745e6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+cassandra (3.0.15) unstable; urgency=medium
+
+  * New release
+
+ -- Michael Shuler   Mon, 26 Jun 2017 18:47:08 -0500
+
 cassandra (3.0.14) unstable; urgency=medium
 
   * New release


-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13440) Sign RPM artifacts

[Michael Shuler (JIRA)]

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

Michael Shuler updated CASSANDRA-13440:
---
Fix Version/s: 2.1.18
   2.2.10

> Sign RPM artifacts
> --
>
> Key: CASSANDRA-13440
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13440
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Packaging
>Reporter: Stefan Podkowinski
>Assignee: Michael Shuler
> Fix For: 2.1.18, 2.2.10, 3.0.14, 3.11.0
>
>
> RPMs should be gpg signed just as the deb packages. Also add documentation 
> how to verify to download page.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

svn commit: r1800001 - in /cassandra/site: publish/download/index.html src/download.md

[mshuler]

Author: mshuler
Date: Mon Jun 26 22:33:46 2017
New Revision: 181

URL: http://svn.apache.org/viewvc?rev=181=rev
Log:
Fix typo

Modified:
cassandra/site/publish/download/index.html
cassandra/site/src/download.md

Modified: cassandra/site/publish/download/index.html
URL: 
http://svn.apache.org/viewvc/cassandra/site/publish/download/index.html?rev=181=180=181=diff
==
--- cassandra/site/publish/download/index.html (original)
+++ cassandra/site/publish/download/index.html Mon Jun 26 22:33:46 2017
@@ -120,7 +120,7 @@
   For the release series specify the major version 
number, without dot, and with an appended x.
   The latest release series is 311x.
   
-For older releases, the release series can one of 
30x, 22x, or 21x.
+For older releases, the release series can be one 
of 30x, 22x, or 21x.
   
   Add the Apache repository of Cassandra to 
/etc/apt/sources.list.d/cassandra.sources.list, for example for 
the latest 3.11 version:
 
@@ -177,7 +177,7 @@ configuration changes.
 
   For the release series specify the major version 
number, without dot, and with an appended x.
   The latest release series is 311x.
-  For older releases, the release series can one of 
30x, 22x, or 21x.
+  For older releases, the release series can be one 
of 30x, 22x, or 21x.
   
 (Not all versions of Apache Cassandra are available, since building 
RPMs is a recent addition to the project.)
   

Modified: cassandra/site/src/download.md
URL: 
http://svn.apache.org/viewvc/cassandra/site/src/download.md?rev=181=180=181=diff
==
--- cassandra/site/src/download.md (original)
+++ cassandra/site/src/download.md Mon Jun 26 22:33:46 2017
@@ -28,7 +28,7 @@ Older (unsupported) versions of Cassandr
 
 * For the `` specify the major version number, without dot, 
and with an appended `x`.
 * The latest `` is `311x`.
-* For older releases, the `` can one of `30x`, `22x`, or `21x`.
+* For older releases, the `` can be one of `30x`, `22x`, or 
`21x`.
 
 * Add the Apache repository of Cassandra to 
`/etc/apt/sources.list.d/cassandra.sources.list`, for example for the latest 
3.11 version:
 
@@ -79,7 +79,7 @@ sudo apt-get install cassandra
 
 * For the `` specify the major version number, without dot, 
and with an appended `x`.
 * The latest `` is `311x`.
-* For older releases, the `` can one of `30x`, `22x`, or `21x`.
+* For older releases, the `` can be one of `30x`, `22x`, or 
`21x`.
 * (Not all versions of Apache Cassandra are available, since building RPMs is 
a recent addition to the project.)
 
 * Add the Apache repository of Cassandra to `/etc/yum.repos.d/cassandra.repo`, 
for example for the latest 3.11 version:



-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

svn commit: r1800000 - in /cassandra/site: publish/download/index.html src/download.md

[mshuler]

Author: mshuler
Date: Mon Jun 26 22:29:30 2017
New Revision: 180

URL: http://svn.apache.org/viewvc?rev=180=rev
Log:
Add `yum install` step

Modified:
cassandra/site/publish/download/index.html
cassandra/site/src/download.md

Modified: cassandra/site/publish/download/index.html
URL: 
http://svn.apache.org/viewvc/cassandra/site/publish/download/index.html?rev=180=179=180=diff
==
--- cassandra/site/publish/download/index.html (original)
+++ cassandra/site/publish/download/index.html Mon Jun 26 22:29:30 2017
@@ -195,6 +195,13 @@ configuration changes.
 
 
 
+
+  Install Cassandra, accepting the gpg key import prompts:
+
+
+sudo yum install cassandra
+
+
 Start Cassandra (will not start automatically):
 
 service cassandra start

Modified: cassandra/site/src/download.md
URL: 
http://svn.apache.org/viewvc/cassandra/site/src/download.md?rev=180=179=180=diff
==
--- cassandra/site/src/download.md (original)
+++ cassandra/site/src/download.md Mon Jun 26 22:29:30 2017
@@ -93,6 +93,12 @@ repo_gpgcheck=1
 gpgkey=https://www.apache.org/dist/cassandra/KEYS
 ```
 
+* Install Cassandra, accepting the gpg key import prompts:
+
+```
+sudo yum install cassandra
+```
+
 Start Cassandra (will not start automatically):
 
 ```



-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

svn commit: r1799999 - in /cassandra/site: publish/download/index.html src/_data/releases.yaml src/download.md

[mshuler]

Author: mshuler
Date: Mon Jun 26 22:25:30 2017
New Revision: 179

URL: http://svn.apache.org/viewvc?rev=179=rev
Log:
Update download page for 2.1.18 and 2.2.10 releases

Modified:
cassandra/site/publish/download/index.html
cassandra/site/src/_data/releases.yaml
cassandra/site/src/download.md

Modified: cassandra/site/publish/download/index.html
URL: 
http://svn.apache.org/viewvc/cassandra/site/publish/download/index.html?rev=179=178=179=diff
==
--- cassandra/site/publish/download/index.html (original)
+++ cassandra/site/publish/download/index.html Mon Jun 26 22:25:30 2017
@@ -107,9 +107,9 @@
 
 
   Apache Cassandra 3.0 is supported until 6 months after 4.0 
release (date TBD). The latest release is http://www.apache.org/dyn/closer.lua/cassandra/3.0.14/apache-cassandra-3.0.14-bin.tar.gz;>3.0.14
 (http://www.apache.org/dist/cassandra/3.0.14/apache-cassandra-3.0.14-bin.tar.gz.asc;>pgp,
 http://www.apache.org/dist/cassandra/3.0.14/apache-cassandra-3.0.14-bin.tar.gz.md5;>md5
 and http://www.apache.org/dist/cassandra/3.0.14/apache-cassandra-3.0.14-bin.tar.gz.sha1;>sha1),
 released on 2017-06-23.
-  Apache Cassandra 2.2 is supported until 4.0 release (date 
TBD). The latest release is http://www.apache.org/dyn/closer.lua/cassandra/2.2.9/apache-cassandra-2.2.9-bin.tar.gz;>2.2.9
 (http://www.apache.org/dist/cassandra/2.2.9/apache-cassandra-2.2.9-bin.tar.gz.asc;>pgp,
 http://www.apache.org/dist/cassandra/2.2.9/apache-cassandra-2.2.9-bin.tar.gz.md5;>md5
 and http://www.apache.org/dist/cassandra/2.2.9/apache-cassandra-2.2.9-bin.tar.gz.sha1;>sha1),
 released on 2017-02-21.
+  Apache Cassandra 2.2 is supported until 4.0 release (date 
TBD). The latest release is http://www.apache.org/dyn/closer.lua/cassandra/2.2.10/apache-cassandra-2.2.10-bin.tar.gz;>2.2.10
 (http://www.apache.org/dist/cassandra/2.2.10/apache-cassandra-2.2.10-bin.tar.gz.asc;>pgp,
 http://www.apache.org/dist/cassandra/2.2.10/apache-cassandra-2.2.10-bin.tar.gz.md5;>md5
 and http://www.apache.org/dist/cassandra/2.2.10/apache-cassandra-2.2.10-bin.tar.gz.sha1;>sha1),
 released on 2017-06-26.
   Apache Cassandra 2.1 is supported until 4.0 release (date 
TBD) with critical fixes only. The latest release is
-http://www.apache.org/dyn/closer.lua/cassandra/2.1.17/apache-cassandra-2.1.17-bin.tar.gz;>2.1.17
 (http://www.apache.org/dist/cassandra/2.1.17/apache-cassandra-2.1.17-bin.tar.gz.asc;>pgp,
 http://www.apache.org/dist/cassandra/2.1.17/apache-cassandra-2.1.17-bin.tar.gz.md5;>md5
 and http://www.apache.org/dist/cassandra/2.1.17/apache-cassandra-2.1.17-bin.tar.gz.sha1;>sha1),
 released on 2017-02-21.
+http://www.apache.org/dyn/closer.lua/cassandra/2.1.18/apache-cassandra-2.1.18-bin.tar.gz;>2.1.18
 (http://www.apache.org/dist/cassandra/2.1.18/apache-cassandra-2.1.18-bin.tar.gz.asc;>pgp,
 http://www.apache.org/dist/cassandra/2.1.18/apache-cassandra-2.1.18-bin.tar.gz.md5;>md5
 and http://www.apache.org/dist/cassandra/2.1.18/apache-cassandra-2.1.18-bin.tar.gz.sha1;>sha1),
 released on 2017-06-26.
 
 
 Older (unsupported) versions of Cassandra are http://archive.apache.org/dist/cassandra/;>archived here.
@@ -146,7 +146,7 @@
   If you encounter this error:
 
 
-GPG error: http://www.apache.org 310x InRelease: The following 
signatures couldn't be verified because the public key is not available: 
NO_PUBKEY A278B781FE4B2BDA
+GPG error: http://www.apache.org 311x InRelease: The following 
signatures couldn't be verified because the public key is not available: 
NO_PUBKEY A278B781FE4B2BDA
 
 Then add the public key A278B781FE4B2BDA as follows:
 
@@ -174,11 +174,10 @@ configuration changes.
 
 Installation from RPM packages
 
-Cassandra can be installed using RPM packages for the following 
release series, similar to Debian packages above:
-
 
-  311x and 30x
-  Modify the release series desired in the 
baseurl below.
+  For the release series specify the major version 
number, without dot, and with an appended x.
+  The latest release series is 311x.
+  For older releases, the release series can one of 
30x, 22x, or 21x.
   
 (Not all versions of Apache Cassandra are available, since building 
RPMs is a recent addition to the project.)
   
@@ -186,12 +185,12 @@ configuration changes.
 
 
 
-  1[cassandra]
-2name=Apache 
Cassandra
-3baseurl=https://www.apache.org/dist/cassandra/redhat/311x/
-4gpgcheck=1
-5repo_gpgcheck=1
-6gpgkey=https://www.apache.org/dist/cassandra/KEYS
+  [cassandra]
+name=Apache 
Cassandra
+baseurl=https://www.apache.org/dist/cassandra/redhat/311x/
+gpgcheck=1
+repo_gpgcheck=1
+gpgkey=https://www.apache.org/dist/cassandra/KEYS
 
 
 

Modified: cassandra/site/src/_data/releases.yaml
URL: 
http://svn.apache.org/viewvc/cassandra/site/src/_data/releases.yaml?rev=179=178=179=diff
==
--- cassandra/site/src/_data/releases.yaml (original)
+++ 

svn commit: r20204 - in /release/cassandra: 2.1.18/ 2.2.10/ debian/dists/21x/ debian/dists/21x/main/binary-amd64/ debian/dists/21x/main/binary-i386/ debian/dists/21x/main/source/ debian/dists/22x/ deb

[mshuler]

Author: mshuler
Date: Mon Jun 26 22:04:57 2017
New Revision: 20204

Log:
Apache Cassandra 2.1.18 and 2.2.10 Releases

Added:
release/cassandra/2.1.18/
release/cassandra/2.1.18/apache-cassandra-2.1.18-bin.tar.gz   (with props)
release/cassandra/2.1.18/apache-cassandra-2.1.18-bin.tar.gz.asc
release/cassandra/2.1.18/apache-cassandra-2.1.18-bin.tar.gz.asc.md5
release/cassandra/2.1.18/apache-cassandra-2.1.18-bin.tar.gz.asc.sha1
release/cassandra/2.1.18/apache-cassandra-2.1.18-bin.tar.gz.md5
release/cassandra/2.1.18/apache-cassandra-2.1.18-bin.tar.gz.sha1
release/cassandra/2.1.18/apache-cassandra-2.1.18-src.tar.gz   (with props)
release/cassandra/2.1.18/apache-cassandra-2.1.18-src.tar.gz.asc
release/cassandra/2.1.18/apache-cassandra-2.1.18-src.tar.gz.asc.md5
release/cassandra/2.1.18/apache-cassandra-2.1.18-src.tar.gz.asc.sha1
release/cassandra/2.1.18/apache-cassandra-2.1.18-src.tar.gz.md5
release/cassandra/2.1.18/apache-cassandra-2.1.18-src.tar.gz.sha1
release/cassandra/2.2.10/
release/cassandra/2.2.10/apache-cassandra-2.2.10-bin.tar.gz   (with props)
release/cassandra/2.2.10/apache-cassandra-2.2.10-bin.tar.gz.asc
release/cassandra/2.2.10/apache-cassandra-2.2.10-bin.tar.gz.asc.md5
release/cassandra/2.2.10/apache-cassandra-2.2.10-bin.tar.gz.asc.sha1
release/cassandra/2.2.10/apache-cassandra-2.2.10-bin.tar.gz.md5
release/cassandra/2.2.10/apache-cassandra-2.2.10-bin.tar.gz.sha1
release/cassandra/2.2.10/apache-cassandra-2.2.10-src.tar.gz   (with props)
release/cassandra/2.2.10/apache-cassandra-2.2.10-src.tar.gz.asc
release/cassandra/2.2.10/apache-cassandra-2.2.10-src.tar.gz.asc.md5
release/cassandra/2.2.10/apache-cassandra-2.2.10-src.tar.gz.asc.sha1
release/cassandra/2.2.10/apache-cassandra-2.2.10-src.tar.gz.md5
release/cassandra/2.2.10/apache-cassandra-2.2.10-src.tar.gz.sha1

release/cassandra/debian/pool/main/c/cassandra/cassandra-tools_2.1.18_all.deb   
(with props)

release/cassandra/debian/pool/main/c/cassandra/cassandra-tools_2.2.10_all.deb   
(with props)
release/cassandra/debian/pool/main/c/cassandra/cassandra_2.1.18.diff.gz   
(with props)
release/cassandra/debian/pool/main/c/cassandra/cassandra_2.1.18.dsc
release/cassandra/debian/pool/main/c/cassandra/cassandra_2.1.18.orig.tar.gz 
  (with props)

release/cassandra/debian/pool/main/c/cassandra/cassandra_2.1.18.orig.tar.gz.asc
release/cassandra/debian/pool/main/c/cassandra/cassandra_2.1.18_all.deb   
(with props)
release/cassandra/debian/pool/main/c/cassandra/cassandra_2.2.10.diff.gz   
(with props)
release/cassandra/debian/pool/main/c/cassandra/cassandra_2.2.10.dsc
release/cassandra/debian/pool/main/c/cassandra/cassandra_2.2.10.orig.tar.gz 
  (with props)

release/cassandra/debian/pool/main/c/cassandra/cassandra_2.2.10.orig.tar.gz.asc
release/cassandra/debian/pool/main/c/cassandra/cassandra_2.2.10_all.deb   
(with props)
release/cassandra/redhat/21x/
release/cassandra/redhat/21x/cassandra-2.1.18-1.noarch.rpm   (with props)
release/cassandra/redhat/21x/cassandra-2.1.18-1.src.rpm   (with props)
release/cassandra/redhat/21x/cassandra-tools-2.1.18-1.noarch.rpm   (with 
props)
release/cassandra/redhat/21x/repodata/

release/cassandra/redhat/21x/repodata/1c622d4a313b58e335ca5809110cc52c03642510d69dc4d8ddb2904f1ec0830b-primary.xml.gz
   (with props)

release/cassandra/redhat/21x/repodata/2c860c89cf36a68d3ab2243c09b22d84915706e8c8c25b17bf9e5ea8609ca344-filelists.xml.gz
   (with props)

release/cassandra/redhat/21x/repodata/316c94ce0d186169dfb898a8305cebb245fd97f88dbc0f6f48ab3065ce4b2826-other.sqlite.bz2
   (with props)

release/cassandra/redhat/21x/repodata/46c7b3a5423daaeab38e1d163b5f84defcf080c907f7c3ac7a991899bea5b160-primary.sqlite.bz2
   (with props)

release/cassandra/redhat/21x/repodata/57248c50a21d164546cd8cc66f51edd9a197419858e005ec0c0548807c98b63d-other.xml.gz
   (with props)

release/cassandra/redhat/21x/repodata/e510ab7ba3b128a4d0114bd814ddb94bd6d4a21ba6f57eb6e357ffa0bb3d80c6-filelists.sqlite.bz2
   (with props)
release/cassandra/redhat/21x/repodata/repomd.xml
release/cassandra/redhat/21x/repodata/repomd.xml.asc
release/cassandra/redhat/22x/
release/cassandra/redhat/22x/cassandra-2.2.10-1.noarch.rpm   (with props)
release/cassandra/redhat/22x/cassandra-2.2.10-1.src.rpm   (with props)
release/cassandra/redhat/22x/cassandra-tools-2.2.10-1.noarch.rpm   (with 
props)
release/cassandra/redhat/22x/repodata/

release/cassandra/redhat/22x/repodata/3236f5a391cbf37fd0e70cba6ec4633b6d466f68064061a4b40443c002199304-filelists.xml.gz
   (with props)

release/cassandra/redhat/22x/repodata/401603460b42f33ace08526f74b13526d3ebfa0aa1ac53b15fe0f6f1f4feae55-primary.sqlite.bz2
   (with props)

release/cassandra/redhat/22x/repodata/4b99211eb9721f495aa9e2aa16ed21e7d68ca0c17cc2135485d40a2dc2fb5dca-other.sqlite.bz2
   (with props)

[cassandra] Git Push Summary

[mshuler]

Repository: cassandra
Updated Tags:  refs/tags/2.2.10-tentative [deleted] 83f28ce3c

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[cassandra] Git Push Summary

[mshuler]

Repository: cassandra
Updated Tags:  refs/tags/cassandra-2.2.10 [created] 1d1e1af90

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[cassandra] Git Push Summary

[mshuler]

Repository: cassandra
Updated Tags:  refs/tags/2.1.18-tentative [deleted] 9369db1df

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[cassandra] Git Push Summary

[mshuler]

Repository: cassandra
Updated Tags:  refs/tags/cassandra-2.1.18 [created] 37b2aa4cc

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Resolved] (CASSANDRA-13139) test failure in hintedhandoff_test.TestHintedHandoff.hintedhandoff_decom_test

[Joel Knighton (JIRA)]

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

Joel Knighton resolved CASSANDRA-13139.
---
Resolution: Fixed

The linked PR resolved this issue.

> test failure in hintedhandoff_test.TestHintedHandoff.hintedhandoff_decom_test
> -
>
> Key: CASSANDRA-13139
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13139
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Sean McCarthy
>  Labels: dtest, test-failure
> Attachments: node1_debug.log, node1_gc.log, node1.log, 
> node2_debug.log, node2_gc.log, node2.log, node3_debug.log, node3_gc.log, 
> node3.log, node4_debug.log, node4_gc.log, node4.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_novnode_dtest/503/testReport/hintedhandoff_test/TestHintedHandoff/hintedhandoff_decom_test
> {code}
> Error Message
> Subprocess ['nodetool', '-h', 'localhost', '-p', '7200', ['decommission']] 
> exited with non-zero status; exit status: 1; 
> stdout: nodetool: Unsupported operation: Not enough live nodes to maintain 
> replication factor in keyspace system_distributed (RF = 3, N = 3). Perform a 
> forceful decommission to ignore.
> See 'nodetool help' or 'nodetool help '.
> {code}{code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/hintedhandoff_test.py", line 169, in 
> hintedhandoff_decom_test
> node2.decommission()
>   File "/usr/local/lib/python2.7/dist-packages/ccmlib/node.py", line 1314, in 
> decommission
> self.nodetool("decommission")
>   File "/usr/local/lib/python2.7/dist-packages/ccmlib/node.py", line 783, in 
> nodetool
> return handle_external_tool_process(p, ['nodetool', '-h', 'localhost', 
> '-p', str(self.jmx_port), cmd.split()])
>   File "/usr/local/lib/python2.7/dist-packages/ccmlib/node.py", line 1993, in 
> handle_external_tool_process
> raise ToolError(cmd_args, rc, out, err)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13565) Materialized view usage of commit logs requires large mutation but commitlog_segment_size_in_mb=2048 causes exception

[Tania S Engel (JIRA)]

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

Tania S Engel commented on CASSANDRA-13565:
---

All of our partition keys have small values (not varchar). Some are composite, 
with 1 or 2 partition keys and four or 5 clustering keys. Would the composite 
of partition and clustering keys (albeit not big individual values) contribute 
to a "wide" partition? Here is an example of the CQL:
!CQLforTable.png!

> Materialized view usage of commit logs requires large mutation but 
> commitlog_segment_size_in_mb=2048 causes exception
> -
>
> Key: CASSANDRA-13565
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13565
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration, Materialized Views, Streaming and 
> Messaging
> Environment: Cassandra 3.9.0, Windows 
>Reporter: Tania S Engel
> Attachments: CQLforTable.png
>
>
> We will be upgrading to 3.10 for CASSANDRA-11670. However, there is another 
> scenario (not applyunsafe during JOIN) which leads to :
>   java.lang.IllegalArgumentException: Mutation of 525.847MiB is too large 
> for the maximum size of 512.000MiB
>       at 
> org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:262) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.db.Keyspace.apply(Keyspace.java:493) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.db.Keyspace.apply(Keyspace.java:396) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:215) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.db.Mutation.apply(Mutation.java:227) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.batchlog.BatchlogManager.store(BatchlogManager.java:147) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.service.StorageProxy.mutateMV(StorageProxy.java:797) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.db.view.ViewBuilder.buildKey(ViewBuilder.java:96) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.db.view.ViewBuilder.run(ViewBuilder.java:165) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.db.compaction.CompactionManager$14.run(CompactionManager.java:1591)
>  [apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_66]
>       at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> [na:1.8.0_66]
>       at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_66]
>       at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_66]
>       at java.lang.Thread.run(Thread.java:745) [na:1.8.0_66] 
> Due to the relationship of max_mutation_size_in_kb and 
> commitlog_segment_size_in_mb, we increased commitlog_segment_size_in_mb and 
> left Cassandra to calculate max_mutation_size_in_kb as half the size 
> commitlog_segment_size_in_mb * 1024.
>  However, we have found that if we set commitlog_segment_size_in_mb=2048 we 
> get an exception upon starting Cassandra, when it is creating a new commit 
> log.
> ERROR [COMMIT-LOG-ALLOCATOR] 2017-05-31 17:01:48,005 
> JVMStabilityInspector.java:82 - Exiting due to error while processing commit 
> log during initialization.
> org.apache.cassandra.io.FSWriteError: java.io.IOException: An attempt was 
> made to move the file pointer before the beginning of the file
> Perhaps the index you are using is not big enough and it goes negative.
> Is the relationship between max_mutation_size_in_kb and 
> commitlog_segment_size_in_mb important to preserve? In our limited stress 
> test we are finding mutation size already over 512mb and we expect more data 
> in our sstables and associated materialized views.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13565) Materialized view usage of commit logs requires large mutation but commitlog_segment_size_in_mb=2048 causes exception

[Tania S Engel (JIRA)]

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

Tania S Engel updated CASSANDRA-13565:
--
Attachment: CQLforTable.png

> Materialized view usage of commit logs requires large mutation but 
> commitlog_segment_size_in_mb=2048 causes exception
> -
>
> Key: CASSANDRA-13565
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13565
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration, Materialized Views, Streaming and 
> Messaging
> Environment: Cassandra 3.9.0, Windows 
>Reporter: Tania S Engel
> Attachments: CQLforTable.png
>
>
> We will be upgrading to 3.10 for CASSANDRA-11670. However, there is another 
> scenario (not applyunsafe during JOIN) which leads to :
>   java.lang.IllegalArgumentException: Mutation of 525.847MiB is too large 
> for the maximum size of 512.000MiB
>       at 
> org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:262) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.db.Keyspace.apply(Keyspace.java:493) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.db.Keyspace.apply(Keyspace.java:396) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:215) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.db.Mutation.apply(Mutation.java:227) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.batchlog.BatchlogManager.store(BatchlogManager.java:147) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.service.StorageProxy.mutateMV(StorageProxy.java:797) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.db.view.ViewBuilder.buildKey(ViewBuilder.java:96) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.db.view.ViewBuilder.run(ViewBuilder.java:165) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.db.compaction.CompactionManager$14.run(CompactionManager.java:1591)
>  [apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_66]
>       at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> [na:1.8.0_66]
>       at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_66]
>       at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_66]
>       at java.lang.Thread.run(Thread.java:745) [na:1.8.0_66] 
> Due to the relationship of max_mutation_size_in_kb and 
> commitlog_segment_size_in_mb, we increased commitlog_segment_size_in_mb and 
> left Cassandra to calculate max_mutation_size_in_kb as half the size 
> commitlog_segment_size_in_mb * 1024.
>  However, we have found that if we set commitlog_segment_size_in_mb=2048 we 
> get an exception upon starting Cassandra, when it is creating a new commit 
> log.
> ERROR [COMMIT-LOG-ALLOCATOR] 2017-05-31 17:01:48,005 
> JVMStabilityInspector.java:82 - Exiting due to error while processing commit 
> log during initialization.
> org.apache.cassandra.io.FSWriteError: java.io.IOException: An attempt was 
> made to move the file pointer before the beginning of the file
> Perhaps the index you are using is not big enough and it goes negative.
> Is the relationship between max_mutation_size_in_kb and 
> commitlog_segment_size_in_mb important to preserve? In our limited stress 
> test we are finding mutation size already over 512mb and we expect more data 
> in our sstables and associated materialized views.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13638) Add the JMX metrics about the total number of hints we have delivered per host

[Chris Lohfink (JIRA)]

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

Chris Lohfink commented on CASSANDRA-13638:
---

You can get the succeeded from Hints_delays-'s count and the created 
from {{org.apache.cassandra.metrics:type=HintedHandoffManager}}'s 
Hints_created-'s value

> Add the JMX metrics about the total number of hints we have delivered per host
> --
>
> Key: CASSANDRA-13638
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13638
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Petrit G
>Priority: Minor
>
> Recently metrics were added regarding how many hints have been successfully 
> delivered in total.
> See [here | 
> http://cassandra.apache.org/doc/latest/operating/metrics.html?highlight=metrics#hintsservice-metrics],
>  for more specific info. 
> However I think it would be beneficial to add a metric which shows how many 
> hints have been delivered per host.
> More or less a corresponding metric for: 
> Hints_created-
> Could be named:
> Hints_succeeded-
> This will allow users to actually see how many hints they have towards a 
> node, by calculating the difference between the two aforementioned metrics.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13043) Unable to achieve CL while applying counters from commitlog

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-13043:
---

I'll try to help out if you poke me again after July 10th; currently on 
vacation, sorry.

> Unable to achieve CL while applying counters from commitlog
> ---
>
> Key: CASSANDRA-13043
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13043
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: Debian
>Reporter: Catalin Alexandru Zamfir
>
> In version 3.9 of Cassandra, we get the following exceptions on the 
> system.log whenever booting an agent. They seem to grow in number with each 
> reboot. Any idea where they come from or what can we do about them? Note that 
> the cluster is healthy (has sufficient live nodes).
> {noformat}
> 2/14/2016 12:39:47 PMINFO  10:39:47 Updating topology for /10.136.64.120
> 12/14/2016 12:39:47 PMINFO  10:39:47 Updating topology for /10.136.64.120
> 12/14/2016 12:39:47 PMWARN  10:39:47 Uncaught exception on thread 
> Thread[CounterMutationStage-111,5,main]: {}
> 12/14/2016 12:39:47 PMorg.apache.cassandra.exceptions.UnavailableException: 
> Cannot achieve consistency level LOCAL_QUORUM
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.db.ConsistencyLevel.assureSufficientLiveNodes(ConsistencyLevel.java:313)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.service.AbstractWriteResponseHandler.assureSufficientLiveNodes(AbstractWriteResponseHandler.java:146)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.service.StorageProxy.performWrite(StorageProxy.java:1054)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.service.StorageProxy.applyCounterMutationOnLeader(StorageProxy.java:1450)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.db.CounterMutationVerbHandler.doVerb(CounterMutationVerbHandler.java:48)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:64) 
> ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_111]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
>  [apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
> [apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat java.lang.Thread.run(Thread.java:745) 
> [na:1.8.0_111]
> 12/14/2016 12:39:47 PMWARN  10:39:47 Uncaught exception on thread 
> Thread[CounterMutationStage-118,5,main]: {}
> 12/14/2016 12:39:47 PMorg.apache.cassandra.exceptions.UnavailableException: 
> Cannot achieve consistency level LOCAL_QUORUM
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.db.ConsistencyLevel.assureSufficientLiveNodes(ConsistencyLevel.java:313)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.service.AbstractWriteResponseHandler.assureSufficientLiveNodes(AbstractWriteResponseHandler.java:146)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.service.StorageProxy.performWrite(StorageProxy.java:1054)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.service.StorageProxy.applyCounterMutationOnLeader(StorageProxy.java:1450)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.db.CounterMutationVerbHandler.doVerb(CounterMutationVerbHandler.java:48)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:64) 
> ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_111]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
>  [apache-cassandra-3.9.jar:3.9]
> 

[jira] [Commented] (CASSANDRA-13565) Materialized view usage of commit logs requires large mutation but commitlog_segment_size_in_mb=2048 causes exception

[ZhaoYang (JIRA)]

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

ZhaoYang commented on CASSANDRA-13565:
--

Could you share your data modeling? it seems your partition is too wide. In my 
understanding, c* rebuilds MV from each base table's partition key.

> Materialized view usage of commit logs requires large mutation but 
> commitlog_segment_size_in_mb=2048 causes exception
> -
>
> Key: CASSANDRA-13565
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13565
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration, Materialized Views, Streaming and 
> Messaging
> Environment: Cassandra 3.9.0, Windows 
>Reporter: Tania S Engel
>
> We will be upgrading to 3.10 for CASSANDRA-11670. However, there is another 
> scenario (not applyunsafe during JOIN) which leads to :
>   java.lang.IllegalArgumentException: Mutation of 525.847MiB is too large 
> for the maximum size of 512.000MiB
>       at 
> org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:262) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.db.Keyspace.apply(Keyspace.java:493) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.db.Keyspace.apply(Keyspace.java:396) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:215) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.db.Mutation.apply(Mutation.java:227) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.batchlog.BatchlogManager.store(BatchlogManager.java:147) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.service.StorageProxy.mutateMV(StorageProxy.java:797) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.db.view.ViewBuilder.buildKey(ViewBuilder.java:96) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.db.view.ViewBuilder.run(ViewBuilder.java:165) 
> ~[apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> org.apache.cassandra.db.compaction.CompactionManager$14.run(CompactionManager.java:1591)
>  [apache-cassandra-3.9.0.jar:3.9.0]
>       at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_66]
>       at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> [na:1.8.0_66]
>       at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_66]
>       at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_66]
>       at java.lang.Thread.run(Thread.java:745) [na:1.8.0_66] 
> Due to the relationship of max_mutation_size_in_kb and 
> commitlog_segment_size_in_mb, we increased commitlog_segment_size_in_mb and 
> left Cassandra to calculate max_mutation_size_in_kb as half the size 
> commitlog_segment_size_in_mb * 1024.
>  However, we have found that if we set commitlog_segment_size_in_mb=2048 we 
> get an exception upon starting Cassandra, when it is creating a new commit 
> log.
> ERROR [COMMIT-LOG-ALLOCATOR] 2017-05-31 17:01:48,005 
> JVMStabilityInspector.java:82 - Exiting due to error while processing commit 
> log during initialization.
> org.apache.cassandra.io.FSWriteError: java.io.IOException: An attempt was 
> made to move the file pointer before the beginning of the file
> Perhaps the index you are using is not big enough and it goes negative.
> Is the relationship between max_mutation_size_in_kb and 
> commitlog_segment_size_in_mb important to preserve? In our limited stress 
> test we are finding mutation size already over 512mb and we expect more data 
> in our sstables and associated materialized views.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13614) Batchlog replay throttle should be dynamically configurable with jmx and possibly nodetool

[JIRA]

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

Andrés de la Peña updated CASSANDRA-13614:
--
Status: Patch Available  (was: Open)

> Batchlog replay throttle should be dynamically configurable with jmx and 
> possibly nodetool
> --
>
> Key: CASSANDRA-13614
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13614
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Configuration, Materialized Views
>Reporter: Andrés de la Peña
>Assignee: Andrés de la Peña
>
> As it is said in 
> [CASSANDRA-13162|https://issues.apache.org/jira/browse/CASSANDRA-13162], 
> batchlog replay can be excessively throttled with materialized views. The 
> throttle is controlled by the property {{batchlog_replay_throttle_in_kb}}, 
> which is set by default to (only) 1024KB, and it can't be configured 
> dynamically. It would be useful to be able of modifying it dynamically with 
> JMX and possibly nodetool.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Resolved] (CASSANDRA-11808) Ant test failed on 2.1.14

[ZhaoYang (JIRA)]

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

ZhaoYang resolved CASSANDRA-11808.
--
Resolution: Not A Problem

> Ant test failed on 2.1.14
> -
>
> Key: CASSANDRA-11808
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11808
> Project: Cassandra
>  Issue Type: Test
> Environment: cassandra-2.1.14, ubuntu-14.04
>Reporter: ZhaoYang
> Attachments: ant_test_2.1.14.log
>
>
> "Ant test" failed



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13532) sstabledump reports incorrect usage for argument order

[ZhaoYang (JIRA)]

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

ZhaoYang updated CASSANDRA-13532:
-
Component/s: Tools

> sstabledump reports incorrect usage for argument order
> --
>
> Key: CASSANDRA-13532
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13532
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Ian Ilsley
>Assignee: Varun Barala
>Priority: Minor
>  Labels: lhf
> Attachments: sstabledump#printUsage.patch
>
>
> sstabledump usage reports 
> {{usage: sstabledump  }}
> However the actual usage is 
> {{sstabledump   }}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13532) sstabledump reports incorrect usage for argument order

[ZhaoYang (JIRA)]

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

ZhaoYang commented on CASSANDRA-13532:
--

LGTM

> sstabledump reports incorrect usage for argument order
> --
>
> Key: CASSANDRA-13532
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13532
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Ian Ilsley
>Assignee: Varun Barala
>Priority: Minor
>  Labels: lhf
> Attachments: sstabledump#printUsage.patch
>
>
> sstabledump usage reports 
> {{usage: sstabledump  }}
> However the actual usage is 
> {{sstabledump   }}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13532) sstabledump reports incorrect usage for argument order

[ZhaoYang (JIRA)]

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

ZhaoYang updated CASSANDRA-13532:
-
Status: Ready to Commit  (was: Patch Available)

> sstabledump reports incorrect usage for argument order
> --
>
> Key: CASSANDRA-13532
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13532
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Ian Ilsley
>Assignee: Varun Barala
>Priority: Minor
>  Labels: lhf
> Attachments: sstabledump#printUsage.patch
>
>
> sstabledump usage reports 
> {{usage: sstabledump  }}
> However the actual usage is 
> {{sstabledump   }}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Assigned] (CASSANDRA-13532) sstabledump reports incorrect usage for argument order

[ZhaoYang (JIRA)]

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

ZhaoYang reassigned CASSANDRA-13532:


Assignee: Varun Barala

> sstabledump reports incorrect usage for argument order
> --
>
> Key: CASSANDRA-13532
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13532
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Ian Ilsley
>Assignee: Varun Barala
>Priority: Minor
>  Labels: lhf
> Attachments: sstabledump#printUsage.patch
>
>
> sstabledump usage reports 
> {{usage: sstabledump  }}
> However the actual usage is 
> {{sstabledump   }}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Comment Edited] (CASSANDRA-13127) Materialized Views: View row expires too soon

[ZhaoYang (JIRA)]

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

ZhaoYang edited comment on CASSANDRA-13127 at 6/26/17 2:07 PM:
---

one more issue in Row.Merger:
{quote}
 if (row.primaryKeyLivenessInfo().supersedes(rowInfo))   // only timestamp is 
used to compare
rowInfo = row.primaryKeyLivenessInfo();
{quote}
3. when timestamps are the same, whether TTL is considered or ignored, is 
depending which row is luckily compared first.
{quote}
  a. insert Row-A using timestamp 1;  flush
  b. insert Row-A using timestamp 1 and ttl 5; flush
  c. sleep 6 second
  d. check result, Row-A exists
  reversed step a and b and try again. Row-A not longer exists.
{quote}
imo, when timestamps are same, livenessInfo with greater localDeletionTime 
should supersede another if both are TTL. if only one is TTL, ttl supersede. 
 


was (Author: jasonstack):
one more issue in Row.Merger:

| if (row.primaryKeyLivenessInfo().supersedes(rowInfo))   // only timestamp is 
used to compare
|rowInfo = row.primaryKeyLivenessInfo();

3. when timestamps are the same, whether TTL is considered or ignored, is 
depending which row is luckily compared first.

|  a. insert Row-A using timestamp 1;  flush
|  b. insert Row-A using timestamp 1 and ttl 5; flush
|  c. sleep 6 second
|  d. check result, Row-A exists
|  reversed step a and b and try again. Row-A not longer exists.

imo, when timestamps are same, livenessInfo with greater localDeletionTime 
should supersede another if both are TTL. if only one is TTL, ttl supersede. 
 

> Materialized Views: View row expires too soon
> -
>
> Key: CASSANDRA-13127
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13127
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths, Materialized Views
>Reporter: Duarte Nunes
>Assignee: ZhaoYang
>
> Consider the following commands, ran against trunk:
> {code}
> echo "DROP MATERIALIZED VIEW ks.mv; DROP TABLE ks.base;" | bin/cqlsh
> echo "CREATE TABLE ks.base (p int, c int, v int, PRIMARY KEY (p, c));" | 
> bin/cqlsh
> echo "CREATE MATERIALIZED VIEW ks.mv AS SELECT p, c FROM base WHERE p IS NOT 
> NULL AND c IS NOT NULL PRIMARY KEY (c, p);" | bin/cqlsh
> echo "INSERT INTO ks.base (p, c) VALUES (0, 0) USING TTL 10;" | bin/cqlsh
> # wait for row liveness to get closer to expiration
> sleep 6;
> echo "UPDATE ks.base USING TTL 8 SET v = 0 WHERE p = 0 and c = 0;" | bin/cqlsh
> echo "SELECT p, c, ttl(v) FROM ks.base; SELECT * FROM ks.mv;" | bin/cqlsh
>  p | c | ttl(v)
> ---+---+
>  0 | 0 |  7
> (1 rows)
>  c | p
> ---+---
>  0 | 0
> (1 rows)
> # wait for row liveness to expire
> sleep 4;
> echo "SELECT p, c, ttl(v) FROM ks.base; SELECT * FROM ks.mv;" | bin/cqlsh
>  p | c | ttl(v)
> ---+---+
>  0 | 0 |  3
> (1 rows)
>  c | p
> ---+---
> (0 rows)
> {code}
> Notice how the view row is removed even though the base row is still live. I 
> would say this is because in ViewUpdateGenerator#computeLivenessInfoForEntry 
> the TTLs are compared instead of the expiration times, but I'm not sure I'm 
> getting that far ahead in the code when updating a column that's not in the 
> view.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Comment Edited] (CASSANDRA-13127) Materialized Views: View row expires too soon

[ZhaoYang (JIRA)]

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

ZhaoYang edited comment on CASSANDRA-13127 at 6/26/17 2:05 PM:
---

|| source || junit-result || dtest-result||
| [3.11|https://github.com/jasonstack/cassandra/commits/CASSANDRA-13127-trunk] 
| [utest|https://circleci.com/gh/jasonstack/cassandra/59] | |
| [dtest| https://github.com/jasonstack/cassandra-dtest/commits/CASSANDRA-13127 
 ] | \ | \ |

1. View.mayBeAffectedBy  will return true as long as view-key-values are not 
filtered

2. LivenessInfo.supersedes(another) will check localDeletionTime if timestamps 
are the same. greater localDeletionTimestamp supersedes. 
 



was (Author: jasonstack):
|| source || junit-result || dtest-result||
| [3.11|https://github.com/jasonstack/cassandra/commits/CASSANDRA-13127-trunk] 
| [utest|https://circleci.com/gh/jasonstack/cassandra/57] | |
| [dtest| https://github.com/jasonstack/cassandra-dtest/commits/CASSANDRA-13127 
 ] | \ | \ |

1. View.mayBeAffectedBy  will return true as long as view-key-values are not 
filtered

2. LivenessInfo.supersedes(another) will check localDeletionTime if timestamps 
are the same. greater localDeletionTimestamp supersedes.  (for primary key)
 


> Materialized Views: View row expires too soon
> -
>
> Key: CASSANDRA-13127
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13127
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths, Materialized Views
>Reporter: Duarte Nunes
>Assignee: ZhaoYang
>
> Consider the following commands, ran against trunk:
> {code}
> echo "DROP MATERIALIZED VIEW ks.mv; DROP TABLE ks.base;" | bin/cqlsh
> echo "CREATE TABLE ks.base (p int, c int, v int, PRIMARY KEY (p, c));" | 
> bin/cqlsh
> echo "CREATE MATERIALIZED VIEW ks.mv AS SELECT p, c FROM base WHERE p IS NOT 
> NULL AND c IS NOT NULL PRIMARY KEY (c, p);" | bin/cqlsh
> echo "INSERT INTO ks.base (p, c) VALUES (0, 0) USING TTL 10;" | bin/cqlsh
> # wait for row liveness to get closer to expiration
> sleep 6;
> echo "UPDATE ks.base USING TTL 8 SET v = 0 WHERE p = 0 and c = 0;" | bin/cqlsh
> echo "SELECT p, c, ttl(v) FROM ks.base; SELECT * FROM ks.mv;" | bin/cqlsh
>  p | c | ttl(v)
> ---+---+
>  0 | 0 |  7
> (1 rows)
>  c | p
> ---+---
>  0 | 0
> (1 rows)
> # wait for row liveness to expire
> sleep 4;
> echo "SELECT p, c, ttl(v) FROM ks.base; SELECT * FROM ks.mv;" | bin/cqlsh
>  p | c | ttl(v)
> ---+---+
>  0 | 0 |  3
> (1 rows)
>  c | p
> ---+---
> (0 rows)
> {code}
> Notice how the view row is removed even though the base row is still live. I 
> would say this is because in ViewUpdateGenerator#computeLivenessInfoForEntry 
> the TTLs are compared instead of the expiration times, but I'm not sure I'm 
> getting that far ahead in the code when updating a column that's not in the 
> view.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Comment Edited] (CASSANDRA-13127) Materialized Views: View row expires too soon

[ZhaoYang (JIRA)]

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

ZhaoYang edited comment on CASSANDRA-13127 at 6/26/17 2:04 PM:
---

one more issue in Row.Merger:

| if (row.primaryKeyLivenessInfo().supersedes(rowInfo))   // only timestamp is 
used to compare
|rowInfo = row.primaryKeyLivenessInfo();

3. when timestamps are the same, whether TTL is considered or ignored, is 
depending which row is luckily compared first.

|  a. insert Row-A using timestamp 1;  flush
|  b. insert Row-A using timestamp 1 and ttl 5; flush
|  c. sleep 6 second
|  d. check result, Row-A exists
|  reversed step a and b and try again. Row-A not longer exists.

imo, when timestamps are same, livenessInfo with greater localDeletionTime 
should supersede another if both are TTL. if only one is TTL, ttl supersede. 
 


was (Author: jasonstack):
one more issue in Row.Merger:

> if (row.primaryKeyLivenessInfo().supersedes(rowInfo))   // only timestamp is 
> used to compare
>rowInfo = row.primaryKeyLivenessInfo();

3. when timestamps are the same, whether TTL is considered or ignored, is 
depending which row is luckily compared first.

>  a. insert Row-A using timestamp 1;  flush
>  b. insert Row-A using timestamp 1 and ttl 5; flush
>  c. sleep 6 second
>  d. check result, Row-A exists
>  reversed step a and b and try again. Row-A not longer exists.

imo, when timestamps are same, livenessInfo with greater localDeletionTime 
should supersede another. 
 

> Materialized Views: View row expires too soon
> -
>
> Key: CASSANDRA-13127
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13127
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths, Materialized Views
>Reporter: Duarte Nunes
>Assignee: ZhaoYang
>
> Consider the following commands, ran against trunk:
> {code}
> echo "DROP MATERIALIZED VIEW ks.mv; DROP TABLE ks.base;" | bin/cqlsh
> echo "CREATE TABLE ks.base (p int, c int, v int, PRIMARY KEY (p, c));" | 
> bin/cqlsh
> echo "CREATE MATERIALIZED VIEW ks.mv AS SELECT p, c FROM base WHERE p IS NOT 
> NULL AND c IS NOT NULL PRIMARY KEY (c, p);" | bin/cqlsh
> echo "INSERT INTO ks.base (p, c) VALUES (0, 0) USING TTL 10;" | bin/cqlsh
> # wait for row liveness to get closer to expiration
> sleep 6;
> echo "UPDATE ks.base USING TTL 8 SET v = 0 WHERE p = 0 and c = 0;" | bin/cqlsh
> echo "SELECT p, c, ttl(v) FROM ks.base; SELECT * FROM ks.mv;" | bin/cqlsh
>  p | c | ttl(v)
> ---+---+
>  0 | 0 |  7
> (1 rows)
>  c | p
> ---+---
>  0 | 0
> (1 rows)
> # wait for row liveness to expire
> sleep 4;
> echo "SELECT p, c, ttl(v) FROM ks.base; SELECT * FROM ks.mv;" | bin/cqlsh
>  p | c | ttl(v)
> ---+---+
>  0 | 0 |  3
> (1 rows)
>  c | p
> ---+---
> (0 rows)
> {code}
> Notice how the view row is removed even though the base row is still live. I 
> would say this is because in ViewUpdateGenerator#computeLivenessInfoForEntry 
> the TTLs are compared instead of the expiration times, but I'm not sure I'm 
> getting that far ahead in the code when updating a column that's not in the 
> view.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Created] (CASSANDRA-13638) Add the JMX metrics about the total number of hints we have delivered per host

[Petrit G (JIRA)]

Petrit G created CASSANDRA-13638:


 Summary: Add the JMX metrics about the total number of hints we 
have delivered per host
 Key: CASSANDRA-13638
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13638
 Project: Cassandra
  Issue Type: Improvement
Reporter: Petrit G
Priority: Minor


Recently metrics were added regarding how many hints have been successfully 
delivered in total.

See [here | 
http://cassandra.apache.org/doc/latest/operating/metrics.html?highlight=metrics#hintsservice-metrics],
 for more specific info. 

However I think it would be beneficial to add a metric which shows how many 
hints have been delivered per host.
More or less a corresponding metric for: 

Hints_created-

Could be named:

Hints_succeeded-

This will allow users to actually see how many hints they have towards a node, 
by calculating the difference between the two aforementioned metrics.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Comment Edited] (CASSANDRA-13127) Materialized Views: View row expires too soon

[ZhaoYang (JIRA)]

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

ZhaoYang edited comment on CASSANDRA-13127 at 6/26/17 1:41 PM:
---

|| source || junit-result || dtest-result||
| [3.11|https://github.com/jasonstack/cassandra/commits/CASSANDRA-13127-trunk] 
| [utest|https://circleci.com/gh/jasonstack/cassandra/57] | |
| [dtest| https://github.com/jasonstack/cassandra-dtest/commits/CASSANDRA-13127 
 ] | \ | \ |

1. View.mayBeAffectedBy  will return true as long as view-key-values are not 
filtered

2. LivenessInfo.supersedes(another) will check localDeletionTime if timestamps 
are the same. greater localDeletionTimestamp supersedes.  (for primary key)
 



was (Author: jasonstack):
|| source || junit-result || dtest-result||
| [3.11|https://github.com/jasonstack/cassandra/commits/CASSANDRA-13127-trunk] 
| [utest|https://circleci.com/gh/jasonstack/cassandra/57] | |
| [dtest| https://github.com/jasonstack/cassandra-dtest/commits/CASSANDRA-13127 
 ] | \ | \ |

1. View.mayBeAffectedBy  will return true as long as view-key-values are not 
filtered

2. LivenessInfo.supersedes(another) will check localDeletionTime if timestamps 
are the same. greater localDeletionTimestamp supersedes.  (for primary key)
 
3. Conflicts.resolveRegular will return LEFT_WIN if left is alive.  (for cells)



> Materialized Views: View row expires too soon
> -
>
> Key: CASSANDRA-13127
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13127
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths, Materialized Views
>Reporter: Duarte Nunes
>Assignee: ZhaoYang
>
> Consider the following commands, ran against trunk:
> {code}
> echo "DROP MATERIALIZED VIEW ks.mv; DROP TABLE ks.base;" | bin/cqlsh
> echo "CREATE TABLE ks.base (p int, c int, v int, PRIMARY KEY (p, c));" | 
> bin/cqlsh
> echo "CREATE MATERIALIZED VIEW ks.mv AS SELECT p, c FROM base WHERE p IS NOT 
> NULL AND c IS NOT NULL PRIMARY KEY (c, p);" | bin/cqlsh
> echo "INSERT INTO ks.base (p, c) VALUES (0, 0) USING TTL 10;" | bin/cqlsh
> # wait for row liveness to get closer to expiration
> sleep 6;
> echo "UPDATE ks.base USING TTL 8 SET v = 0 WHERE p = 0 and c = 0;" | bin/cqlsh
> echo "SELECT p, c, ttl(v) FROM ks.base; SELECT * FROM ks.mv;" | bin/cqlsh
>  p | c | ttl(v)
> ---+---+
>  0 | 0 |  7
> (1 rows)
>  c | p
> ---+---
>  0 | 0
> (1 rows)
> # wait for row liveness to expire
> sleep 4;
> echo "SELECT p, c, ttl(v) FROM ks.base; SELECT * FROM ks.mv;" | bin/cqlsh
>  p | c | ttl(v)
> ---+---+
>  0 | 0 |  3
> (1 rows)
>  c | p
> ---+---
> (0 rows)
> {code}
> Notice how the view row is removed even though the base row is still live. I 
> would say this is because in ViewUpdateGenerator#computeLivenessInfoForEntry 
> the TTLs are compared instead of the expiration times, but I'm not sure I'm 
> getting that far ahead in the code when updating a column that's not in the 
> view.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13067) Integer overflows with file system size reported by Amazon Elastic File System (EFS)

[Alex Petrov (JIRA)]

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

Alex Petrov updated CASSANDRA-13067:

Reviewer: Alex Petrov

> Integer overflows with file system size reported by Amazon Elastic File 
> System (EFS)
> 
>
> Key: CASSANDRA-13067
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13067
> Project: Cassandra
>  Issue Type: Bug
> Environment: Cassandra in OpenShift running on Amazon EC2 instance 
> with EFS mounted for data
>Reporter: Michael Hanselmann
>Assignee: Benjamin Lerer
> Attachments: 0001-Handle-exabyte-sized-filesystems.patch
>
>
> When not explicitly configured Cassandra uses 
> [{{nio.FileStore.getTotalSpace}}|https://docs.oracle.com/javase/7/docs/api/java/nio/file/FileStore.html]
>  to determine the total amount of available space in order to [calculate the 
> preferred commit log 
> size|https://github.com/apache/cassandra/blob/cassandra-3.9/src/java/org/apache/cassandra/config/DatabaseDescriptor.java#L553].
>  [Amazon EFS|https://aws.amazon.com/efs/] instances report a filesystem size 
> of 8 EiB when empty. [{{getTotalSpace}} causes an integer overflow 
> (JDK-8162520)|https://bugs.openjdk.java.net/browse/JDK-8162520] and returns a 
> negative number, resulting in a negative preferred size and causing the 
> checked integer to throw.
> Overriding {{commitlog_total_space_in_mb}} is not sufficient as 
> [{{DataDirectory.getAvailableSpace}}|https://github.com/apache/cassandra/blob/cassandra-3.9/src/java/org/apache/cassandra/db/Directories.java#L550]
>  makes use of {{nio.FileStore.getUsableSpace}}.
> [AMQ-6441] is a comparable issue in ActiveMQ.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13142) Upgradesstables cancels compactions unnecessarily

[Kurt Greaves (JIRA)]

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

Kurt Greaves commented on CASSANDRA-13142:
--

[~krummas] I've updated the branch although haven't addressed your second point 
yet. I agree we should block until all compactions for a given CF are finished, 
however I'm having trouble identifying a way to get currently running 
compaction futures. Is there some novel way to achieve this or should I just go 
the route of using {{CompactionInfo.Holder}}?

Also regarding {{cfs.markAllCompacting()}}, I've changed it to take operations 
to interrupt, however the main change being that it now uses 
{{getUncompactingSSTables()}} rather than {{getPermittedToCompactSSTables()}}. 
I believe this is OK as at the moment it's only ever called after all 
compactions are stopped, so these should return the same assuming all types are 
interruptible, otherwise it will return the subset of SSTables that are not 
compacting and didn't get forcibly stopped. Worth checking my logic here though.

And yeah those last three points were broken because I changed tract from 
"uninterruptibles" to "interruptibles" and confused myself... heh. Should be 
addressed now.
[github|https://github.com/apache/cassandra/compare/cassandra-2.2...kgreav:cassandra-2.2]


> Upgradesstables cancels compactions unnecessarily
> -
>
> Key: CASSANDRA-13142
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13142
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Kurt Greaves
>Assignee: Kurt Greaves
> Attachments: 13142-v1.patch
>
>
> Since at least 1.2 upgradesstables will cancel any compactions bar 
> validations when run. This was originally determined as a non-issue in 
> CASSANDRA-3430 however can be quite annoying (especially with STCS) as a 
> compaction will output the new version anyway. Furthermore, as per 
> CASSANDRA-12243 it also stops things like view builds and I assume secondary 
> index builds as well which is not ideal.
> We should avoid cancelling compactions unnecessarily.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13142) Upgradesstables cancels compactions unnecessarily

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CASSANDRA-13142:


Github user kgreav closed the pull request at:

https://github.com/apache/cassandra/pull/110


> Upgradesstables cancels compactions unnecessarily
> -
>
> Key: CASSANDRA-13142
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13142
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Kurt Greaves
>Assignee: Kurt Greaves
> Attachments: 13142-v1.patch
>
>
> Since at least 1.2 upgradesstables will cancel any compactions bar 
> validations when run. This was originally determined as a non-issue in 
> CASSANDRA-3430 however can be quite annoying (especially with STCS) as a 
> compaction will output the new version anyway. Furthermore, as per 
> CASSANDRA-12243 it also stops things like view builds and I assume secondary 
> index builds as well which is not ideal.
> We should avoid cancelling compactions unnecessarily.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13127) Materialized Views: View row expires too soon

[ZhaoYang (JIRA)]

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

ZhaoYang commented on CASSANDRA-13127:
--

|| source || junit-result || dtest-result||
| [3.11|https://github.com/jasonstack/cassandra/commits/CASSANDRA-13127-trunk] 
| [utest|https://circleci.com/gh/jasonstack/cassandra/57] | |
| [dtest| https://github.com/jasonstack/cassandra-dtest/commits/CASSANDRA-13127 
 ] | \ | \ |

1. View.mayBeAffectedBy  will return true as long as view-key-values are not 
filtered

2. LivenessInfo.supersedes(another) will check localDeletionTime if timestamps 
are the same. greater localDeletionTimestamp supersedes.  (for primary key)
 
3. Conflicts.resolveRegular will return LEFT_WIN if left is alive.  (for cells)



> Materialized Views: View row expires too soon
> -
>
> Key: CASSANDRA-13127
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13127
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths, Materialized Views
>Reporter: Duarte Nunes
>Assignee: ZhaoYang
>
> Consider the following commands, ran against trunk:
> {code}
> echo "DROP MATERIALIZED VIEW ks.mv; DROP TABLE ks.base;" | bin/cqlsh
> echo "CREATE TABLE ks.base (p int, c int, v int, PRIMARY KEY (p, c));" | 
> bin/cqlsh
> echo "CREATE MATERIALIZED VIEW ks.mv AS SELECT p, c FROM base WHERE p IS NOT 
> NULL AND c IS NOT NULL PRIMARY KEY (c, p);" | bin/cqlsh
> echo "INSERT INTO ks.base (p, c) VALUES (0, 0) USING TTL 10;" | bin/cqlsh
> # wait for row liveness to get closer to expiration
> sleep 6;
> echo "UPDATE ks.base USING TTL 8 SET v = 0 WHERE p = 0 and c = 0;" | bin/cqlsh
> echo "SELECT p, c, ttl(v) FROM ks.base; SELECT * FROM ks.mv;" | bin/cqlsh
>  p | c | ttl(v)
> ---+---+
>  0 | 0 |  7
> (1 rows)
>  c | p
> ---+---
>  0 | 0
> (1 rows)
> # wait for row liveness to expire
> sleep 4;
> echo "SELECT p, c, ttl(v) FROM ks.base; SELECT * FROM ks.mv;" | bin/cqlsh
>  p | c | ttl(v)
> ---+---+
>  0 | 0 |  3
> (1 rows)
>  c | p
> ---+---
> (0 rows)
> {code}
> Notice how the view row is removed even though the base row is still live. I 
> would say this is because in ViewUpdateGenerator#computeLivenessInfoForEntry 
> the TTLs are compared instead of the expiration times, but I'm not sure I'm 
> getting that far ahead in the code when updating a column that's not in the 
> view.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13127) Materialized Views: View row expires too soon

[ZhaoYang (JIRA)]

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

ZhaoYang updated CASSANDRA-13127:
-
Status: Awaiting Feedback  (was: In Progress)

> Materialized Views: View row expires too soon
> -
>
> Key: CASSANDRA-13127
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13127
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths, Materialized Views
>Reporter: Duarte Nunes
>Assignee: ZhaoYang
>
> Consider the following commands, ran against trunk:
> {code}
> echo "DROP MATERIALIZED VIEW ks.mv; DROP TABLE ks.base;" | bin/cqlsh
> echo "CREATE TABLE ks.base (p int, c int, v int, PRIMARY KEY (p, c));" | 
> bin/cqlsh
> echo "CREATE MATERIALIZED VIEW ks.mv AS SELECT p, c FROM base WHERE p IS NOT 
> NULL AND c IS NOT NULL PRIMARY KEY (c, p);" | bin/cqlsh
> echo "INSERT INTO ks.base (p, c) VALUES (0, 0) USING TTL 10;" | bin/cqlsh
> # wait for row liveness to get closer to expiration
> sleep 6;
> echo "UPDATE ks.base USING TTL 8 SET v = 0 WHERE p = 0 and c = 0;" | bin/cqlsh
> echo "SELECT p, c, ttl(v) FROM ks.base; SELECT * FROM ks.mv;" | bin/cqlsh
>  p | c | ttl(v)
> ---+---+
>  0 | 0 |  7
> (1 rows)
>  c | p
> ---+---
>  0 | 0
> (1 rows)
> # wait for row liveness to expire
> sleep 4;
> echo "SELECT p, c, ttl(v) FROM ks.base; SELECT * FROM ks.mv;" | bin/cqlsh
>  p | c | ttl(v)
> ---+---+
>  0 | 0 |  3
> (1 rows)
>  c | p
> ---+---
> (0 rows)
> {code}
> Notice how the view row is removed even though the base row is still live. I 
> would say this is because in ViewUpdateGenerator#computeLivenessInfoForEntry 
> the TTLs are compared instead of the expiration times, but I'm not sure I'm 
> getting that far ahead in the code when updating a column that's not in the 
> view.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-13627) Index queries are rejected on COMPACT tables

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer updated CASSANDRA-13627:
---
Resolution: Fixed
Status: Resolved  (was: Ready to Commit)

Committed into 3.0 at 57c590f6f71907dda6f3d88a16883b5dbcf259ee and merged into 
3.11 and trunk. 

> Index queries are rejected on COMPACT tables
> 
>
> Key: CASSANDRA-13627
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13627
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>
> Since {{3.0}}, {{compact}} tables are using under the hood {{static}} 
> columns. Due to that {{SELECT}} queries using secondary indexes get rejected 
> with the following error:
> {{Queries using 2ndary indexes don't support selecting only static columns}}.
> This problem can be reproduced using the following unit test:
> {code}@Test
> public void testIndicesOnCompactTable() throws Throwable
> {
> createTable("CREATE TABLE %s (pk int PRIMARY KEY, v int) WITH COMPACT 
> STORAGE");
> createIndex("CREATE INDEX ON %s(v)");
> execute("INSERT INTO %S (pk, v) VALUES (?, ?)", 1, 1);
> execute("INSERT INTO %S (pk, v) VALUES (?, ?)", 2, 1);
> execute("INSERT INTO %S (pk, v) VALUES (?, ?)", 3, 3);
> assertRows(execute("SELECT pk, v FROM %s WHERE v = 1"),
>row(1, 1),
>row(2, 1));
> }{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13627) Index queries are rejected on COMPACT tables

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer commented on CASSANDRA-13627:


Thanks for the review. I fixed the mentioned problems.

> Index queries are rejected on COMPACT tables
> 
>
> Key: CASSANDRA-13627
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13627
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>
> Since {{3.0}}, {{compact}} tables are using under the hood {{static}} 
> columns. Due to that {{SELECT}} queries using secondary indexes get rejected 
> with the following error:
> {{Queries using 2ndary indexes don't support selecting only static columns}}.
> This problem can be reproduced using the following unit test:
> {code}@Test
> public void testIndicesOnCompactTable() throws Throwable
> {
> createTable("CREATE TABLE %s (pk int PRIMARY KEY, v int) WITH COMPACT 
> STORAGE");
> createIndex("CREATE INDEX ON %s(v)");
> execute("INSERT INTO %S (pk, v) VALUES (?, ?)", 1, 1);
> execute("INSERT INTO %S (pk, v) VALUES (?, ?)", 2, 1);
> execute("INSERT INTO %S (pk, v) VALUES (?, ?)", 3, 3);
> assertRows(execute("SELECT pk, v FROM %s WHERE v = 1"),
>row(1, 1),
>row(2, 1));
> }{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[5/6] cassandra git commit: Merge branch cassandra-3.0 into cassandra-3.11

[blerer]

Merge branch cassandra-3.0 into cassandra-3.11


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/eaa3da1d
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/eaa3da1d
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/eaa3da1d

Branch: refs/heads/cassandra-3.11
Commit: eaa3da1d1290d3f909103442d88d2e390a86cf86
Parents: 56c8f0c 57c590f
Author: Benjamin Lerer 
Authored: Mon Jun 26 13:24:33 2017 +0200
Committer: Benjamin Lerer 
Committed: Mon Jun 26 13:24:33 2017 +0200

--
 CHANGES.txt |  1 +
 .../cassandra/cql3/selection/Selection.java |  2 +-
 .../validation/entities/SecondaryIndexTest.java | 43 
 3 files changed, 45 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/eaa3da1d/CHANGES.txt
--
diff --cc CHANGES.txt
index 6f2d509,d90d220..4297a15
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,5 -1,5 +1,6 @@@
 -3.0.15
 +3.11.1
 +Merged from 3.0:
+  * Fix secondary index queries on COMPACT tables (CASSANDRA-13627)
   * Nodetool listsnapshots output is missing a newline, if there are no 
snapshots (CASSANDRA-13568)
  
  

http://git-wip-us.apache.org/repos/asf/cassandra/blob/eaa3da1d/src/java/org/apache/cassandra/cql3/selection/Selection.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/eaa3da1d/test/unit/org/apache/cassandra/cql3/validation/entities/SecondaryIndexTest.java
--
diff --cc 
test/unit/org/apache/cassandra/cql3/validation/entities/SecondaryIndexTest.java
index 3aed07a,0f6cba7..bda0166
--- 
a/test/unit/org/apache/cassandra/cql3/validation/entities/SecondaryIndexTest.java
+++ 
b/test/unit/org/apache/cassandra/cql3/validation/entities/SecondaryIndexTest.java
@@@ -1577,53 -1274,46 +1577,96 @@@ public class SecondaryIndexTest extend
  assertEmpty(execute("SELECT * FROM %s WHERE a = 5"));
  }
  
+ @Test
+ public void testIndicesOnCompactTable() throws Throwable
+ {
+ assertInvalidMessage("COMPACT STORAGE with composite PRIMARY KEY 
allows no more than one column not part of the PRIMARY KEY (got: v1, v2)",
+  "CREATE TABLE test (pk int, c int, v1 int, v2 
int, PRIMARY KEY(pk, c)) WITH COMPACT STORAGE");
+ 
+ createTable("CREATE TABLE %s (pk int, c int, v int, PRIMARY KEY(pk, 
c)) WITH COMPACT STORAGE");
+ assertInvalidMessage("Secondary indexes are not supported on COMPACT 
STORAGE tables that have clustering columns",
+  "CREATE INDEX ON %s(v)");
+ 
+ createTable("CREATE TABLE %s (pk int PRIMARY KEY, v int) WITH COMPACT 
STORAGE");
+ createIndex("CREATE INDEX ON %s(v)");
+ 
+ execute("INSERT INTO %s (pk, v) VALUES (?, ?)", 1, 1);
+ execute("INSERT INTO %s (pk, v) VALUES (?, ?)", 2, 1);
+ execute("INSERT INTO %s (pk, v) VALUES (?, ?)", 3, 3);
+ 
+ assertRows(execute("SELECT pk, v FROM %s WHERE v = 1"),
+row(1, 1),
+row(2, 1));
+ 
+ assertRows(execute("SELECT pk, v FROM %s WHERE v = 3"),
+row(3, 3));
+ 
+ assertEmpty(execute("SELECT pk, v FROM %s WHERE v = 5"));
+ 
+ createTable("CREATE TABLE %s (pk int PRIMARY KEY, v1 int, v2 int) 
WITH COMPACT STORAGE");
+ createIndex("CREATE INDEX ON %s(v1)");
+ 
+ execute("INSERT INTO %s (pk, v1, v2) VALUES (?, ?, ?)", 1, 1, 1);
+ execute("INSERT INTO %s (pk, v1, v2) VALUES (?, ?, ?)", 2, 1, 2);
+ execute("INSERT INTO %s (pk, v1, v2) VALUES (?, ?, ?)", 3, 3, 3);
+ 
+ assertRows(execute("SELECT pk, v2 FROM %s WHERE v1 = 1"),
+row(1, 1),
+row(2, 2));
+ 
+ assertRows(execute("SELECT pk, v2 FROM %s WHERE v1 = 3"),
+row(3, 3));
+ 
+ assertEmpty(execute("SELECT pk, v2 FROM %s WHERE v1 = 5"));
+ }
++
 +private ResultMessage.Prepared prepareStatement(String cql, boolean 
forThrift)
 +{
 +return QueryProcessor.prepare(String.format(cql, KEYSPACE, 
currentTable()),
 +  ClientState.forInternalCalls(),
 +  forThrift);
 +}
 +
 +private void validateCell(Cell cell, ColumnDefinition def, ByteBuffer 
val, long timestamp)
 +{
 +assertNotNull(cell);
 +assertEquals(0, def.type.compare(cell.value(), val));
 +assertEquals(timestamp, cell.timestamp());
 +}
 +
 +private static void assertColumnValue(int expected, String name, Row row, 

[6/6] cassandra git commit: Merge branch cassandra-3.11 into trunk

[blerer]

Merge branch cassandra-3.11 into trunk


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/977363e1
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/977363e1
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/977363e1

Branch: refs/heads/trunk
Commit: 977363e157c5421012e059357f4253fa031198aa
Parents: 679c317 eaa3da1
Author: Benjamin Lerer 
Authored: Mon Jun 26 13:25:18 2017 +0200
Committer: Benjamin Lerer 
Committed: Mon Jun 26 13:27:58 2017 +0200

--
 CHANGES.txt |  1 +
 .../cassandra/cql3/selection/Selection.java |  2 +-
 .../cql3/statements/SelectStatement.java|  2 +-
 .../validation/entities/SecondaryIndexTest.java | 43 
 4 files changed, 46 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/977363e1/CHANGES.txt
--
diff --cc CHANGES.txt
index ab06e2b,4297a15..04640ab
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,89 -1,7 +1,90 @@@
 +4.0
 + * Improve secondary index (re)build failure and concurrency handling 
(CASSANDRA-10130)
 + * Improve calculation of available disk space for compaction 
(CASSANDRA-13068)
 + * Change the accessibility of RowCacheSerializer for third party row cache 
plugins (CASSANDRA-13579)
 + * Allow sub-range repairs for a preview of repaired data (CASSANDRA-13570)
 + * NPE in IR cleanup when columnfamily has no sstables (CASSANDRA-13585)
 + * Fix Randomness of stress values (CASSANDRA-12744)
 + * Allow selecting Map values and Set elements (CASSANDRA-7396)
 + * Fast and garbage-free Streaming Histogram (CASSANDRA-13444)
 + * Update repairTime for keyspaces on completion (CASSANDRA-13539)
 + * Add configurable upper bound for validation executor threads 
(CASSANDRA-13521)
 + * Bring back maxHintTTL propery (CASSANDRA-12982)
 + * Add testing guidelines (CASSANDRA-13497)
 + * Add more repair metrics (CASSANDRA-13531)
 + * RangeStreamer should be smarter when picking endpoints for streaming 
(CASSANDRA-4650)
 + * Avoid rewrapping an exception thrown for cache load functions 
(CASSANDRA-13367)
 + * Log time elapsed for each incremental repair phase (CASSANDRA-13498)
 + * Add multiple table operation support to cassandra-stress (CASSANDRA-8780)
 + * Fix incorrect cqlsh results when selecting same columns multiple times 
(CASSANDRA-13262)
 + * Fix WriteResponseHandlerTest is sensitive to test execution order 
(CASSANDRA-13421)
 + * Improve incremental repair logging (CASSANDRA-13468)
 + * Start compaction when incremental repair finishes (CASSANDRA-13454)
 + * Add repair streaming preview (CASSANDRA-13257)
 + * Cleanup isIncremental/repairedAt usage (CASSANDRA-13430)
 + * Change protocol to allow sending key space independent of query string 
(CASSANDRA-10145)
 + * Make gc_log and gc_warn settable at runtime (CASSANDRA-12661)
 + * Take number of files in L0 in account when estimating remaining compaction 
tasks (CASSANDRA-13354)
 + * Skip building views during base table streams on range movements 
(CASSANDRA-13065)
 + * Improve error messages for +/- operations on maps and tuples 
(CASSANDRA-13197)
 + * Remove deprecated repair JMX APIs (CASSANDRA-11530)
 + * Fix version check to enable streaming keep-alive (CASSANDRA-12929)
 + * Make it possible to monitor an ideal consistency level separate from 
actual consistency level (CASSANDRA-13289)
 + * Outbound TCP connections ignore internode authenticator (CASSANDRA-13324)
 + * Upgrade junit from 4.6 to 4.12 (CASSANDRA-13360)
 + * Cleanup ParentRepairSession after repairs (CASSANDRA-13359)
 + * Upgrade snappy-java to 1.1.2.6 (CASSANDRA-13336)
 + * Incremental repair not streaming correct sstables (CASSANDRA-13328)
 + * Upgrade the jna version to 4.3.0 (CASSANDRA-13300)
 + * Add the currentTimestamp, currentDate, currentTime and currentTimeUUID 
functions (CASSANDRA-13132)
 + * Remove config option index_interval (CASSANDRA-10671)
 + * Reduce lock contention for collection types and serializers 
(CASSANDRA-13271)
 + * Make it possible to override MessagingService.Verb ids (CASSANDRA-13283)
 + * Avoid synchronized on prepareForRepair in ActiveRepairService 
(CASSANDRA-9292)
 + * Adds the ability to use uncompressed chunks in compressed files 
(CASSANDRA-10520)
 + * Don't flush sstables when streaming for incremental repair 
(CASSANDRA-13226)
 + * Remove unused method (CASSANDRA-13227)
 + * Fix minor bugs related to #9143 (CASSANDRA-13217)
 + * Output warning if user increases RF (CASSANDRA-13079)
 + * Remove pre-3.0 streaming compatibility code for 4.0 (CASSANDRA-13081)
 + * Add support for + and - operations on dates (CASSANDRA-11936)
 + * Fix consistency of incrementally repaired data (CASSANDRA-9143)
 + * 

[4/6] cassandra git commit: Merge branch cassandra-3.0 into cassandra-3.11

[blerer]

Merge branch cassandra-3.0 into cassandra-3.11


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/eaa3da1d
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/eaa3da1d
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/eaa3da1d

Branch: refs/heads/trunk
Commit: eaa3da1d1290d3f909103442d88d2e390a86cf86
Parents: 56c8f0c 57c590f
Author: Benjamin Lerer 
Authored: Mon Jun 26 13:24:33 2017 +0200
Committer: Benjamin Lerer 
Committed: Mon Jun 26 13:24:33 2017 +0200

--
 CHANGES.txt |  1 +
 .../cassandra/cql3/selection/Selection.java |  2 +-
 .../validation/entities/SecondaryIndexTest.java | 43 
 3 files changed, 45 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/eaa3da1d/CHANGES.txt
--
diff --cc CHANGES.txt
index 6f2d509,d90d220..4297a15
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,5 -1,5 +1,6 @@@
 -3.0.15
 +3.11.1
 +Merged from 3.0:
+  * Fix secondary index queries on COMPACT tables (CASSANDRA-13627)
   * Nodetool listsnapshots output is missing a newline, if there are no 
snapshots (CASSANDRA-13568)
  
  

http://git-wip-us.apache.org/repos/asf/cassandra/blob/eaa3da1d/src/java/org/apache/cassandra/cql3/selection/Selection.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/eaa3da1d/test/unit/org/apache/cassandra/cql3/validation/entities/SecondaryIndexTest.java
--
diff --cc 
test/unit/org/apache/cassandra/cql3/validation/entities/SecondaryIndexTest.java
index 3aed07a,0f6cba7..bda0166
--- 
a/test/unit/org/apache/cassandra/cql3/validation/entities/SecondaryIndexTest.java
+++ 
b/test/unit/org/apache/cassandra/cql3/validation/entities/SecondaryIndexTest.java
@@@ -1577,53 -1274,46 +1577,96 @@@ public class SecondaryIndexTest extend
  assertEmpty(execute("SELECT * FROM %s WHERE a = 5"));
  }
  
+ @Test
+ public void testIndicesOnCompactTable() throws Throwable
+ {
+ assertInvalidMessage("COMPACT STORAGE with composite PRIMARY KEY 
allows no more than one column not part of the PRIMARY KEY (got: v1, v2)",
+  "CREATE TABLE test (pk int, c int, v1 int, v2 
int, PRIMARY KEY(pk, c)) WITH COMPACT STORAGE");
+ 
+ createTable("CREATE TABLE %s (pk int, c int, v int, PRIMARY KEY(pk, 
c)) WITH COMPACT STORAGE");
+ assertInvalidMessage("Secondary indexes are not supported on COMPACT 
STORAGE tables that have clustering columns",
+  "CREATE INDEX ON %s(v)");
+ 
+ createTable("CREATE TABLE %s (pk int PRIMARY KEY, v int) WITH COMPACT 
STORAGE");
+ createIndex("CREATE INDEX ON %s(v)");
+ 
+ execute("INSERT INTO %s (pk, v) VALUES (?, ?)", 1, 1);
+ execute("INSERT INTO %s (pk, v) VALUES (?, ?)", 2, 1);
+ execute("INSERT INTO %s (pk, v) VALUES (?, ?)", 3, 3);
+ 
+ assertRows(execute("SELECT pk, v FROM %s WHERE v = 1"),
+row(1, 1),
+row(2, 1));
+ 
+ assertRows(execute("SELECT pk, v FROM %s WHERE v = 3"),
+row(3, 3));
+ 
+ assertEmpty(execute("SELECT pk, v FROM %s WHERE v = 5"));
+ 
+ createTable("CREATE TABLE %s (pk int PRIMARY KEY, v1 int, v2 int) 
WITH COMPACT STORAGE");
+ createIndex("CREATE INDEX ON %s(v1)");
+ 
+ execute("INSERT INTO %s (pk, v1, v2) VALUES (?, ?, ?)", 1, 1, 1);
+ execute("INSERT INTO %s (pk, v1, v2) VALUES (?, ?, ?)", 2, 1, 2);
+ execute("INSERT INTO %s (pk, v1, v2) VALUES (?, ?, ?)", 3, 3, 3);
+ 
+ assertRows(execute("SELECT pk, v2 FROM %s WHERE v1 = 1"),
+row(1, 1),
+row(2, 2));
+ 
+ assertRows(execute("SELECT pk, v2 FROM %s WHERE v1 = 3"),
+row(3, 3));
+ 
+ assertEmpty(execute("SELECT pk, v2 FROM %s WHERE v1 = 5"));
+ }
++
 +private ResultMessage.Prepared prepareStatement(String cql, boolean 
forThrift)
 +{
 +return QueryProcessor.prepare(String.format(cql, KEYSPACE, 
currentTable()),
 +  ClientState.forInternalCalls(),
 +  forThrift);
 +}
 +
 +private void validateCell(Cell cell, ColumnDefinition def, ByteBuffer 
val, long timestamp)
 +{
 +assertNotNull(cell);
 +assertEquals(0, def.type.compare(cell.value(), val));
 +assertEquals(timestamp, cell.timestamp());
 +}
 +
 +private static void assertColumnValue(int expected, String name, Row row, 
CFMetaData cfm)
 

[3/6] cassandra git commit: Fix secondary index queries on COMPACT tables

[blerer]

Fix secondary index queries on COMPACT tables

patch by Benjamin Lerer; reviewed by Andrés de la Peña for CASSANDRA-13627


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/57c590f6
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/57c590f6
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/57c590f6

Branch: refs/heads/trunk
Commit: 57c590f6f71907dda6f3d88a16883b5dbcf259ee
Parents: 96bd3d5
Author: Benjamin Lerer 
Authored: Mon Jun 26 13:14:46 2017 +0200
Committer: Benjamin Lerer 
Committed: Mon Jun 26 13:14:46 2017 +0200

--
 CHANGES.txt |  1 +
 .../cassandra/cql3/selection/Selection.java |  2 +-
 .../validation/entities/SecondaryIndexTest.java | 43 
 3 files changed, 45 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/57c590f6/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 00e87bf..d90d220 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.15
+ * Fix secondary index queries on COMPACT tables (CASSANDRA-13627)
  * Nodetool listsnapshots output is missing a newline, if there are no 
snapshots (CASSANDRA-13568)
 
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/57c590f6/src/java/org/apache/cassandra/cql3/selection/Selection.java
--
diff --git a/src/java/org/apache/cassandra/cql3/selection/Selection.java 
b/src/java/org/apache/cassandra/cql3/selection/Selection.java
index 8a27314..0ecf063 100644
--- a/src/java/org/apache/cassandra/cql3/selection/Selection.java
+++ b/src/java/org/apache/cassandra/cql3/selection/Selection.java
@@ -81,7 +81,7 @@ public abstract class Selection
  */
 public boolean containsStaticColumns()
 {
-if (!cfm.hasStaticColumns())
+if (cfm.isStaticCompactTable() || !cfm.hasStaticColumns())
 return false;
 
 if (isWildcard())

http://git-wip-us.apache.org/repos/asf/cassandra/blob/57c590f6/test/unit/org/apache/cassandra/cql3/validation/entities/SecondaryIndexTest.java
--
diff --git 
a/test/unit/org/apache/cassandra/cql3/validation/entities/SecondaryIndexTest.java
 
b/test/unit/org/apache/cassandra/cql3/validation/entities/SecondaryIndexTest.java
index 1a1b881..0f6cba7 100644
--- 
a/test/unit/org/apache/cassandra/cql3/validation/entities/SecondaryIndexTest.java
+++ 
b/test/unit/org/apache/cassandra/cql3/validation/entities/SecondaryIndexTest.java
@@ -1273,4 +1273,47 @@ public class SecondaryIndexTest extends CQLTester
 assertEmpty(execute("SELECT * FROM %s WHERE a = 3"));
 assertEmpty(execute("SELECT * FROM %s WHERE a = 5"));
 }
+
+@Test
+public void testIndicesOnCompactTable() throws Throwable
+{
+assertInvalidMessage("COMPACT STORAGE with composite PRIMARY KEY 
allows no more than one column not part of the PRIMARY KEY (got: v1, v2)",
+ "CREATE TABLE test (pk int, c int, v1 int, v2 
int, PRIMARY KEY(pk, c)) WITH COMPACT STORAGE");
+
+createTable("CREATE TABLE %s (pk int, c int, v int, PRIMARY KEY(pk, 
c)) WITH COMPACT STORAGE");
+assertInvalidMessage("Secondary indexes are not supported on COMPACT 
STORAGE tables that have clustering columns",
+ "CREATE INDEX ON %s(v)");
+
+createTable("CREATE TABLE %s (pk int PRIMARY KEY, v int) WITH COMPACT 
STORAGE");
+createIndex("CREATE INDEX ON %s(v)");
+
+execute("INSERT INTO %s (pk, v) VALUES (?, ?)", 1, 1);
+execute("INSERT INTO %s (pk, v) VALUES (?, ?)", 2, 1);
+execute("INSERT INTO %s (pk, v) VALUES (?, ?)", 3, 3);
+
+assertRows(execute("SELECT pk, v FROM %s WHERE v = 1"),
+   row(1, 1),
+   row(2, 1));
+
+assertRows(execute("SELECT pk, v FROM %s WHERE v = 3"),
+   row(3, 3));
+
+assertEmpty(execute("SELECT pk, v FROM %s WHERE v = 5"));
+
+createTable("CREATE TABLE %s (pk int PRIMARY KEY, v1 int, v2 int) WITH 
COMPACT STORAGE");
+createIndex("CREATE INDEX ON %s(v1)");
+
+execute("INSERT INTO %s (pk, v1, v2) VALUES (?, ?, ?)", 1, 1, 1);
+execute("INSERT INTO %s (pk, v1, v2) VALUES (?, ?, ?)", 2, 1, 2);
+execute("INSERT INTO %s (pk, v1, v2) VALUES (?, ?, ?)", 3, 3, 3);
+
+assertRows(execute("SELECT pk, v2 FROM %s WHERE v1 = 1"),
+   row(1, 1),
+   row(2, 2));
+
+assertRows(execute("SELECT pk, v2 FROM %s WHERE v1 = 3"),
+   row(3, 3));
+
+assertEmpty(execute("SELECT pk, v2 

[1/6] cassandra git commit: Fix secondary index queries on COMPACT tables

[blerer]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 96bd3d536 -> 57c590f6f
  refs/heads/cassandra-3.11 56c8f0c58 -> eaa3da1d1
  refs/heads/trunk 679c31718 -> 977363e15


Fix secondary index queries on COMPACT tables

patch by Benjamin Lerer; reviewed by Andrés de la Peña for CASSANDRA-13627


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/57c590f6
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/57c590f6
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/57c590f6

Branch: refs/heads/cassandra-3.0
Commit: 57c590f6f71907dda6f3d88a16883b5dbcf259ee
Parents: 96bd3d5
Author: Benjamin Lerer 
Authored: Mon Jun 26 13:14:46 2017 +0200
Committer: Benjamin Lerer 
Committed: Mon Jun 26 13:14:46 2017 +0200

--
 CHANGES.txt |  1 +
 .../cassandra/cql3/selection/Selection.java |  2 +-
 .../validation/entities/SecondaryIndexTest.java | 43 
 3 files changed, 45 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/57c590f6/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 00e87bf..d90d220 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.15
+ * Fix secondary index queries on COMPACT tables (CASSANDRA-13627)
  * Nodetool listsnapshots output is missing a newline, if there are no 
snapshots (CASSANDRA-13568)
 
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/57c590f6/src/java/org/apache/cassandra/cql3/selection/Selection.java
--
diff --git a/src/java/org/apache/cassandra/cql3/selection/Selection.java 
b/src/java/org/apache/cassandra/cql3/selection/Selection.java
index 8a27314..0ecf063 100644
--- a/src/java/org/apache/cassandra/cql3/selection/Selection.java
+++ b/src/java/org/apache/cassandra/cql3/selection/Selection.java
@@ -81,7 +81,7 @@ public abstract class Selection
  */
 public boolean containsStaticColumns()
 {
-if (!cfm.hasStaticColumns())
+if (cfm.isStaticCompactTable() || !cfm.hasStaticColumns())
 return false;
 
 if (isWildcard())

http://git-wip-us.apache.org/repos/asf/cassandra/blob/57c590f6/test/unit/org/apache/cassandra/cql3/validation/entities/SecondaryIndexTest.java
--
diff --git 
a/test/unit/org/apache/cassandra/cql3/validation/entities/SecondaryIndexTest.java
 
b/test/unit/org/apache/cassandra/cql3/validation/entities/SecondaryIndexTest.java
index 1a1b881..0f6cba7 100644
--- 
a/test/unit/org/apache/cassandra/cql3/validation/entities/SecondaryIndexTest.java
+++ 
b/test/unit/org/apache/cassandra/cql3/validation/entities/SecondaryIndexTest.java
@@ -1273,4 +1273,47 @@ public class SecondaryIndexTest extends CQLTester
 assertEmpty(execute("SELECT * FROM %s WHERE a = 3"));
 assertEmpty(execute("SELECT * FROM %s WHERE a = 5"));
 }
+
+@Test
+public void testIndicesOnCompactTable() throws Throwable
+{
+assertInvalidMessage("COMPACT STORAGE with composite PRIMARY KEY 
allows no more than one column not part of the PRIMARY KEY (got: v1, v2)",
+ "CREATE TABLE test (pk int, c int, v1 int, v2 
int, PRIMARY KEY(pk, c)) WITH COMPACT STORAGE");
+
+createTable("CREATE TABLE %s (pk int, c int, v int, PRIMARY KEY(pk, 
c)) WITH COMPACT STORAGE");
+assertInvalidMessage("Secondary indexes are not supported on COMPACT 
STORAGE tables that have clustering columns",
+ "CREATE INDEX ON %s(v)");
+
+createTable("CREATE TABLE %s (pk int PRIMARY KEY, v int) WITH COMPACT 
STORAGE");
+createIndex("CREATE INDEX ON %s(v)");
+
+execute("INSERT INTO %s (pk, v) VALUES (?, ?)", 1, 1);
+execute("INSERT INTO %s (pk, v) VALUES (?, ?)", 2, 1);
+execute("INSERT INTO %s (pk, v) VALUES (?, ?)", 3, 3);
+
+assertRows(execute("SELECT pk, v FROM %s WHERE v = 1"),
+   row(1, 1),
+   row(2, 1));
+
+assertRows(execute("SELECT pk, v FROM %s WHERE v = 3"),
+   row(3, 3));
+
+assertEmpty(execute("SELECT pk, v FROM %s WHERE v = 5"));
+
+createTable("CREATE TABLE %s (pk int PRIMARY KEY, v1 int, v2 int) WITH 
COMPACT STORAGE");
+createIndex("CREATE INDEX ON %s(v1)");
+
+execute("INSERT INTO %s (pk, v1, v2) VALUES (?, ?, ?)", 1, 1, 1);
+execute("INSERT INTO %s (pk, v1, v2) VALUES (?, ?, ?)", 2, 1, 2);
+execute("INSERT INTO %s (pk, v1, v2) VALUES (?, ?, ?)", 3, 3, 3);
+
+assertRows(execute("SELECT pk, v2 FROM %s WHERE v1 = 1"),
+ 

[2/6] cassandra git commit: Fix secondary index queries on COMPACT tables

[blerer]

Fix secondary index queries on COMPACT tables

patch by Benjamin Lerer; reviewed by Andrés de la Peña for CASSANDRA-13627


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/57c590f6
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/57c590f6
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/57c590f6

Branch: refs/heads/cassandra-3.11
Commit: 57c590f6f71907dda6f3d88a16883b5dbcf259ee
Parents: 96bd3d5
Author: Benjamin Lerer 
Authored: Mon Jun 26 13:14:46 2017 +0200
Committer: Benjamin Lerer 
Committed: Mon Jun 26 13:14:46 2017 +0200

--
 CHANGES.txt |  1 +
 .../cassandra/cql3/selection/Selection.java |  2 +-
 .../validation/entities/SecondaryIndexTest.java | 43 
 3 files changed, 45 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/57c590f6/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 00e87bf..d90d220 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.15
+ * Fix secondary index queries on COMPACT tables (CASSANDRA-13627)
  * Nodetool listsnapshots output is missing a newline, if there are no 
snapshots (CASSANDRA-13568)
 
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/57c590f6/src/java/org/apache/cassandra/cql3/selection/Selection.java
--
diff --git a/src/java/org/apache/cassandra/cql3/selection/Selection.java 
b/src/java/org/apache/cassandra/cql3/selection/Selection.java
index 8a27314..0ecf063 100644
--- a/src/java/org/apache/cassandra/cql3/selection/Selection.java
+++ b/src/java/org/apache/cassandra/cql3/selection/Selection.java
@@ -81,7 +81,7 @@ public abstract class Selection
  */
 public boolean containsStaticColumns()
 {
-if (!cfm.hasStaticColumns())
+if (cfm.isStaticCompactTable() || !cfm.hasStaticColumns())
 return false;
 
 if (isWildcard())

http://git-wip-us.apache.org/repos/asf/cassandra/blob/57c590f6/test/unit/org/apache/cassandra/cql3/validation/entities/SecondaryIndexTest.java
--
diff --git 
a/test/unit/org/apache/cassandra/cql3/validation/entities/SecondaryIndexTest.java
 
b/test/unit/org/apache/cassandra/cql3/validation/entities/SecondaryIndexTest.java
index 1a1b881..0f6cba7 100644
--- 
a/test/unit/org/apache/cassandra/cql3/validation/entities/SecondaryIndexTest.java
+++ 
b/test/unit/org/apache/cassandra/cql3/validation/entities/SecondaryIndexTest.java
@@ -1273,4 +1273,47 @@ public class SecondaryIndexTest extends CQLTester
 assertEmpty(execute("SELECT * FROM %s WHERE a = 3"));
 assertEmpty(execute("SELECT * FROM %s WHERE a = 5"));
 }
+
+@Test
+public void testIndicesOnCompactTable() throws Throwable
+{
+assertInvalidMessage("COMPACT STORAGE with composite PRIMARY KEY 
allows no more than one column not part of the PRIMARY KEY (got: v1, v2)",
+ "CREATE TABLE test (pk int, c int, v1 int, v2 
int, PRIMARY KEY(pk, c)) WITH COMPACT STORAGE");
+
+createTable("CREATE TABLE %s (pk int, c int, v int, PRIMARY KEY(pk, 
c)) WITH COMPACT STORAGE");
+assertInvalidMessage("Secondary indexes are not supported on COMPACT 
STORAGE tables that have clustering columns",
+ "CREATE INDEX ON %s(v)");
+
+createTable("CREATE TABLE %s (pk int PRIMARY KEY, v int) WITH COMPACT 
STORAGE");
+createIndex("CREATE INDEX ON %s(v)");
+
+execute("INSERT INTO %s (pk, v) VALUES (?, ?)", 1, 1);
+execute("INSERT INTO %s (pk, v) VALUES (?, ?)", 2, 1);
+execute("INSERT INTO %s (pk, v) VALUES (?, ?)", 3, 3);
+
+assertRows(execute("SELECT pk, v FROM %s WHERE v = 1"),
+   row(1, 1),
+   row(2, 1));
+
+assertRows(execute("SELECT pk, v FROM %s WHERE v = 3"),
+   row(3, 3));
+
+assertEmpty(execute("SELECT pk, v FROM %s WHERE v = 5"));
+
+createTable("CREATE TABLE %s (pk int PRIMARY KEY, v1 int, v2 int) WITH 
COMPACT STORAGE");
+createIndex("CREATE INDEX ON %s(v1)");
+
+execute("INSERT INTO %s (pk, v1, v2) VALUES (?, ?, ?)", 1, 1, 1);
+execute("INSERT INTO %s (pk, v1, v2) VALUES (?, ?, ?)", 2, 1, 2);
+execute("INSERT INTO %s (pk, v1, v2) VALUES (?, ?, ?)", 3, 3, 3);
+
+assertRows(execute("SELECT pk, v2 FROM %s WHERE v1 = 1"),
+   row(1, 1),
+   row(2, 2));
+
+assertRows(execute("SELECT pk, v2 FROM %s WHERE v1 = 3"),
+   row(3, 3));
+
+

[jira] [Comment Edited] (CASSANDRA-13043) Unable to achieve CL while applying counters from commitlog

[Stefano Ortolani (JIRA)]

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

Stefano Ortolani edited comment on CASSANDRA-13043 at 6/26/17 11:23 AM:


Based on my analysis the request is coming from another node (and not from a 
client), apparently the coordinator. I don't understand why the replica node 
(the node where this exception is triggered) is checking for Consistency Level 
though, but I guess it might be a corner case of how counters are handled. 

[~iamaleksey], I have been told you might have some more insights here re how 
counters are handled?

I guess an easy solution would be to delay requests from other nodes.
Would that make sense/being feasible?



was (Author: ostefano):
Based on my analysis the request is coming from another node (and not from a 
client), apparently the coordinator. I don't understand why the replica node 
(the node where this exception is triggered) is checking for Consistency Level 
though, but I guess it might be a corner case of how counters are handled. 

[~iamaleksey], I have been yold you might have some more insights here re how 
counters are handled?

I guess an easy solution would be to delay requests from other nodes.
Would that make sense/being feasible?


> Unable to achieve CL while applying counters from commitlog
> ---
>
> Key: CASSANDRA-13043
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13043
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: Debian
>Reporter: Catalin Alexandru Zamfir
>
> In version 3.9 of Cassandra, we get the following exceptions on the 
> system.log whenever booting an agent. They seem to grow in number with each 
> reboot. Any idea where they come from or what can we do about them? Note that 
> the cluster is healthy (has sufficient live nodes).
> {noformat}
> 2/14/2016 12:39:47 PMINFO  10:39:47 Updating topology for /10.136.64.120
> 12/14/2016 12:39:47 PMINFO  10:39:47 Updating topology for /10.136.64.120
> 12/14/2016 12:39:47 PMWARN  10:39:47 Uncaught exception on thread 
> Thread[CounterMutationStage-111,5,main]: {}
> 12/14/2016 12:39:47 PMorg.apache.cassandra.exceptions.UnavailableException: 
> Cannot achieve consistency level LOCAL_QUORUM
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.db.ConsistencyLevel.assureSufficientLiveNodes(ConsistencyLevel.java:313)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.service.AbstractWriteResponseHandler.assureSufficientLiveNodes(AbstractWriteResponseHandler.java:146)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.service.StorageProxy.performWrite(StorageProxy.java:1054)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.service.StorageProxy.applyCounterMutationOnLeader(StorageProxy.java:1450)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.db.CounterMutationVerbHandler.doVerb(CounterMutationVerbHandler.java:48)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:64) 
> ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_111]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
>  [apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
> [apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat java.lang.Thread.run(Thread.java:745) 
> [na:1.8.0_111]
> 12/14/2016 12:39:47 PMWARN  10:39:47 Uncaught exception on thread 
> Thread[CounterMutationStage-118,5,main]: {}
> 12/14/2016 12:39:47 PMorg.apache.cassandra.exceptions.UnavailableException: 
> Cannot achieve consistency level LOCAL_QUORUM
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.db.ConsistencyLevel.assureSufficientLiveNodes(ConsistencyLevel.java:313)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.service.AbstractWriteResponseHandler.assureSufficientLiveNodes(AbstractWriteResponseHandler.java:146)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.service.StorageProxy.performWrite(StorageProxy.java:1054)
>  

[jira] [Commented] (CASSANDRA-13043) Unable to achieve CL while applying counters from commitlog

[Stefano Ortolani (JIRA)]

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

Stefano Ortolani commented on CASSANDRA-13043:
--

Based on my analysis the request is coming from another node (and not from a 
client), apparently the coordinator. I don't understand why the replica node 
(the node where this exception is triggered) is checking for Consistency Level 
though, but I guess it might be a corner case of how counters are handled. 

[~iamaleksey], I have been yold you might have some more insights here re how 
counters are handled?

I guess an easy solution would be to delay requests from other nodes.
Would that make sense/being feasible?


> Unable to achieve CL while applying counters from commitlog
> ---
>
> Key: CASSANDRA-13043
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13043
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: Debian
>Reporter: Catalin Alexandru Zamfir
>
> In version 3.9 of Cassandra, we get the following exceptions on the 
> system.log whenever booting an agent. They seem to grow in number with each 
> reboot. Any idea where they come from or what can we do about them? Note that 
> the cluster is healthy (has sufficient live nodes).
> {noformat}
> 2/14/2016 12:39:47 PMINFO  10:39:47 Updating topology for /10.136.64.120
> 12/14/2016 12:39:47 PMINFO  10:39:47 Updating topology for /10.136.64.120
> 12/14/2016 12:39:47 PMWARN  10:39:47 Uncaught exception on thread 
> Thread[CounterMutationStage-111,5,main]: {}
> 12/14/2016 12:39:47 PMorg.apache.cassandra.exceptions.UnavailableException: 
> Cannot achieve consistency level LOCAL_QUORUM
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.db.ConsistencyLevel.assureSufficientLiveNodes(ConsistencyLevel.java:313)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.service.AbstractWriteResponseHandler.assureSufficientLiveNodes(AbstractWriteResponseHandler.java:146)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.service.StorageProxy.performWrite(StorageProxy.java:1054)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.service.StorageProxy.applyCounterMutationOnLeader(StorageProxy.java:1450)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.db.CounterMutationVerbHandler.doVerb(CounterMutationVerbHandler.java:48)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:64) 
> ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_111]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
>  [apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
> [apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat java.lang.Thread.run(Thread.java:745) 
> [na:1.8.0_111]
> 12/14/2016 12:39:47 PMWARN  10:39:47 Uncaught exception on thread 
> Thread[CounterMutationStage-118,5,main]: {}
> 12/14/2016 12:39:47 PMorg.apache.cassandra.exceptions.UnavailableException: 
> Cannot achieve consistency level LOCAL_QUORUM
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.db.ConsistencyLevel.assureSufficientLiveNodes(ConsistencyLevel.java:313)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.service.AbstractWriteResponseHandler.assureSufficientLiveNodes(AbstractWriteResponseHandler.java:146)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.service.StorageProxy.performWrite(StorageProxy.java:1054)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.service.StorageProxy.applyCounterMutationOnLeader(StorageProxy.java:1450)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.db.CounterMutationVerbHandler.doVerb(CounterMutationVerbHandler.java:48)
>  ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:64) 
> ~[apache-cassandra-3.9.jar:3.9]
> 12/14/2016 12:39:47 PMat 
> 

[jira] [Created] (CASSANDRA-13637) data updated to old value after flushing largest CFS

[JIRA]

Hervé Toulan created CASSANDRA-13637:


 Summary: data updated to old value after flushing largest CFS
 Key: CASSANDRA-13637
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13637
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: RHEL 6.6 64 bits
Cassandra 2.2.6 with replication factor of 2
2 servers in the Cassandra ring. 
One server is down for maintenance for more than 24 hours


Reporter: Hervé Toulan
 Fix For: 2.2.6
 Attachments: local.zip

VitualMachine 1 : application server  + Cassandra 1
VirtualMachine 2: application server  + Cassandra 2

Cassandra1 and Cassandra2 are the only members of the Cassandra ring.

I expect Cassandra to always be synchronized as soon as VM1 and Vm2 can 
communicate.

Applicaiton server (AS1) of VM1  writes a value to Cassandra (a date).
VM1 is shot down.
VM2 reads the value written by AS1  as expected.
Cassandra of VM2 perform a flush operation.
VM2 reads the value older than the exp
ected one, the last value written by AS1.

I've lost the last inserted data, and I don't understand why.

In attached log bcs.log the read in DB:
2.4.0.1-SNAPSHOT - LCL - 26 Jun 2017 07:15:47,959 INFO  [RMI TCP 
Connection(111)-172.25.153.163] - Cassandra supervisor : check OK : last 
generation of CDR is : {color:red}Sun Jun 25 00:10:53 CEST 2017{color}
2.4.0.1-SNAPSHOT - LCL - 26 Jun 2017 07:16:47,963 INFO  [RMI TCP 
Connection(113)-172.25.153.163] - Cassandra supervisor : check OK : last 
generation of CDR is : {color:red}Thu Jun 22 07:16:10 CEST 2017{color}

Nothing has been inserted in database between the 2 logs but in debug.log from 
Cassandra I can see a flush operation the 2017-06-24 at  07:16:37,056.

What did we miss ?
How data  can be overwritten  ?



Regards,

Hervé




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Assigned] (CASSANDRA-13127) Materialized Views: View row expires too soon

[ZhaoYang (JIRA)]

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

ZhaoYang reassigned CASSANDRA-13127:


Assignee: ZhaoYang

> Materialized Views: View row expires too soon
> -
>
> Key: CASSANDRA-13127
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13127
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths, Materialized Views
>Reporter: Duarte Nunes
>Assignee: ZhaoYang
>
> Consider the following commands, ran against trunk:
> {code}
> echo "DROP MATERIALIZED VIEW ks.mv; DROP TABLE ks.base;" | bin/cqlsh
> echo "CREATE TABLE ks.base (p int, c int, v int, PRIMARY KEY (p, c));" | 
> bin/cqlsh
> echo "CREATE MATERIALIZED VIEW ks.mv AS SELECT p, c FROM base WHERE p IS NOT 
> NULL AND c IS NOT NULL PRIMARY KEY (c, p);" | bin/cqlsh
> echo "INSERT INTO ks.base (p, c) VALUES (0, 0) USING TTL 10;" | bin/cqlsh
> # wait for row liveness to get closer to expiration
> sleep 6;
> echo "UPDATE ks.base USING TTL 8 SET v = 0 WHERE p = 0 and c = 0;" | bin/cqlsh
> echo "SELECT p, c, ttl(v) FROM ks.base; SELECT * FROM ks.mv;" | bin/cqlsh
>  p | c | ttl(v)
> ---+---+
>  0 | 0 |  7
> (1 rows)
>  c | p
> ---+---
>  0 | 0
> (1 rows)
> # wait for row liveness to expire
> sleep 4;
> echo "SELECT p, c, ttl(v) FROM ks.base; SELECT * FROM ks.mv;" | bin/cqlsh
>  p | c | ttl(v)
> ---+---+
>  0 | 0 |  3
> (1 rows)
>  c | p
> ---+---
> (0 rows)
> {code}
> Notice how the view row is removed even though the base row is still live. I 
> would say this is because in ViewUpdateGenerator#computeLivenessInfoForEntry 
> the TTLs are compared instead of the expiration times, but I'm not sure I'm 
> getting that far ahead in the code when updating a column that's not in the 
> view.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13127) Materialized Views: View row expires too soon

[ZhaoYang (JIRA)]

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

ZhaoYang commented on CASSANDRA-13127:
--

one more issue in Row.Merger:

> if (row.primaryKeyLivenessInfo().supersedes(rowInfo))   // only timestamp is 
> used to compare
>rowInfo = row.primaryKeyLivenessInfo();

3. when timestamps are the same, whether TTL is considered or ignored, is 
depending which row is luckily compared first.

>  a. insert Row-A using timestamp 1;  flush
>  b. insert Row-A using timestamp 1 and ttl 5; flush
>  c. sleep 6 second
>  d. check result, Row-A exists
>  reversed step a and b and try again. Row-A not longer exists.

imo, when timestamps are same, livenessInfo with greater localDeletionTime 
should supersede another. 
 

> Materialized Views: View row expires too soon
> -
>
> Key: CASSANDRA-13127
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13127
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths, Materialized Views
>Reporter: Duarte Nunes
>
> Consider the following commands, ran against trunk:
> {code}
> echo "DROP MATERIALIZED VIEW ks.mv; DROP TABLE ks.base;" | bin/cqlsh
> echo "CREATE TABLE ks.base (p int, c int, v int, PRIMARY KEY (p, c));" | 
> bin/cqlsh
> echo "CREATE MATERIALIZED VIEW ks.mv AS SELECT p, c FROM base WHERE p IS NOT 
> NULL AND c IS NOT NULL PRIMARY KEY (c, p);" | bin/cqlsh
> echo "INSERT INTO ks.base (p, c) VALUES (0, 0) USING TTL 10;" | bin/cqlsh
> # wait for row liveness to get closer to expiration
> sleep 6;
> echo "UPDATE ks.base USING TTL 8 SET v = 0 WHERE p = 0 and c = 0;" | bin/cqlsh
> echo "SELECT p, c, ttl(v) FROM ks.base; SELECT * FROM ks.mv;" | bin/cqlsh
>  p | c | ttl(v)
> ---+---+
>  0 | 0 |  7
> (1 rows)
>  c | p
> ---+---
>  0 | 0
> (1 rows)
> # wait for row liveness to expire
> sleep 4;
> echo "SELECT p, c, ttl(v) FROM ks.base; SELECT * FROM ks.mv;" | bin/cqlsh
>  p | c | ttl(v)
> ---+---+
>  0 | 0 |  3
> (1 rows)
>  c | p
> ---+---
> (0 rows)
> {code}
> Notice how the view row is removed even though the base row is still live. I 
> would say this is because in ViewUpdateGenerator#computeLivenessInfoForEntry 
> the TTLs are compared instead of the expiration times, but I'm not sure I'm 
> getting that far ahead in the code when updating a column that's not in the 
> view.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-13418) Allow TWCS to ignore overlaps when dropping fully expired sstables

[Romain GERARD (JIRA)]

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

Romain GERARD commented on CASSANDRA-13418:
---

Will have a look at it this week [~markerickson-wk]

> Allow TWCS to ignore overlaps when dropping fully expired sstables
> --
>
> Key: CASSANDRA-13418
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13418
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Compaction
>Reporter: Corentin Chary
>  Labels: twcs
> Attachments: twcs-cleanup.png
>
>
> http://thelastpickle.com/blog/2016/12/08/TWCS-part1.html explains it well. If 
> you really want read-repairs you're going to have sstables blocking the 
> expiration of other fully expired SSTables because they overlap.
> You can set unchecked_tombstone_compaction = true or tombstone_threshold to a 
> very low value and that will purge the blockers of old data that should 
> already have expired, thus removing the overlaps and allowing the other 
> SSTables to expire.
> The thing is that this is rather CPU intensive and not optimal. If you have 
> time series, you might not care if all your data doesn't exactly expire at 
> the right time, or if data re-appears for some time, as long as it gets 
> deleted as soon as it can. And in this situation I believe it would be really 
> beneficial to allow users to simply ignore overlapping SSTables when looking 
> for fully expired ones.
> To the question: why would you need read-repairs ?
> - Full repairs basically take longer than the TTL of the data on my dataset, 
> so this isn't really effective.
> - Even with a 10% chances of doing a repair, we found out that this would be 
> enough to greatly reduce entropy of the most used data (and if you have 
> timeseries, you're likely to have a dashboard doing the same important 
> queries over and over again).
> - LOCAL_QUORUM is too expensive (need >3 replicas), QUORUM is too slow.
> I'll try to come up with a patch demonstrating how this would work, try it on 
> our system and report the effects.
> cc: [~adejanovski], [~rgerard] as I know you worked on similar issues already.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org