[jira] [Issue Comment Deleted] (CASSANDRA-8884) Opening a non-system keyspace before first accessing the system keyspace results in deadlock
[
https://issues.apache.org/jira/browse/CASSANDRA-8884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xu Zhongxing updated CASSANDRA-8884:
Comment: was deleted
(was: Hi Piotr,
I had the same problem. After adding Keyspace.open("system"), the program does
not exit.
What do I need to do to "close" the Keyspace?)
> Opening a non-system keyspace before first accessing the system keyspace
> results in deadlock
>
>
> Key: CASSANDRA-8884
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8884
> Project: Cassandra
> Issue Type: Bug
>Reporter: Piotr Kołaczkowski
>Assignee: Benjamin Lerer
> Attachments: bulk.jstack
>
>
> I created a writer like this:
> {code}
> val writer = CQLSSTableWriter.builder()
> .forTable(tableDef.cql)
> .using(insertStatement)
> .withPartitioner(partitioner)
> .inDirectory(outputDirectory)
> .withBufferSizeInMB(bufferSizeInMB)
> .build()
> {code}
> Then I'm trying to write a row with {{addRow}} and it blocks forever.
> Everything related to {{CQLSSTableWriter}}, including its creation, is
> happening in only one thread.
> {noformat}
> "SSTableBatchOpen:3" daemon prio=10 tid=0x7f4b399d7000 nid=0x4778 waiting
> for monitor entry [0x7f4b240a7000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:118)
> - waiting to lock <0xe35fd6d0> (a java.lang.Class for
> org.apache.cassandra.db.Keyspace)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:99)
> at
> org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.prepare(SelectStatement.java:1464)
> at
> org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:517)
> at
> org.apache.cassandra.cql3.QueryProcessor.parseStatement(QueryProcessor.java:265)
> at
> org.apache.cassandra.cql3.QueryProcessor.prepareInternal(QueryProcessor.java:306)
> at
> org.apache.cassandra.cql3.QueryProcessor.executeInternal(QueryProcessor.java:316)
> at
> org.apache.cassandra.db.SystemKeyspace.getSSTableReadMeter(SystemKeyspace.java:910)
> at
> org.apache.cassandra.io.sstable.SSTableReader.(SSTableReader.java:561)
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:433)
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:343)
> at
> org.apache.cassandra.io.sstable.SSTableReader$4.run(SSTableReader.java:480)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> "SSTableBatchOpen:2" daemon prio=10 tid=0x7f4b399e7800 nid=0x4777 waiting
> for monitor entry [0x7f4b23ca3000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:118)
> - waiting to lock <0xe35fd6d0> (a java.lang.Class for
> org.apache.cassandra.db.Keyspace)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:99)
> at
> org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.prepare(SelectStatement.java:1464)
> at
> org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:517)
> at
> org.apache.cassandra.cql3.QueryProcessor.parseStatement(QueryProcessor.java:265)
> at
> org.apache.cassandra.cql3.QueryProcessor.prepareInternal(QueryProcessor.java:306)
> at
> org.apache.cassandra.cql3.QueryProcessor.executeInternal(QueryProcessor.java:316)
> at
> org.apache.cassandra.db.SystemKeyspace.getSSTableReadMeter(SystemKeyspace.java:910)
> at
> org.apache.cassandra.io.sstable.SSTableReader.(SSTableReader.java:561)
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:433)
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:343)
> at
> org.apache.cassandra.io.sstable.SSTableReader$4.run(SSTableReader.java:480)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> "SSTableBatchOpen:1" daemon prio=10 tid=0x7f4b399e7000 nid=0x4776 waiting
> for monitor entry [0x7f4b2359d000
[jira] [Commented] (CASSANDRA-8884) Opening a non-system keyspace before first accessing the system keyspace results in deadlock
[
https://issues.apache.org/jira/browse/CASSANDRA-8884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14979905#comment-14979905
]
Xu Zhongxing commented on CASSANDRA-8884:
-
Hi Piotr,
I had the same problem. After adding Keyspace.open("system"), the program does
not exit.
What do I need to do to "close" the Keyspace?
> Opening a non-system keyspace before first accessing the system keyspace
> results in deadlock
>
>
> Key: CASSANDRA-8884
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8884
> Project: Cassandra
> Issue Type: Bug
>Reporter: Piotr Kołaczkowski
>Assignee: Benjamin Lerer
> Attachments: bulk.jstack
>
>
> I created a writer like this:
> {code}
> val writer = CQLSSTableWriter.builder()
> .forTable(tableDef.cql)
> .using(insertStatement)
> .withPartitioner(partitioner)
> .inDirectory(outputDirectory)
> .withBufferSizeInMB(bufferSizeInMB)
> .build()
> {code}
> Then I'm trying to write a row with {{addRow}} and it blocks forever.
> Everything related to {{CQLSSTableWriter}}, including its creation, is
> happening in only one thread.
> {noformat}
> "SSTableBatchOpen:3" daemon prio=10 tid=0x7f4b399d7000 nid=0x4778 waiting
> for monitor entry [0x7f4b240a7000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:118)
> - waiting to lock <0xe35fd6d0> (a java.lang.Class for
> org.apache.cassandra.db.Keyspace)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:99)
> at
> org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.prepare(SelectStatement.java:1464)
> at
> org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:517)
> at
> org.apache.cassandra.cql3.QueryProcessor.parseStatement(QueryProcessor.java:265)
> at
> org.apache.cassandra.cql3.QueryProcessor.prepareInternal(QueryProcessor.java:306)
> at
> org.apache.cassandra.cql3.QueryProcessor.executeInternal(QueryProcessor.java:316)
> at
> org.apache.cassandra.db.SystemKeyspace.getSSTableReadMeter(SystemKeyspace.java:910)
> at
> org.apache.cassandra.io.sstable.SSTableReader.(SSTableReader.java:561)
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:433)
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:343)
> at
> org.apache.cassandra.io.sstable.SSTableReader$4.run(SSTableReader.java:480)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> "SSTableBatchOpen:2" daemon prio=10 tid=0x7f4b399e7800 nid=0x4777 waiting
> for monitor entry [0x7f4b23ca3000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:118)
> - waiting to lock <0xe35fd6d0> (a java.lang.Class for
> org.apache.cassandra.db.Keyspace)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:99)
> at
> org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.prepare(SelectStatement.java:1464)
> at
> org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:517)
> at
> org.apache.cassandra.cql3.QueryProcessor.parseStatement(QueryProcessor.java:265)
> at
> org.apache.cassandra.cql3.QueryProcessor.prepareInternal(QueryProcessor.java:306)
> at
> org.apache.cassandra.cql3.QueryProcessor.executeInternal(QueryProcessor.java:316)
> at
> org.apache.cassandra.db.SystemKeyspace.getSSTableReadMeter(SystemKeyspace.java:910)
> at
> org.apache.cassandra.io.sstable.SSTableReader.(SSTableReader.java:561)
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:433)
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:343)
> at
> org.apache.cassandra.io.sstable.SSTableReader$4.run(SSTableReader.java:480)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> "SSTableBatchOpen:1" daemon prio=10 tid=0x7f4b399e7000 nid=0x4776 waiting
> for monitor
[jira] [Commented] (CASSANDRA-8884) Opening a non-system keyspace before first accessing the system keyspace results in deadlock
[
https://issues.apache.org/jira/browse/CASSANDRA-8884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14979903#comment-14979903
]
Xu Zhongxing commented on CASSANDRA-8884:
-
Hi Piotr,
I had the same problem. After adding Keyspace.open("system"), the program does
not exit.
What do I need to do to "close" the Keyspace?
> Opening a non-system keyspace before first accessing the system keyspace
> results in deadlock
>
>
> Key: CASSANDRA-8884
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8884
> Project: Cassandra
> Issue Type: Bug
>Reporter: Piotr Kołaczkowski
>Assignee: Benjamin Lerer
> Attachments: bulk.jstack
>
>
> I created a writer like this:
> {code}
> val writer = CQLSSTableWriter.builder()
> .forTable(tableDef.cql)
> .using(insertStatement)
> .withPartitioner(partitioner)
> .inDirectory(outputDirectory)
> .withBufferSizeInMB(bufferSizeInMB)
> .build()
> {code}
> Then I'm trying to write a row with {{addRow}} and it blocks forever.
> Everything related to {{CQLSSTableWriter}}, including its creation, is
> happening in only one thread.
> {noformat}
> "SSTableBatchOpen:3" daemon prio=10 tid=0x7f4b399d7000 nid=0x4778 waiting
> for monitor entry [0x7f4b240a7000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:118)
> - waiting to lock <0xe35fd6d0> (a java.lang.Class for
> org.apache.cassandra.db.Keyspace)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:99)
> at
> org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.prepare(SelectStatement.java:1464)
> at
> org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:517)
> at
> org.apache.cassandra.cql3.QueryProcessor.parseStatement(QueryProcessor.java:265)
> at
> org.apache.cassandra.cql3.QueryProcessor.prepareInternal(QueryProcessor.java:306)
> at
> org.apache.cassandra.cql3.QueryProcessor.executeInternal(QueryProcessor.java:316)
> at
> org.apache.cassandra.db.SystemKeyspace.getSSTableReadMeter(SystemKeyspace.java:910)
> at
> org.apache.cassandra.io.sstable.SSTableReader.(SSTableReader.java:561)
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:433)
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:343)
> at
> org.apache.cassandra.io.sstable.SSTableReader$4.run(SSTableReader.java:480)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> "SSTableBatchOpen:2" daemon prio=10 tid=0x7f4b399e7800 nid=0x4777 waiting
> for monitor entry [0x7f4b23ca3000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:118)
> - waiting to lock <0xe35fd6d0> (a java.lang.Class for
> org.apache.cassandra.db.Keyspace)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:99)
> at
> org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.prepare(SelectStatement.java:1464)
> at
> org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:517)
> at
> org.apache.cassandra.cql3.QueryProcessor.parseStatement(QueryProcessor.java:265)
> at
> org.apache.cassandra.cql3.QueryProcessor.prepareInternal(QueryProcessor.java:306)
> at
> org.apache.cassandra.cql3.QueryProcessor.executeInternal(QueryProcessor.java:316)
> at
> org.apache.cassandra.db.SystemKeyspace.getSSTableReadMeter(SystemKeyspace.java:910)
> at
> org.apache.cassandra.io.sstable.SSTableReader.(SSTableReader.java:561)
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:433)
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:343)
> at
> org.apache.cassandra.io.sstable.SSTableReader$4.run(SSTableReader.java:480)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> "SSTableBatchOpen:1" daemon prio=10 tid=0x7f4b399e7000 nid=0x4776 waiting
> for monitor
[jira] [Commented] (CASSANDRA-8417) Default base_time_seconds in DTCS is almost always too large
[ https://issues.apache.org/jira/browse/CASSANDRA-8417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14979751#comment-14979751 ] Akihiko Kawaguchi commented on CASSANDRA-8417: -- Hi, As per the change of the default value, I think the following document should also be fixed but should I report this kind of documentation issue here or another place? http://docs.datastax.com/en/cql/3.3/cql/cql_reference/compactSubprop.html bq. base_time_seconds: 3600 (1 hour) > Default base_time_seconds in DTCS is almost always too large > > > Key: CASSANDRA-8417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8417 > Project: Cassandra > Issue Type: Improvement >Reporter: Jonathan Ellis >Assignee: Björn Hegerfors > Fix For: 2.0.12, 2.1.3 > > Attachments: cassandra-trunk-CASSANDRA-8417-basetime60.txt > > > One hour is a very long time to compact all new inserts together with any > reasonable volume at all. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10512) We do not save an upsampled index summaries
[ https://issues.apache.org/jira/browse/CASSANDRA-10512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14979225#comment-14979225 ] Ariel Weisberg edited comment on CASSANDRA-10512 at 10/29/15 1:32 AM: -- 2.1 and 2.2 build on the CASSANDRA-10511 branches. The 3.0 branch doesn't need the 10511 changes so it's just off 3.0. |[2.2 code|https://github.com/apache/cassandra/compare/apache:cassandra-2.2...aweisberg:CASSANDRA-10511-2.2?expand=1]|[utests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10511-2.2-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10511-2.2-dtest/]| |[2.1 code|https://github.com/apache/cassandra/compare/apache:cassandra-2.1...aweisberg:CASSANDRA-10511-2.1?expand=1]|[utests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10511-2.1-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10511-2.1-dtest/]| |[3.0 code|https://github.com/apache/cassandra/compare/apache:cassandra-3.0...aweisberg:CASSANDRA-10512-3.0?expand=1]|[utests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10512-3.0-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10512-3.0-dtest/]| was (Author: aweisberg): 2.1 and 2.2 build on the CASSANDRA-10511 branch. The 3.0 branch does not. |[2.2 code|https://github.com/apache/cassandra/compare/apache:cassandra-2.2...aweisberg:CASSANDRA-10511-2.2?expand=1]|[utests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10511-2.2-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10511-2.2-dtest/]| |[2.1 code|https://github.com/apache/cassandra/compare/apache:cassandra-2.1...aweisberg:CASSANDRA-10511-2.1?expand=1]|[utests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10511-2.1-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10511-2.1-dtest/]| |[3.0 code|https://github.com/apache/cassandra/compare/apache:cassandra-3.0...aweisberg:CASSANDRA-10512-3.0?expand=1]|[utests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10512-3.0-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10512-3.0-dtest/]| > We do not save an upsampled index summaries > --- > > Key: CASSANDRA-10512 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10512 > Project: Cassandra > Issue Type: Bug >Reporter: Benedict >Assignee: Ariel Weisberg > Fix For: 2.1.x, 2.2.x, 3.1 > > > If we downsample an index summary, we overwrite the existing summary, despite > downsampling being inexpensive. However on upsampling (which is expensive) we > do not, so that on restart all of our index summaries are the smallest they > have ever been adjusted to. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9304) COPY TO improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-9304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14979570#comment-14979570 ] Stefania commented on CASSANDRA-9304: - Thanks [~thobbs]! bq. Regarding Windows testing, maybe Joshua McKenzie can weight in on who can help with that? I can test on Windows myself; I've postponed setting up dtests on Windows for long enough. :) > COPY TO improvements > > > Key: CASSANDRA-9304 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9304 > Project: Cassandra > Issue Type: Improvement >Reporter: Jonathan Ellis >Assignee: Stefania >Priority: Minor > Labels: cqlsh > Fix For: 3.x, 2.1.x, 2.2.x > > > COPY FROM has gotten a lot of love. COPY TO not so much. One obvious > improvement could be to parallelize reading and writing (write one page of > data while fetching the next). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10341) Streaming does not guarantee cache invalidation
[ https://issues.apache.org/jira/browse/CASSANDRA-10341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14979527#comment-14979527 ] Paulo Motta commented on CASSANDRA-10341: - bq. we are invalidating counter cache also, but before that we are checking if row cache only is enabled. should we handle them separately? Nice catch! Updated patch handling counter cache and row cache separately. Also added tests for counter cache invalidation. ||2.1||2.2||3.0||trunk|| |[branch|https://github.com/apache/cassandra/compare/cassandra-2.1...pauloricardomg:10341-2.1]|[branch|https://github.com/apache/cassandra/compare/cassandra-2.2...pauloricardomg:10341-2.2]|[branch|https://github.com/apache/cassandra/compare/cassandra-3.0...pauloricardomg:10341-3.0]|[branch|https://github.com/apache/cassandra/compare/trunk...pauloricardomg:10341-trunk]| |[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-10341-2.1-testall/lastCompletedBuild/testReport/]|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-10341-2.2-testall/lastCompletedBuild/testReport/]|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-10341-3.0-testall/lastCompletedBuild/testReport/]|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-10341-trunk-testall/lastCompletedBuild/testReport/]| |[dtests|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-10341-2.1-dtest/lastCompletedBuild/testReport/]|[dtests|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-10341-2.2-dtest/lastCompletedBuild/testReport/]|[dtests|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-10341-3.0-dtest/lastCompletedBuild/testReport/]|[dtests|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-10341-trunk-dtest/lastCompletedBuild/testReport/]| Tests are still running. Will update when tests are finished and successful. > Streaming does not guarantee cache invalidation > --- > > Key: CASSANDRA-10341 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10341 > Project: Cassandra > Issue Type: Bug >Reporter: Benedict >Assignee: Paulo Motta > Fix For: 2.1.x, 2.2.x, 3.1 > > > Looking at the code, we attempt to invalidate the row cache for any rows we > receive via streaming, however we invalidate them immediately, before the new > data is available. So, if it is requested (which is likely if it is "hot") in > the interval, it will be re-cached and not invalidated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (CASSANDRA-10615) Large partition plus row cache causes JVM OutOfMemory Error
[
https://issues.apache.org/jira/browse/CASSANDRA-10615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Jirsa updated CASSANDRA-10615:
---
Comment: was deleted
(was: JVM OOM was one of the canonical risks of enabling the row cache older
versions of C* before the row cache was made more like a query cache in
CASSANDRA-5357. In 2.1 and newer, options have been added to control how many
rows per partition could be cached ( {{rows_per_partition_to_cache}} ) -
were/are you using the defaults? Do you have the serialized cache files saved?
)
> Large partition plus row cache causes JVM OutOfMemory Error
> ---
>
> Key: CASSANDRA-10615
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10615
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Cassandra 2.1.8.621
>Reporter: Michael Perrone
>
> Found on multiple nodes of cluster, restarting C* resulted in hung startup
> process, nodes never came up to Up Joining, but would hang until OOM. The
> work-around is to disable row cache.
> {code}
> ERROR [SharedPool-Worker-22] 2015-10-27 17:22:52,753
> JVMStabilityInspector.java:94 - JVM state determined to be unstable. Exiting
> forcefully due to:
> java.lang.OutOfMemoryError: Java heap space
> at
> org.apache.cassandra.io.util.RandomAccessReader.readBytes(RandomAccessReader.java:374)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:348)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.utils.ByteBufferUtil.readWithShortLength(ByteBufferUtil.java:327)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.db.composites.AbstractCType$Serializer.deserialize(AbstractCType.java:397)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.db.composites.AbstractCType$Serializer.deserialize(AbstractCType.java:381)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.db.OnDiskAtom$Serializer.deserializeFromSSTable(OnDiskAtom.java:75)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:52)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:46)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
> ~[guava-16.0.1.jar:na]
> at
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
> ~[guava-16.0.1.jar:na]
> at
> org.apache.cassandra.db.columniterator.SimpleSliceReader.computeNext(SimpleSliceReader.java:83)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.db.columniterator.SimpleSliceReader.computeNext(SimpleSliceReader.java:37)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
> ~[guava-16.0.1.jar:na]
> at
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
> ~[guava-16.0.1.jar:na]
> at
> org.apache.cassandra.db.columniterator.SSTableSliceIterator.hasNext(SSTableSliceIterator.java:82)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.db.filter.QueryFilter$2.getNext(QueryFilter.java:173)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.db.filter.QueryFilter$2.hasNext(QueryFilter.java:156)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:146)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:125)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:99)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
> ~[guava-16.0.1.jar:na]
> at
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
> ~[guava-16.0.1.jar:na]
> at
> org.apache.cassandra.db.filter.SliceQueryFilter.collectReducedColumns(SliceQueryFilter.java:264)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.db.filter.QueryFilter.collateColumns(QueryFilter.java:108)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.db.filter.QueryFilter.collateOnDiskAtom(QueryFilter.java:82)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.db.filter
[jira] [Commented] (CASSANDRA-10615) Large partition plus row cache causes JVM OutOfMemory Error
[
https://issues.apache.org/jira/browse/CASSANDRA-10615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14979504#comment-14979504
]
Jeff Jirsa commented on CASSANDRA-10615:
JVM OOM was one of the canonical risks of enabling the row cache older versions
of C* before the row cache was made more like a query cache in CASSANDRA-5357.
In 2.1 and newer, options have been added to control how many rows per
partition could be cached ( {{rows_per_partition_to_cache}} ) - were/are you
using the defaults? Do you have the serialized cache files saved?
> Large partition plus row cache causes JVM OutOfMemory Error
> ---
>
> Key: CASSANDRA-10615
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10615
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Cassandra 2.1.8.621
>Reporter: Michael Perrone
>
> Found on multiple nodes of cluster, restarting C* resulted in hung startup
> process, nodes never came up to Up Joining, but would hang until OOM. The
> work-around is to disable row cache.
> {code}
> ERROR [SharedPool-Worker-22] 2015-10-27 17:22:52,753
> JVMStabilityInspector.java:94 - JVM state determined to be unstable. Exiting
> forcefully due to:
> java.lang.OutOfMemoryError: Java heap space
> at
> org.apache.cassandra.io.util.RandomAccessReader.readBytes(RandomAccessReader.java:374)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:348)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.utils.ByteBufferUtil.readWithShortLength(ByteBufferUtil.java:327)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.db.composites.AbstractCType$Serializer.deserialize(AbstractCType.java:397)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.db.composites.AbstractCType$Serializer.deserialize(AbstractCType.java:381)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.db.OnDiskAtom$Serializer.deserializeFromSSTable(OnDiskAtom.java:75)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:52)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:46)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
> ~[guava-16.0.1.jar:na]
> at
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
> ~[guava-16.0.1.jar:na]
> at
> org.apache.cassandra.db.columniterator.SimpleSliceReader.computeNext(SimpleSliceReader.java:83)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.db.columniterator.SimpleSliceReader.computeNext(SimpleSliceReader.java:37)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
> ~[guava-16.0.1.jar:na]
> at
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
> ~[guava-16.0.1.jar:na]
> at
> org.apache.cassandra.db.columniterator.SSTableSliceIterator.hasNext(SSTableSliceIterator.java:82)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.db.filter.QueryFilter$2.getNext(QueryFilter.java:173)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.db.filter.QueryFilter$2.hasNext(QueryFilter.java:156)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:146)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:125)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:99)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
> ~[guava-16.0.1.jar:na]
> at
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
> ~[guava-16.0.1.jar:na]
> at
> org.apache.cassandra.db.filter.SliceQueryFilter.collectReducedColumns(SliceQueryFilter.java:264)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.db.filter.QueryFilter.collateColumns(QueryFilter.java:108)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.db.filter.QueryFilter.collateOnDiskAtom(QueryFilter.java:82)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.a
[jira] [Commented] (CASSANDRA-9304) COPY TO improvements
[
https://issues.apache.org/jira/browse/CASSANDRA-9304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14979489#comment-14979489
]
Tyler Hobbs commented on CASSANDRA-9304:
[~Stefania] very nice work! You did a very good job with the error handling
and backoff. You're also getting pretty good at python :)
I think the rate of ~60k rows/sec on a laptop is good for now. We could
probably double that, but I think most of the low-hanging fruit has been picked
here.
Your latest commits look good to me, and I'm fine with the {{NO_COLOR_MAP}} fix.
Regarding Windows testing, maybe [~JoshuaMcKenzie] can weight in on who can
help with that?
> COPY TO improvements
>
>
> Key: CASSANDRA-9304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9304
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Jonathan Ellis
>Assignee: Stefania
>Priority: Minor
> Labels: cqlsh
> Fix For: 3.x, 2.1.x, 2.2.x
>
>
> COPY FROM has gotten a lot of love. COPY TO not so much. One obvious
> improvement could be to parallelize reading and writing (write one page of
> data while fetching the next).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-10474) Streaming should tolerate secondary index build failure
[ https://issues.apache.org/jira/browse/CASSANDRA-10474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita reassigned CASSANDRA-10474: -- Assignee: Yuki Morishita > Streaming should tolerate secondary index build failure > --- > > Key: CASSANDRA-10474 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10474 > Project: Cassandra > Issue Type: Bug >Reporter: Yuki Morishita >Assignee: Yuki Morishita > Labels: streaming > Fix For: 2.1.x, 2.2.x > > > When streaming failed to build secondary index at the end of streaming (like > in CASSANDRA-10449), streaming session can hang as it throws exception > without catching it. > Streaming should tolerate secondary index build failure, and instead of > failing (hanging) streaming session, it should WARN user and go on. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10474) Streaming should tolerate secondary index build failure
[ https://issues.apache.org/jira/browse/CASSANDRA-10474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14979431#comment-14979431 ] Yuki Morishita commented on CASSANDRA-10474: For 3.0+, this is handled already. Thanks for pointing out, [~aweisberg]. I think it is still worth to add similar error handling to 2.1 and 2.2. I'll start work on that. > Streaming should tolerate secondary index build failure > --- > > Key: CASSANDRA-10474 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10474 > Project: Cassandra > Issue Type: Bug >Reporter: Yuki Morishita > Labels: streaming > Fix For: 2.1.x, 2.2.x > > > When streaming failed to build secondary index at the end of streaming (like > in CASSANDRA-10449), streaming session can hang as it throws exception > without catching it. > Streaming should tolerate secondary index build failure, and instead of > failing (hanging) streaming session, it should WARN user and go on. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10474) Streaming should tolerate secondary index build failure
[ https://issues.apache.org/jira/browse/CASSANDRA-10474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-10474: --- Fix Version/s: (was: 3.1) > Streaming should tolerate secondary index build failure > --- > > Key: CASSANDRA-10474 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10474 > Project: Cassandra > Issue Type: Bug >Reporter: Yuki Morishita > Labels: streaming > Fix For: 2.1.x, 2.2.x > > > When streaming failed to build secondary index at the end of streaming (like > in CASSANDRA-10449), streaming session can hang as it throws exception > without catching it. > Streaming should tolerate secondary index build failure, and instead of > failing (hanging) streaming session, it should WARN user and go on. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10365) Consider storing types by their CQL names in schema tables instead of fully-qualified internal class names
[
https://issues.apache.org/jira/browse/CASSANDRA-10365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14979372#comment-14979372
]
Robert Stupp commented on CASSANDRA-10365:
--
Alright - next try, same branch (force pushed):
* {{system_schema.aggregates.initcond}} is of type {{text}} and contains the
CQL term
* does not (yet) work perfectly due to the issues with
AbstractType/TypeSerializer mentioned above (created CASSANDRA-10617 for this)
* two unit tests in {{AggregationTest}} fail due these issues
* migration of 2.2 UDAs will work fine
> Consider storing types by their CQL names in schema tables instead of
> fully-qualified internal class names
> --
>
> Key: CASSANDRA-10365
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10365
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
> Labels: client-impacting
> Fix For: 3.0.0
>
>
> Consider saving CQL types names for column, UDF/UDA arguments and return
> types, and UDT components.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-10617) Provide functionality to create CQL term from bytes
Robert Stupp created CASSANDRA-10617:
Summary: Provide functionality to create CQL term from bytes
Key: CASSANDRA-10617
URL: https://issues.apache.org/jira/browse/CASSANDRA-10617
Project: Cassandra
Issue Type: Improvement
Reporter: Robert Stupp
Assignee: Robert Stupp
Fix For: 3.0.0
As mentioned in [this
comment|https://issues.apache.org/jira/browse/CASSANDRA-10365?focusedCommentId=14979182&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14979182]
in CASSANDRA-10365, the current implementations of
{{AbstractType.getString}}/{{TypeSerializer.toString}} don't work as expected
and do not generate valid CQL terms as needed by CASSANDRA-10365.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10341) Streaming does not guarantee cache invalidation
[ https://issues.apache.org/jira/browse/CASSANDRA-10341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14979344#comment-14979344 ] Yuki Morishita commented on CASSANDRA-10341: Bounds part looks good. One more thing before commit: we are invalidating counter cache also, but before that we are checking if row cache only is enabled. should we handle them separately? > Streaming does not guarantee cache invalidation > --- > > Key: CASSANDRA-10341 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10341 > Project: Cassandra > Issue Type: Bug >Reporter: Benedict >Assignee: Paulo Motta > Fix For: 2.1.x, 2.2.x, 3.1 > > > Looking at the code, we attempt to invalidate the row cache for any rows we > receive via streaming, however we invalidate them immediately, before the new > data is available. So, if it is requested (which is likely if it is "hot") in > the interval, it will be re-cached and not invalidated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10485) Missing host ID on hinted handoff write
[
https://issues.apache.org/jira/browse/CASSANDRA-10485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14975122#comment-14975122
]
Paulo Motta edited comment on CASSANDRA-10485 at 10/28/15 10:12 PM:
It seems pending endpoints are removed from the {{TokenMetadata}} before the
new pending ranges are calculated asynchronously by
{{PendingRangeCalculatorService}}. For example, when {{StorageService}}
receives a notification that a node was removed:
{code:title=StorageService.java|borderStyle=solid}
public void onRemove(InetAddress endpoint)
{
tokenMetadata.removeEndpoint(endpoint);
PendingRangeCalculatorService.instance.update();
}
{code}
So, there's a window before the new pending ranges are calculated where removed
pending endpoints are returned to write operations by
{{TokenMetadata.pendingEndpointsFor()}}, but since the endpoint was already
removed from the {{TokenMetadata}}, it's not possible to fetch the endpoint's
ID.
This seems to be confirmed by reports of this bug during node replacements or
failed bootstraps on CASSANDRA-6335 and CASSANDRA-10233. I also created a
[simple
test|https://github.com/pauloricardomg/cassandra/blob/9a4bb94f4a92ed20dba4b0c04e173c641d45251a/test/unit/org/apache/cassandra/locator/SimpleStrategyTest.java#L168]
confirming the issue.
The simple solution is to iterate over all pending ranges on
{{TokenMetadata.removeEndpoint()}}, and remove the entries containing the
removed endpoint. I assumed it's thread-safe to update the {{pendingRanges}}
backing {{HashMultiMap}} within the {{TokenMetadata}} write lock while it's
read by other threads due to this note on {{HashMultiMap}}
[documentation|https://google-collections.googlecode.com/svn/trunk/javadoc/com/google/common/collect/HashMultimap.html]:
bq. This class is not threadsafe when any concurrent operations update the
multimap. Concurrent read operations will work correctly.
Code and tests below:
||2.1||2.2||3.0||trunk||
|[branch|https://github.com/apache/cassandra/compare/cassandra-2.1...pauloricardomg:2.1-10485]|[branch|https://github.com/apache/cassandra/compare/cassandra-2.2...pauloricardomg:2.2-10485]|[branch|https://github.com/apache/cassandra/compare/cassandra-3.0...pauloricardomg:3.0-10485]|[branch|https://github.com/apache/cassandra/compare/trunk...pauloricardomg:trunk-10485]|
|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-2.1-10485-testall/lastCompletedBuild/testReport/]|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-2.2-10485-testall/lastCompletedBuild/testReport/]|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-3.0-10485-testall/lastCompletedBuild/testReport/]|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-trunk-10485-testall/lastCompletedBuild/testReport/]|
|[dtests|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-2.1-10485-dtest/lastCompletedBuild/testReport/]|[dtests|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-2.2-10485-dtest/lastCompletedBuild/testReport/]|[dtests|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-3.0-10485-dtest/lastCompletedBuild/testReport/]|[dtests|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-trunk-10485-dtest/lastCompletedBuild/testReport/]|
For the record: while investigating the issue I created an [alternative
solution|https://github.com/apache/cassandra/compare/cassandra-2.1...pauloricardomg:2.1-10485-v3],
where endpoint removal is performed only after the new pending ranges are
calculated, but I think it's not an ideal solution because it will mean hints
will be stored for a node that is already known to be removed. Furthermore it
may also break other places relying on the assumption that the endpoint was
immediately removed from {{TokenMetadata}} after the {{Gossiper}} removal
notification.
was (Author: pauloricardomg):
It seems pending endpoints are removed from the {{TokenMetadata}} before the
new pending ranges are calculated asynchronously by
{{PendingRangeCalculatorService}}. For example, when {{StorageService}}
receives a notification that a node was removed:
{code:title=StorageService.java|borderStyle=solid}
public void onRemove(InetAddress endpoint)
{
tokenMetadata.removeEndpoint(endpoint);
PendingRangeCalculatorService.instance.update();
}
{code}
So, there's a window before the new pending ranges are calculated where removed
pending endpoints are returned to write operations by
{{TokenMetadata.pendingEndpointsFor()}}, but since the endpoint was already
removed from the {{TokenMetadata}}, it's not possible to fetch the endpoint's
ID.
This seems to be confirmed by reports of this bug during node replacements or
failed bootstraps on CASSANDRA-6335 and CASSANDRA-10233. I also created a
[jira] [Commented] (CASSANDRA-10557) Streaming can throw exception when trying to retry
[
https://issues.apache.org/jira/browse/CASSANDRA-10557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14979312#comment-14979312
]
Paulo Motta commented on CASSANDRA-10557:
-
bq. SSTableWriter.abort() can throw RuntimeException which is not handled by
anything and if that happens it will leave incomplete stream.
Fair enough, lgtm. Thanks!
> Streaming can throw exception when trying to retry
> --
>
> Key: CASSANDRA-10557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10557
> Project: Cassandra
> Issue Type: Bug
>Reporter: Yuki Morishita
>Assignee: Yuki Morishita
>Priority: Minor
> Fix For: 2.1.x, 2.2.x, 3.0.0
>
>
> Streaming can throw below exception when trying to retry.
> This seems to be happening when underlining cause is not catched properly.
> {code}
> ERROR 18:45:56 [Stream #9f95fa90-7691-11e5-931f-5b735851f84a] Streaming error
> occurred
> java.lang.IllegalArgumentException: Unknown type 0
> at
> org.apache.cassandra.streaming.messages.StreamMessage$Type.get(StreamMessage.java:97)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:58)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:261)
> ~[main/:na]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10592) IllegalArgumentException in DataOutputBuffer.reallocate
[
https://issues.apache.org/jira/browse/CASSANDRA-10592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14979309#comment-14979309
]
Ariel Weisberg commented on CASSANDRA-10592:
[~sebastian.este...@datastax.com] I having a tough time running the query in
that tool. I used C* branched off of 2.2 tip. I take it the table is named test
not transaction_by_retailer.
I can't find where I can just enter the query. The query builder seems kind of
broken and can't see the table schema. It won't let me add it to the select
deck.
> IllegalArgumentException in DataOutputBuffer.reallocate
> ---
>
> Key: CASSANDRA-10592
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10592
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sebastian Estevez
>Assignee: Ariel Weisberg
> Fix For: 2.2.4, 3.0.0
>
>
> CORRECTION-
> It turns out the exception occurs when running a read using a thrift jdbc
> driver. Once you have loaded the data with stress below, run
> SELECT * FROM "autogeneratedtest"."transaction_by_retailer" using this tool -
> http://www.aquafold.com/aquadatastudio_downloads.html
>
> The exception:
> {code}
> WARN [SharedPool-Worker-1] 2015-10-22 12:58:20,792
> AbstractTracingAwareExecutorService.java:169 - Uncaught exception on thread
> Thread[SharedPool-Worker-1,5,main]: {}
> java.lang.RuntimeException: java.lang.IllegalArgumentException
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2366)
> ~[main/:na]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_60]
> at
> org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
> ~[main/:na]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
> [main/:na]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]
> Caused by: java.lang.IllegalArgumentException: null
> at java.nio.ByteBuffer.allocate(ByteBuffer.java:334) ~[na:1.8.0_60]
> at
> org.apache.cassandra.io.util.DataOutputBuffer.reallocate(DataOutputBuffer.java:63)
> ~[main/:na]
> at
> org.apache.cassandra.io.util.DataOutputBuffer.doFlush(DataOutputBuffer.java:57)
> ~[main/:na]
> at
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:132)
> ~[main/:na]
> at
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:151)
> ~[main/:na]
> at
> org.apache.cassandra.utils.ByteBufferUtil.writeWithVIntLength(ByteBufferUtil.java:296)
> ~[main/:na]
> at
> org.apache.cassandra.db.marshal.AbstractType.writeValue(AbstractType.java:374)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.BufferCell$Serializer.serialize(BufferCell.java:263)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:183)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:108)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:96)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:132)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:87)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:77)
> ~[main/:na]
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:381)
> ~[main/:na]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:136)
> ~[main/:na]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:128)
> ~[main/:na]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:123)
> ~[main/:na]
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:65)
> ~[main/:na]
> at
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:289)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1697)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2362)
> ~[main/:na]
> ... 4 common frames omitted
> {code}
> I was running this command:
> {code}
> tools/bin/cassandra-stress user
> profile=~/Desktop/startup/stress/stress.yaml n=10 ops\(insert=1\) -rate
[jira] [Updated] (CASSANDRA-10580) On dropped mutations, more details should be logged.
[ https://issues.apache.org/jira/browse/CASSANDRA-10580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anubhav Kale updated CASSANDRA-10580: - Attachment: CASSANDRA-10580-Head.patch > On dropped mutations, more details should be logged. > > > Key: CASSANDRA-10580 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10580 > Project: Cassandra > Issue Type: Bug > Environment: Production >Reporter: Anubhav Kale >Priority: Minor > Fix For: 2.1.x > > Attachments: CASSANDRA-10580-Head.patch > > > In our production cluster, we are seeing a large number of dropped mutations. > At a minimum, we should print the time the thread took to get scheduled > thereby dropping the mutation (We should also print the Message / Mutation so > it helps in figuring out which column family was affected). This will help > find the right tuning parameter for write_timeout_in_ms. > The change is small and is in StorageProxy.java and MessagingTask.java. I > will submit a patch shortly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9526) Provide a JMX hook to monitor phi values in the FailureDetector
[ https://issues.apache.org/jira/browse/CASSANDRA-9526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14979262#comment-14979262 ] Ariel Weisberg commented on CASSANDRA-9526: --- Committer please do a quick code review of this fix. > Provide a JMX hook to monitor phi values in the FailureDetector > --- > > Key: CASSANDRA-9526 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9526 > Project: Cassandra > Issue Type: Improvement >Reporter: Ron Kuris >Assignee: Ron Kuris > Labels: docs-impacting > Fix For: 2.2.4, 3.0.0 > > Attachments: Monitor-Phi-JMX.patch, Phi-Log-Debug-When-Close.patch, > Tiny-Race-Condition.patch > > > phi_convict_threshold can be tuned, but there's currently no way to monitor > the phi values to see if you're getting close. > The attached patch adds the ability to get these values via JMX. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10614) AssertionError while flushing memtables
[
https://issues.apache.org/jira/browse/CASSANDRA-10614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14979252#comment-14979252
]
Alan Boudreault commented on CASSANDRA-10614:
-
[~thobbs] I'll verify that.
It's was a one-off. It would be good to setup some regular jobs in jenkins as
you said. Adding this in the backlog.
> AssertionError while flushing memtables
> ---
>
> Key: CASSANDRA-10614
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10614
> Project: Cassandra
> Issue Type: Bug
> Components: Core, Local Write-Read Paths
>Reporter: Tyler Hobbs
>Assignee: Tyler Hobbs
>Priority: Critical
> Fix For: 3.0.0
>
>
> While running mvbench against a single local node, I noticed this stacktrace
> showing up multiple times in the logs:
> {noformat}
> ERROR 16:40:01 Exception in thread Thread[MemtableFlushWriter:1,5,main]
> java.lang.AssertionError: null
> at org.apache.cassandra.db.rows.Rows.collectStats(Rows.java:70)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter$StatsCollector.applyToRow(BigTableWriter.java:197)
> ~[main/:na]
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:116)
> ~[main/:na]
> at
> org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:38)
> ~[main/:na]
> at
> org.apache.cassandra.db.ColumnIndex.writeAndBuildIndex(ColumnIndex.java:49)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(BigTableWriter.java:149)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.SimpleSSTableMultiWriter.append(SimpleSSTableMultiWriter.java:45)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.SSTableTxnWriter.append(SSTableTxnWriter.java:52)
> ~[main/:na]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents(Memtable.java:389)
> ~[main/:na]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.runMayThrow(Memtable.java:352)
> ~[main/:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[main/:na]
> at
> com.google.common.util.concurrent.MoreExecutors$DirectExecutorService.execute(MoreExecutors.java:299)
> ~[guava-18.0.jar:na]
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1037)
> ~[main/:na]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> ~[na:1.8.0_45]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> ~[na:1.8.0_45]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_45]
> {noformat}
> To reproduce, run mvbench with the regular schema and the following arguments:
> {noformat}
> mvn exec:java -Dexec.args="--num-users 10 --num-songs 100
> --num-artists 1 -n 50 --endpoint 127.0.0.1"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10512) We do not save an upsampled index summaries
[ https://issues.apache.org/jira/browse/CASSANDRA-10512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14979225#comment-14979225 ] Ariel Weisberg commented on CASSANDRA-10512: 2.1 and 2.2 build on the CASSANDRA-10511 branch. The 3.0 branch does not. |[2.2 code|https://github.com/apache/cassandra/compare/apache:cassandra-2.2...aweisberg:CASSANDRA-10511-2.2?expand=1]|[utests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10511-2.2-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10511-2.2-dtest/]| |[2.1 code|https://github.com/apache/cassandra/compare/apache:cassandra-2.1...aweisberg:CASSANDRA-10511-2.1?expand=1]|[utests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10511-2.1-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10511-2.1-dtest/]| |[3.0 code|https://github.com/apache/cassandra/compare/apache:cassandra-3.0...aweisberg:CASSANDRA-10512-3.0?expand=1]|[utests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10512-3.0-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10512-3.0-dtest/]| > We do not save an upsampled index summaries > --- > > Key: CASSANDRA-10512 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10512 > Project: Cassandra > Issue Type: Bug >Reporter: Benedict >Assignee: Ariel Weisberg > Fix For: 2.1.x, 2.2.x, 3.1 > > > If we downsample an index summary, we overwrite the existing summary, despite > downsampling being inexpensive. However on upsampling (which is expensive) we > do not, so that on restart all of our index summaries are the smallest they > have ever been adjusted to. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10365) Consider storing types by their CQL names in schema tables instead of fully-qualified internal class names
[
https://issues.apache.org/jira/browse/CASSANDRA-10365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14979182#comment-14979182
]
Robert Stupp commented on CASSANDRA-10365:
--
Pushed a commit that adds initcond literal to schema table
[here|https://github.com/snazy/cassandra/tree/10365-uda-3.0].
Specifically the patch does:
* add {{initcond_literal}} column to {{system_schema.aggregates}}, which
contains the literal from the _CREATE AGGREGATE_ statement
* add {{initcond_version}} column to {{system_schema.aggregates}}, which
contains the native protocol version used to serialize {{initcond}} value (to
be able to read it in future versions)
* add {{"tuple"}} case to {{CqlTypeParser}} (to get {{AggregationTest}} working)
Unfortunately we cannot reliably re-construct the CQL literal for a number of
reasons:
* there are no {{TypeSerializer}} implementations for tuples/UDTs
* AbstractTextSerializer.getString() returns the non-quoted string
* TupleType/UserType return BytesSerializer - this means that nested type
combinations cannot be reliably stringified (would return a hex representation
instead of CQL tuple/UDT literals)
WRT this ticket - although it is not nice to not have the INITCOND literal in a
_describeAggregate_ method for pre-3.0 UDAs, I *think* it's ok, since UDFs and
UDAs were experimental in 2.2 and it only affects a _describeAggregate_ method,
if the driver is not "smart enough" to reconstruct the literal itself from
{{initcond}}. So - for pre-3.0 UDAs such a _describeAggregate_ would not work
perfectly and might return some hint if {{initcond_literal}} column is {{null}}.
I'm not sure whether it's worth to fix the AbstractType/TypeSerializer
getString/toString functionality (for 3.0) since it's a 'bit' more code to
change.
> Consider storing types by their CQL names in schema tables instead of
> fully-qualified internal class names
> --
>
> Key: CASSANDRA-10365
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10365
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
> Labels: client-impacting
> Fix For: 3.0.0
>
>
> Consider saving CQL types names for column, UDF/UDA arguments and return
> types, and UDT components.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10513) Update cqlsh for new driver execution API
[ https://issues.apache.org/jira/browse/CASSANDRA-10513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14979156#comment-14979156 ] Paulo Motta commented on CASSANDRA-10513: - Tests are now passing. Marking as "Ready to Commit". Thanks for the patch [~aholmber]! Committer: please commit github links which contain the updated driver, not the attached initial patches (.txt). > Update cqlsh for new driver execution API > - > > Key: CASSANDRA-10513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10513 > Project: Cassandra > Issue Type: New Feature > Components: Tools >Reporter: Adam Holmberg >Assignee: Paulo Motta >Priority: Minor > Labels: cqlsh > Fix For: 2.2.x, 3.0.x > > Attachments: 10513-2.1.txt, 10513-2.2.txt, 10513.txt > > > The 3.0 Python driver will have a few tweaks to the execution API. We'll need > to update cqlsh in a couple of minor ways. > [Results are always returned as an iterable > ResultSet|https://datastax-oss.atlassian.net/browse/PYTHON-368] > [Trace data is always attached to the > ResultSet|https://datastax-oss.atlassian.net/browse/PYTHON-318] (instead of > being attached to a statement) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10616) add support for jacoco execfile merging and bump version
[ https://issues.apache.org/jira/browse/CASSANDRA-10616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14979153#comment-14979153 ] Russ Hatch commented on CASSANDRA-10616: initial review by [~philipthompson] > add support for jacoco execfile merging and bump version > > > Key: CASSANDRA-10616 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10616 > Project: Cassandra > Issue Type: Improvement >Reporter: Russ Hatch >Assignee: Russ Hatch > Fix For: 3.x > > Attachments: trunk-10616.txt > > > To support coverage reporting across multiple machines we need to add a build > task for jacoco's merge feature. This will allow tests to be run in > fragmented ways (such as in parallel) and later combined into a single > cohesive coverage report. > Additionally, jacoco can be updated from 0.7.1 to 0.7.5. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10616) add support for jacoco execfile merging and bump version
[ https://issues.apache.org/jira/browse/CASSANDRA-10616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Russ Hatch updated CASSANDRA-10616: --- Attachment: trunk-10616.txt Attaching patch. This introduces an intermediate task called 'jacoco-merge' which is run automatically when a report is created. Running this manually will be used to combine multiple execution files when the are placed in build/jacoco/partials. Basic usage should stay the same from a user perspective, but the additional step adds flexibility for those wishing to combine reports. > add support for jacoco execfile merging and bump version > > > Key: CASSANDRA-10616 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10616 > Project: Cassandra > Issue Type: Improvement >Reporter: Russ Hatch >Assignee: Russ Hatch > Attachments: trunk-10616.txt > > > To support coverage reporting across multiple machines we need to add a build > task for jacoco's merge feature. This will allow tests to be run in > fragmented ways (such as in parallel) and later combined into a single > cohesive coverage report. > Additionally, jacoco can be updated from 0.7.1 to 0.7.5. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10614) AssertionError while flushing memtables
[
https://issues.apache.org/jira/browse/CASSANDRA-10614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14979120#comment-14979120
]
Tyler Hobbs edited comment on CASSANDRA-10614 at 10/28/15 8:03 PM:
---
The cause was a bad short-circuit of the check for whether an update affects a
view. If the view's PK only included columns from the base table's PK, empty
rows could be inserted into the view when an update didn't affect any columns
in the view.
This appears to also fix the performance regression spotted in CASSANDRA-10609.
[~aboudreault] can you verify that for me?
Patches and pending CI runs:
||branch||testall||dtest||
|[CASSANDRA-10614|https://github.com/thobbs/cassandra/tree/CASSANDRA-10614]|[testall|http://cassci.datastax.com/view/Dev/view/thobbs/job/thobbs-CASSANDRA-10614-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/thobbs/job/thobbs-CASSANDRA-10614-dtest]|
|[CASSANDRA-10614-trunk|https://github.com/thobbs/cassandra/tree/CASSANDRA-10614-trunk]|[testall|http://cassci.datastax.com/view/Dev/view/thobbs/job/thobbs-CASSANDRA-10614-trunk-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/thobbs/job/thobbs-CASSANDRA-10614-trunk-dtest]|
As far as a test goes, I could add a simple regression unit test that triggers
a flush, but it would be good to know that we regularly run MV tests long
enough to spot other issues like this. [~aboudreault] were you just doing a
one-off perf test, or is this part of a regular job?
was (Author: thobbs):
The cause was a bad short-circuit of the check for whether an update affects a
view. If the view's PK only included columns from the base table's PK, empty
rows could be inserted into the view when an update didn't affect any columns
in the view.
This appears to also fix the performance regression spotted in CASSANDRA-10609.
[~aboudreault] can you verify that for me?
Patches and pending CI runs:
||branch||testall||dtest||
|[CASSANDRA-10614|https://github.com/thobbs/cassandra/tree/CASSANDRA-10614]|[testall|http://cassci.datastax.com/view/Dev/view/beobal/job/thobbs-CASSANDRA-10614-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/beobal/job/thobbs-CASSANDRA-10614-dtest]|
|[CASSANDRA-10614-trunk|https://github.com/thobbs/cassandra/tree/CASSANDRA-10614-trunk]|[testall|http://cassci.datastax.com/view/Dev/view/beobal/job/thobbs-CASSANDRA-10614-trunk-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/beobal/job/thobbs-CASSANDRA-10614-trunk-dtest]|
As far as a test goes, I could add a simple regression unit test that triggers
a flush, but it would be good to know that we regularly run MV tests long
enough to spot other issues like this. [~aboudreault] were you just doing a
one-off perf test, or is this part of a regular job?
> AssertionError while flushing memtables
> ---
>
> Key: CASSANDRA-10614
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10614
> Project: Cassandra
> Issue Type: Bug
> Components: Core, Local Write-Read Paths
>Reporter: Tyler Hobbs
>Assignee: Tyler Hobbs
>Priority: Critical
> Fix For: 3.0.0
>
>
> While running mvbench against a single local node, I noticed this stacktrace
> showing up multiple times in the logs:
> {noformat}
> ERROR 16:40:01 Exception in thread Thread[MemtableFlushWriter:1,5,main]
> java.lang.AssertionError: null
> at org.apache.cassandra.db.rows.Rows.collectStats(Rows.java:70)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter$StatsCollector.applyToRow(BigTableWriter.java:197)
> ~[main/:na]
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:116)
> ~[main/:na]
> at
> org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:38)
> ~[main/:na]
> at
> org.apache.cassandra.db.ColumnIndex.writeAndBuildIndex(ColumnIndex.java:49)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(BigTableWriter.java:149)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.SimpleSSTableMultiWriter.append(SimpleSSTableMultiWriter.java:45)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.SSTableTxnWriter.append(SSTableTxnWriter.java:52)
> ~[main/:na]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents(Memtable.java:389)
> ~[main/:na]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.runMayThrow(Memtable.java:352)
> ~[main/:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[main/:na]
> at
> com.google.common.util.concurrent.MoreExecutors$DirectExecutorService.execute(MoreExecutors.java:299)
> ~[guava-18.0.jar:na]
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore
[jira] [Created] (CASSANDRA-10616) add support for jacoco execfile merging and bump version
Russ Hatch created CASSANDRA-10616: -- Summary: add support for jacoco execfile merging and bump version Key: CASSANDRA-10616 URL: https://issues.apache.org/jira/browse/CASSANDRA-10616 Project: Cassandra Issue Type: Improvement Reporter: Russ Hatch Assignee: Russ Hatch To support coverage reporting across multiple machines we need to add a build task for jacoco's merge feature. This will allow tests to be run in fragmented ways (such as in parallel) and later combined into a single cohesive coverage report. Additionally, jacoco can be updated from 0.7.1 to 0.7.5. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10615) Large partition plus row cache causes JVM OutOfMemory Error
[
https://issues.apache.org/jira/browse/CASSANDRA-10615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Perrone updated CASSANDRA-10615:
Description:
Found on multiple nodes of cluster, restarting C* resulted in hung startup
process, nodes never came up to Up Joining, but would hang until OOM. The
work-around is to disable row cache.
{quote}
ERROR [SharedPool-Worker-22] 2015-10-27 17:22:52,753
JVMStabilityInspector.java:94 - JVM state determined to be unstable. Exiting
forcefully due to:
java.lang.OutOfMemoryError: Java heap space
at
org.apache.cassandra.io.util.RandomAccessReader.readBytes(RandomAccessReader.java:374)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:348)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.utils.ByteBufferUtil.readWithShortLength(ByteBufferUtil.java:327)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.composites.AbstractCType$Serializer.deserialize(AbstractCType.java:397)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.composites.AbstractCType$Serializer.deserialize(AbstractCType.java:381)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.OnDiskAtom$Serializer.deserializeFromSSTable(OnDiskAtom.java:75)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:52)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:46)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
~[guava-16.0.1.jar:na]
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
~[guava-16.0.1.jar:na]
at
org.apache.cassandra.db.columniterator.SimpleSliceReader.computeNext(SimpleSliceReader.java:83)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.columniterator.SimpleSliceReader.computeNext(SimpleSliceReader.java:37)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
~[guava-16.0.1.jar:na]
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
~[guava-16.0.1.jar:na]
at
org.apache.cassandra.db.columniterator.SSTableSliceIterator.hasNext(SSTableSliceIterator.java:82)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.filter.QueryFilter$2.getNext(QueryFilter.java:173)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.filter.QueryFilter$2.hasNext(QueryFilter.java:156)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:146)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:125)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:99)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
~[guava-16.0.1.jar:na]
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
~[guava-16.0.1.jar:na]
at
org.apache.cassandra.db.filter.SliceQueryFilter.collectReducedColumns(SliceQueryFilter.java:264)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.filter.QueryFilter.collateColumns(QueryFilter.java:108)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.filter.QueryFilter.collateOnDiskAtom(QueryFilter.java:82)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.filter.QueryFilter.collateOnDiskAtom(QueryFilter.java:69)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:314)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:62)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1967)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.service.CacheService$RowCacheSerializer$1.call(CacheService.java:456)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.service.CacheService$RowCacheSerializer$1.call(CacheService.java:451)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
~[cassand
[jira] [Updated] (CASSANDRA-10615) Large partition plus row cache causes JVM OutOfMemory Error
[
https://issues.apache.org/jira/browse/CASSANDRA-10615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Perrone updated CASSANDRA-10615:
Description:
Found on multiple nodes of cluster, restarting C* resulted in hung startup
process, nodes never came up to Up Joining, but would hang until OOM. The
work-around is to disable row cache.
{code}
ERROR [SharedPool-Worker-22] 2015-10-27 17:22:52,753
JVMStabilityInspector.java:94 - JVM state determined to be unstable. Exiting
forcefully due to:
java.lang.OutOfMemoryError: Java heap space
at
org.apache.cassandra.io.util.RandomAccessReader.readBytes(RandomAccessReader.java:374)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:348)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.utils.ByteBufferUtil.readWithShortLength(ByteBufferUtil.java:327)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.composites.AbstractCType$Serializer.deserialize(AbstractCType.java:397)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.composites.AbstractCType$Serializer.deserialize(AbstractCType.java:381)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.OnDiskAtom$Serializer.deserializeFromSSTable(OnDiskAtom.java:75)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:52)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:46)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
~[guava-16.0.1.jar:na]
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
~[guava-16.0.1.jar:na]
at
org.apache.cassandra.db.columniterator.SimpleSliceReader.computeNext(SimpleSliceReader.java:83)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.columniterator.SimpleSliceReader.computeNext(SimpleSliceReader.java:37)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
~[guava-16.0.1.jar:na]
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
~[guava-16.0.1.jar:na]
at
org.apache.cassandra.db.columniterator.SSTableSliceIterator.hasNext(SSTableSliceIterator.java:82)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.filter.QueryFilter$2.getNext(QueryFilter.java:173)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.filter.QueryFilter$2.hasNext(QueryFilter.java:156)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:146)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:125)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:99)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
~[guava-16.0.1.jar:na]
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
~[guava-16.0.1.jar:na]
at
org.apache.cassandra.db.filter.SliceQueryFilter.collectReducedColumns(SliceQueryFilter.java:264)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.filter.QueryFilter.collateColumns(QueryFilter.java:108)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.filter.QueryFilter.collateOnDiskAtom(QueryFilter.java:82)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.filter.QueryFilter.collateOnDiskAtom(QueryFilter.java:69)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:314)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:62)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1967)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.service.CacheService$RowCacheSerializer$1.call(CacheService.java:456)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.service.CacheService$RowCacheSerializer$1.call(CacheService.java:451)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
~[cassandr
[jira] [Updated] (CASSANDRA-10615) Large partition plus row cache causes JVM OutOfMemory Error
[ https://issues.apache.org/jira/browse/CASSANDRA-10615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Perrone updated CASSANDRA-10615: Description: Found on multiple nodes of cluster, restarting C* resulted in hung startup process, nodes never came up to Up Joining, but would hang until OOM. The work-around is to disable row cache. ``` ERROR [SharedPool-Worker-22] 2015-10-27 17:22:52,753 JVMStabilityInspector.java:94 - JVM state determined to be unstable. Exiting forcefully due to: java.lang.OutOfMemoryError: Java heap space at org.apache.cassandra.io.util.RandomAccessReader.readBytes(RandomAccessReader.java:374) ~[cassandra-all-2.1.8.621.jar:2.1.8.621] at org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:348) ~[cassandra-all-2.1.8.621.jar:2.1.8.621] at org.apache.cassandra.utils.ByteBufferUtil.readWithShortLength(ByteBufferUtil.java:327) ~[cassandra-all-2.1.8.621.jar:2.1.8.621] at org.apache.cassandra.db.composites.AbstractCType$Serializer.deserialize(AbstractCType.java:397) ~[cassandra-all-2.1.8.621.jar:2.1.8.621] at org.apache.cassandra.db.composites.AbstractCType$Serializer.deserialize(AbstractCType.java:381) ~[cassandra-all-2.1.8.621.jar:2.1.8.621] at org.apache.cassandra.db.OnDiskAtom$Serializer.deserializeFromSSTable(OnDiskAtom.java:75) ~[cassandra-all-2.1.8.621.jar:2.1.8.621] at org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:52) ~[cassandra-all-2.1.8.621.jar:2.1.8.621] at org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:46) ~[cassandra-all-2.1.8.621.jar:2.1.8.621] at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143) ~[guava-16.0.1.jar:na] at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) ~[guava-16.0.1.jar:na] at org.apache.cassandra.db.columniterator.SimpleSliceReader.computeNext(SimpleSliceReader.java:83) ~[cassandra-all-2.1.8.621.jar:2.1.8.621] at org.apache.cassandra.db.columniterator.SimpleSliceReader.computeNext(SimpleSliceReader.java:37) ~[cassandra-all-2.1.8.621.jar:2.1.8.621] at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143) ~[guava-16.0.1.jar:na] at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) ~[guava-16.0.1.jar:na] at org.apache.cassandra.db.columniterator.SSTableSliceIterator.hasNext(SSTableSliceIterator.java:82) ~[cassandra-all-2.1.8.621.jar:2.1.8.621] at org.apache.cassandra.db.filter.QueryFilter$2.getNext(QueryFilter.java:173) ~[cassandra-all-2.1.8.621.jar:2.1.8.621] at org.apache.cassandra.db.filter.QueryFilter$2.hasNext(QueryFilter.java:156) ~[cassandra-all-2.1.8.621.jar:2.1.8.621] at org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:146) ~[cassandra-all-2.1.8.621.jar:2.1.8.621] at org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:125) ~[cassandra-all-2.1.8.621.jar:2.1.8.621] at org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:99) ~[cassandra-all-2.1.8.621.jar:2.1.8.621] at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143) ~[guava-16.0.1.jar:na] at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) ~[guava-16.0.1.jar:na] at org.apache.cassandra.db.filter.SliceQueryFilter.collectReducedColumns(SliceQueryFilter.java:264) ~[cassandra-all-2.1.8.621.jar:2.1.8.621] at org.apache.cassandra.db.filter.QueryFilter.collateColumns(QueryFilter.java:108) ~[cassandra-all-2.1.8.621.jar:2.1.8.621] at org.apache.cassandra.db.filter.QueryFilter.collateOnDiskAtom(QueryFilter.java:82) ~[cassandra-all-2.1.8.621.jar:2.1.8.621] at org.apache.cassandra.db.filter.QueryFilter.collateOnDiskAtom(QueryFilter.java:69) ~[cassandra-all-2.1.8.621.jar:2.1.8.621] at org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:314) ~[cassandra-all-2.1.8.621.jar:2.1.8.621] at org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:62) ~[cassandra-all-2.1.8.621.jar:2.1.8.621] at org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1967) ~[cassandra-all-2.1.8.621.jar:2.1.8.621] at org.apache.cassandra.service.CacheService$RowCacheSerializer$1.call(CacheService.java:456) ~[cassandra-all-2.1.8.621.jar:2.1.8.621] at org.apache.cassandra.service.CacheService$RowCacheSerializer$1.call(CacheService.java:451) ~[cassandra-all-2.1.8.621.jar:2.1.8.621] at org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164) ~[cassandra-a
[jira] [Updated] (CASSANDRA-10615) Large partition plus row cache causes JVM OutOfMemory Error
[
https://issues.apache.org/jira/browse/CASSANDRA-10615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Perrone updated CASSANDRA-10615:
Reproduced In: 2.1.8
> Large partition plus row cache causes JVM OutOfMemory Error
> ---
>
> Key: CASSANDRA-10615
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10615
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Cassandra 2.1.8.621
>Reporter: Michael Perrone
>
> Found on multiple nodes of cluster, restarting C* resulted in hung startup
> process, nodes never came up to Up Joining, but would hang until OOM. The
> work-around is to disable row cache.
> {qoute}
> ERROR [SharedPool-Worker-22] 2015-10-27 17:22:52,753
> JVMStabilityInspector.java:94 - JVM state determined to be unstable. Exiting
> forcefully due to:
> java.lang.OutOfMemoryError: Java heap space
> at
> org.apache.cassandra.io.util.RandomAccessReader.readBytes(RandomAccessReader.java:374)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:348)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.utils.ByteBufferUtil.readWithShortLength(ByteBufferUtil.java:327)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.db.composites.AbstractCType$Serializer.deserialize(AbstractCType.java:397)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.db.composites.AbstractCType$Serializer.deserialize(AbstractCType.java:381)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.db.OnDiskAtom$Serializer.deserializeFromSSTable(OnDiskAtom.java:75)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:52)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:46)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
> ~[guava-16.0.1.jar:na]
> at
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
> ~[guava-16.0.1.jar:na]
> at
> org.apache.cassandra.db.columniterator.SimpleSliceReader.computeNext(SimpleSliceReader.java:83)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.db.columniterator.SimpleSliceReader.computeNext(SimpleSliceReader.java:37)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
> ~[guava-16.0.1.jar:na]
> at
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
> ~[guava-16.0.1.jar:na]
> at
> org.apache.cassandra.db.columniterator.SSTableSliceIterator.hasNext(SSTableSliceIterator.java:82)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.db.filter.QueryFilter$2.getNext(QueryFilter.java:173)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.db.filter.QueryFilter$2.hasNext(QueryFilter.java:156)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:146)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:125)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:99)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
> ~[guava-16.0.1.jar:na]
> at
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
> ~[guava-16.0.1.jar:na]
> at
> org.apache.cassandra.db.filter.SliceQueryFilter.collectReducedColumns(SliceQueryFilter.java:264)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.db.filter.QueryFilter.collateColumns(QueryFilter.java:108)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.db.filter.QueryFilter.collateOnDiskAtom(QueryFilter.java:82)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.db.filter.QueryFilter.collateOnDiskAtom(QueryFilter.java:69)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:314)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:62)
> ~[cassandra-all-2.1.8
[jira] [Comment Edited] (CASSANDRA-10614) AssertionError while flushing memtables
[
https://issues.apache.org/jira/browse/CASSANDRA-10614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14979120#comment-14979120
]
Tyler Hobbs edited comment on CASSANDRA-10614 at 10/28/15 7:52 PM:
---
The cause was a bad short-circuit of the check for whether an update affects a
view. If the view's PK only included columns from the base table's PK, empty
rows could be inserted into the view when an update didn't affect any columns
in the view.
This appears to also fix the performance regression spotted in CASSANDRA-10609.
[~aboudreault] can you verify that for me?
Patches and pending CI runs:
||branch||testall||dtest||
|[CASSANDRA-10614|https://github.com/thobbs/cassandra/tree/CASSANDRA-10614]|[testall|http://cassci.datastax.com/view/Dev/view/beobal/job/thobbs-CASSANDRA-10614-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/beobal/job/thobbs-CASSANDRA-10614-dtest]|
|[CASSANDRA-10614-trunk|https://github.com/thobbs/cassandra/tree/CASSANDRA-10614-trunk]|[testall|http://cassci.datastax.com/view/Dev/view/beobal/job/thobbs-CASSANDRA-10614-trunk-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/beobal/job/thobbs-CASSANDRA-10614-trunk-dtest]|
As far as a test goes, I could add a simple regression unit test that triggers
a flush, but it would be good to know that we regularly run MV tests long
enough to spot other issues like this. [~aboudreault] were you just doing a
one-off perf test, or is this part of a regular job?
was (Author: thobbs):
The cause was a bad short-circuit of the check for whether an update affects a
view. If the view's PK only included columns from the base table's PK, empty
rows could be inserted into the view when an update didn't affect any columns
in the view.
This appears to also fix the performance regression spotted in CASSANDRA-10609.
[~aboudreault] can you verify that for me?
Patches and pending CI runs:
||branch||testall||dtest||
|[CASSANDRA-10614|https://github.com/thobbs/cassandra/tree/CASSANDRA-10614]|[testall|http://cassci.datastax.com/view/Dev/view/beobal/job/thobbs-CASSANDRA-10614-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/beobal/job/thobbs-CASSANDRA-10614-dtest]|
|[CASSANDRA-10614-trunk|https://github.com/thobbs/cassandra/tree/CASSANDRA-10614-trunk]|[testall|http://cassci.datastax.com/view/Dev/view/beobal/job/thobbs-CASSANDRA-10614-trunk-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/beobal/job/thobbs-CASSANDRA-10614-trunk-dtest]|
> AssertionError while flushing memtables
> ---
>
> Key: CASSANDRA-10614
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10614
> Project: Cassandra
> Issue Type: Bug
> Components: Core, Local Write-Read Paths
>Reporter: Tyler Hobbs
>Assignee: Tyler Hobbs
>Priority: Critical
> Fix For: 3.0.0
>
>
> While running mvbench against a single local node, I noticed this stacktrace
> showing up multiple times in the logs:
> {noformat}
> ERROR 16:40:01 Exception in thread Thread[MemtableFlushWriter:1,5,main]
> java.lang.AssertionError: null
> at org.apache.cassandra.db.rows.Rows.collectStats(Rows.java:70)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter$StatsCollector.applyToRow(BigTableWriter.java:197)
> ~[main/:na]
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:116)
> ~[main/:na]
> at
> org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:38)
> ~[main/:na]
> at
> org.apache.cassandra.db.ColumnIndex.writeAndBuildIndex(ColumnIndex.java:49)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(BigTableWriter.java:149)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.SimpleSSTableMultiWriter.append(SimpleSSTableMultiWriter.java:45)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.SSTableTxnWriter.append(SSTableTxnWriter.java:52)
> ~[main/:na]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents(Memtable.java:389)
> ~[main/:na]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.runMayThrow(Memtable.java:352)
> ~[main/:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[main/:na]
> at
> com.google.common.util.concurrent.MoreExecutors$DirectExecutorService.execute(MoreExecutors.java:299)
> ~[guava-18.0.jar:na]
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1037)
> ~[main/:na]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> ~[na:1.8.0_45]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> ~[na:1.8.0_45]
> at java.lang.Thread.run(Thr
[jira] [Created] (CASSANDRA-10615) Large partition plus row cache causes JVM OutOfMemory Error
Michael Perrone created CASSANDRA-10615:
---
Summary: Large partition plus row cache causes JVM OutOfMemory
Error
Key: CASSANDRA-10615
URL: https://issues.apache.org/jira/browse/CASSANDRA-10615
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: Cassandra 2.1.8.621
Reporter: Michael Perrone
Found on multiple nodes of cluster, restarting C* resulted in hung startup
process, nodes never came up to Up Joining, but would hang until OOM. The
work-around is to disable row cache.
{qoute}
ERROR [SharedPool-Worker-22] 2015-10-27 17:22:52,753
JVMStabilityInspector.java:94 - JVM state determined to be unstable. Exiting
forcefully due to:
java.lang.OutOfMemoryError: Java heap space
at
org.apache.cassandra.io.util.RandomAccessReader.readBytes(RandomAccessReader.java:374)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:348)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.utils.ByteBufferUtil.readWithShortLength(ByteBufferUtil.java:327)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.composites.AbstractCType$Serializer.deserialize(AbstractCType.java:397)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.composites.AbstractCType$Serializer.deserialize(AbstractCType.java:381)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.OnDiskAtom$Serializer.deserializeFromSSTable(OnDiskAtom.java:75)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:52)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:46)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
~[guava-16.0.1.jar:na]
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
~[guava-16.0.1.jar:na]
at
org.apache.cassandra.db.columniterator.SimpleSliceReader.computeNext(SimpleSliceReader.java:83)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.columniterator.SimpleSliceReader.computeNext(SimpleSliceReader.java:37)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
~[guava-16.0.1.jar:na]
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
~[guava-16.0.1.jar:na]
at
org.apache.cassandra.db.columniterator.SSTableSliceIterator.hasNext(SSTableSliceIterator.java:82)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.filter.QueryFilter$2.getNext(QueryFilter.java:173)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.filter.QueryFilter$2.hasNext(QueryFilter.java:156)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:146)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:125)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:99)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
~[guava-16.0.1.jar:na]
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
~[guava-16.0.1.jar:na]
at
org.apache.cassandra.db.filter.SliceQueryFilter.collectReducedColumns(SliceQueryFilter.java:264)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.filter.QueryFilter.collateColumns(QueryFilter.java:108)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.filter.QueryFilter.collateOnDiskAtom(QueryFilter.java:82)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.filter.QueryFilter.collateOnDiskAtom(QueryFilter.java:69)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:314)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:62)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1967)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.service.CacheService$RowCacheSerializer$1.call(CacheService.java:456)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.service.CacheService$RowCacheSerializer$1.call
[jira] [Updated] (CASSANDRA-10614) AssertionError while flushing memtables
[
https://issues.apache.org/jira/browse/CASSANDRA-10614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tyler Hobbs updated CASSANDRA-10614:
Reviewer: T Jake Luciani
> AssertionError while flushing memtables
> ---
>
> Key: CASSANDRA-10614
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10614
> Project: Cassandra
> Issue Type: Bug
> Components: Core, Local Write-Read Paths
>Reporter: Tyler Hobbs
>Assignee: Tyler Hobbs
>Priority: Critical
> Fix For: 3.0.0
>
>
> While running mvbench against a single local node, I noticed this stacktrace
> showing up multiple times in the logs:
> {noformat}
> ERROR 16:40:01 Exception in thread Thread[MemtableFlushWriter:1,5,main]
> java.lang.AssertionError: null
> at org.apache.cassandra.db.rows.Rows.collectStats(Rows.java:70)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter$StatsCollector.applyToRow(BigTableWriter.java:197)
> ~[main/:na]
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:116)
> ~[main/:na]
> at
> org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:38)
> ~[main/:na]
> at
> org.apache.cassandra.db.ColumnIndex.writeAndBuildIndex(ColumnIndex.java:49)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(BigTableWriter.java:149)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.SimpleSSTableMultiWriter.append(SimpleSSTableMultiWriter.java:45)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.SSTableTxnWriter.append(SSTableTxnWriter.java:52)
> ~[main/:na]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents(Memtable.java:389)
> ~[main/:na]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.runMayThrow(Memtable.java:352)
> ~[main/:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[main/:na]
> at
> com.google.common.util.concurrent.MoreExecutors$DirectExecutorService.execute(MoreExecutors.java:299)
> ~[guava-18.0.jar:na]
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1037)
> ~[main/:na]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> ~[na:1.8.0_45]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> ~[na:1.8.0_45]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_45]
> {noformat}
> To reproduce, run mvbench with the regular schema and the following arguments:
> {noformat}
> mvn exec:java -Dexec.args="--num-users 10 --num-songs 100
> --num-artists 1 -n 50 --endpoint 127.0.0.1"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10614) AssertionError while flushing memtables
[
https://issues.apache.org/jira/browse/CASSANDRA-10614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14979120#comment-14979120
]
Tyler Hobbs commented on CASSANDRA-10614:
-
The cause was a bad short-circuit of the check for whether an update affects a
view. If the view's PK only included columns from the base table's PK, empty
rows could be inserted into the view when an update didn't affect any columns
in the view.
This appears to also fix the performance regression spotted in CASSANDRA-10609.
[~aboudreault] can you verify that for me?
Patches and pending CI runs:
||branch||testall||dtest||
|[CASSANDRA-10614|https://github.com/thobbs/cassandra/tree/CASSANDRA-10614]|[testall|http://cassci.datastax.com/view/Dev/view/beobal/job/thobbs-CASSANDRA-10614-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/beobal/job/thobbs-CASSANDRA-10614-dtest]|
|[CASSANDRA-10614-trunk|https://github.com/thobbs/cassandra/tree/CASSANDRA-10614-trunk]|[testall|http://cassci.datastax.com/view/Dev/view/beobal/job/thobbs-CASSANDRA-10614-trunk-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/beobal/job/thobbs-CASSANDRA-10614-trunk-dtest]|
> AssertionError while flushing memtables
> ---
>
> Key: CASSANDRA-10614
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10614
> Project: Cassandra
> Issue Type: Bug
> Components: Core, Local Write-Read Paths
>Reporter: Tyler Hobbs
>Assignee: Tyler Hobbs
>Priority: Critical
> Fix For: 3.0.0
>
>
> While running mvbench against a single local node, I noticed this stacktrace
> showing up multiple times in the logs:
> {noformat}
> ERROR 16:40:01 Exception in thread Thread[MemtableFlushWriter:1,5,main]
> java.lang.AssertionError: null
> at org.apache.cassandra.db.rows.Rows.collectStats(Rows.java:70)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter$StatsCollector.applyToRow(BigTableWriter.java:197)
> ~[main/:na]
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:116)
> ~[main/:na]
> at
> org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:38)
> ~[main/:na]
> at
> org.apache.cassandra.db.ColumnIndex.writeAndBuildIndex(ColumnIndex.java:49)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(BigTableWriter.java:149)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.SimpleSSTableMultiWriter.append(SimpleSSTableMultiWriter.java:45)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.SSTableTxnWriter.append(SSTableTxnWriter.java:52)
> ~[main/:na]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents(Memtable.java:389)
> ~[main/:na]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.runMayThrow(Memtable.java:352)
> ~[main/:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[main/:na]
> at
> com.google.common.util.concurrent.MoreExecutors$DirectExecutorService.execute(MoreExecutors.java:299)
> ~[guava-18.0.jar:na]
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1037)
> ~[main/:na]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> ~[na:1.8.0_45]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> ~[na:1.8.0_45]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_45]
> {noformat}
> To reproduce, run mvbench with the regular schema and the following arguments:
> {noformat}
> mvn exec:java -Dexec.args="--num-users 10 --num-songs 100
> --num-artists 1 -n 50 --endpoint 127.0.0.1"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10511) Index summary downsampling prevents mmap access of large files after restart
[
https://issues.apache.org/jira/browse/CASSANDRA-10511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14979096#comment-14979096
]
Ariel Weisberg edited comment on CASSANDRA-10511 at 10/28/15 7:47 PM:
--
Do we also need to fix this for files that have broken summaries already? --I
am going to check, but I think that you don't any portion of the file mapped if
the bounds aren't set correctly.-- I checked and you don't get any mappings at
all if the boundaries are not saved.
|[2.2
code|https://github.com/apache/cassandra/compare/apache:cassandra-2.2...aweisberg:CASSANDRA-10511-2.2?expand=1]|[utests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10511-2.2-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10511-2.2-dtest/]|
|[2.1
code|https://github.com/apache/cassandra/compare/apache:cassandra-2.1...aweisberg:CASSANDRA-10511-2.1?expand=1]|[utests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10511-2.1-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10511-2.1-dtest/]|
was (Author: aweisberg):
Do we also need to fix this for files that have broken summaries already? I am
going to check, but I think that you don't any portion of the file mapped if
the bounds aren't set correctly.
|[2.2
code|https://github.com/apache/cassandra/compare/apache:cassandra-2.2...aweisberg:CASSANDRA-10511-2.2?expand=1]|[utests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10511-2.2-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10511-2.2-dtest/]|
|[2.1
code|https://github.com/apache/cassandra/compare/apache:cassandra-2.1...aweisberg:CASSANDRA-10511-2.1?expand=1]|[utests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10511-2.1-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10511-2.1-dtest/]|
> Index summary downsampling prevents mmap access of large files after restart
>
>
> Key: CASSANDRA-10511
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10511
> Project: Cassandra
> Issue Type: Bug
>Reporter: Benedict
>Assignee: Ariel Weisberg
> Fix For: 2.1.x, 2.2.x, 3.1
>
>
> {{SSTableReader.cloneWithNewSummarySampleLevel}} constructs a
> {{SegmentedFile.Builder}} but never populates it with any boundaries. For
> files larger than 2Gb, this will result in their being accessed via buffered
> io after a restart.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10511) Index summary downsampling prevents mmap access of large files after restart
[
https://issues.apache.org/jira/browse/CASSANDRA-10511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14979096#comment-14979096
]
Ariel Weisberg edited comment on CASSANDRA-10511 at 10/28/15 7:38 PM:
--
Do we also need to fix this for files that have broken summaries already? I am
going to check, but I think that you don't any portion of the file mapped if
the bounds aren't set correctly.
|[2.2
code|https://github.com/apache/cassandra/compare/apache:cassandra-2.2...aweisberg:CASSANDRA-10511-2.2?expand=1]|[utests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10511-2.2-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10511-2.2-dtest/]|
|[2.1
code|https://github.com/apache/cassandra/compare/apache:cassandra-2.1...aweisberg:CASSANDRA-10511-2.1?expand=1]|[utests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10511-2.1-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10511-2.1-dtest/]|
was (Author: aweisberg):
Do we need to also fix this for files that have broken summaries already? I am
going to check, but I think that you don't any portion of the file mapped if
the bounds aren't set correctly.
|[2.2
code|https://github.com/apache/cassandra/compare/apache:cassandra-2.2...aweisberg:CASSANDRA-10511-2.2?expand=1]|[utests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10511-2.2-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10511-2.2-dtest/]|
|[2.1
code|https://github.com/apache/cassandra/compare/apache:cassandra-2.1...aweisberg:CASSANDRA-10511-2.1?expand=1]|[utests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10511-2.1-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10511-2.1-dtest/]|
> Index summary downsampling prevents mmap access of large files after restart
>
>
> Key: CASSANDRA-10511
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10511
> Project: Cassandra
> Issue Type: Bug
>Reporter: Benedict
>Assignee: Ariel Weisberg
> Fix For: 2.1.x, 2.2.x, 3.1
>
>
> {{SSTableReader.cloneWithNewSummarySampleLevel}} constructs a
> {{SegmentedFile.Builder}} but never populates it with any boundaries. For
> files larger than 2Gb, this will result in their being accessed via buffered
> io after a restart.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10511) Index summary downsampling prevents mmap access of large files after restart
[
https://issues.apache.org/jira/browse/CASSANDRA-10511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14979096#comment-14979096
]
Ariel Weisberg commented on CASSANDRA-10511:
Do we need to also fix this for files that have broken summaries already? I am
going to check, but I think that you don't any portion of the file mapped if
the bounds aren't set correctly.
|[2.2
code|https://github.com/apache/cassandra/compare/apache:cassandra-2.2...aweisberg:CASSANDRA-10511-2.2?expand=1]|[utests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10511-2.2-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10511-2.2-dtest/]|
|[2.1
code|https://github.com/apache/cassandra/compare/apache:cassandra-2.1...aweisberg:CASSANDRA-10511-2.1?expand=1]|[utests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10511-2.1-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-CASSANDRA-10511-2.1-dtest/]|
> Index summary downsampling prevents mmap access of large files after restart
>
>
> Key: CASSANDRA-10511
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10511
> Project: Cassandra
> Issue Type: Bug
>Reporter: Benedict
>Assignee: Ariel Weisberg
> Fix For: 2.1.x, 2.2.x, 3.1
>
>
> {{SSTableReader.cloneWithNewSummarySampleLevel}} constructs a
> {{SegmentedFile.Builder}} but never populates it with any boundaries. For
> files larger than 2Gb, this will result in their being accessed via buffered
> io after a restart.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[3/3] cassandra git commit: Merge branch 'cassandra-3.0' into trunk
Merge branch 'cassandra-3.0' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0df49539 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0df49539 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0df49539 Branch: refs/heads/trunk Commit: 0df49539fa64672341f86e876849764a41037e47 Parents: a88d3e8 4b47d71 Author: Robert Stupp Authored: Wed Oct 28 20:13:57 2015 +0100 Committer: Robert Stupp Committed: Wed Oct 28 20:13:57 2015 +0100 -- CHANGES.txt | 1 + NEWS.txt| 4 conf/cassandra-env.sh | 23 +--- conf/cassandra.yaml | 13 --- .../org/apache/cassandra/config/Config.java | 3 --- 5 files changed, 15 insertions(+), 29 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/0df49539/CHANGES.txt -- diff --cc CHANGES.txt index 114e2aa,3f2f493..dda3843 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,10 -1,5 +1,11 @@@ +3.2 + * Added graphing option to cassandra-stress (CASSANDRA-7918) + * Abort in-progress queries that time out (CASSANDRA-7392) + * Add transparent data encryption core classes (CASSANDRA-9945) + + 3.0 + * Remove memory_allocator paramter from cassandra.yaml (CASSANDRA-10581) * Execute the metadata reload task of all registered indexes on CFS::reload (CASSANDRA-10604) * Fix thrift cas operations with defined columns (CASSANDRA-10576) * Fix PartitionUpdate.operationCount()for updates with static column operations (CASSANDRA-10606) http://git-wip-us.apache.org/repos/asf/cassandra/blob/0df49539/src/java/org/apache/cassandra/config/Config.java --
[1/3] cassandra git commit: Update cassandra.yaml comments to reflect memory_allocator deprecation, remove in 3.0
Repository: cassandra
Updated Branches:
refs/heads/trunk a88d3e896 -> 0df49539f
Update cassandra.yaml comments to reflect memory_allocator deprecation, remove
in 3.0
patch by Robert Stupp; reviewed by Jim Witschey for CASSANDRA-10581
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/83fcc926
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/83fcc926
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/83fcc926
Branch: refs/heads/trunk
Commit: 83fcc926eb6e5f8667f31dfec3605d7358e0cfd0
Parents: 734a3bf
Author: Robert Stupp
Authored: Wed Oct 28 20:12:25 2015 +0100
Committer: Robert Stupp
Committed: Wed Oct 28 20:12:25 2015 +0100
--
CHANGES.txt | 1 +
NEWS.txt| 3 +++
conf/cassandra-env.sh | 23 +---
conf/cassandra.yaml | 13 ---
.../cassandra/config/DatabaseDescriptor.java| 3 +++
5 files changed, 17 insertions(+), 26 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/83fcc926/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index c4f606f..cc4a8bd 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.2.4
+ * Deprecate memory_allocator in cassandra.yaml (CASSANDRA-10581)
* Expose phi values from failure detector via JMX and tweak debug
and trace logging (CASSANDRA-9526)
* Fix RangeNamesQueryPager (CASSANDRA-10509)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/83fcc926/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index 94567d6..b67814a 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -20,6 +20,9 @@ Deprecation
---
- Pig support has been deprecated, and will be removed in 3.0.
Please see CASSANDRA-10542 for more details.
+- Configuration parameter memory_allocator in cassandra.yaml has been
deprecated
+ and will be removed in 3.0.0. As mentioned below for 2.2.0, jemalloc is
+ automatically preloaded on Unix platforms.
Operations
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/83fcc926/conf/cassandra-env.sh
--
diff --git a/conf/cassandra-env.sh b/conf/cassandra-env.sh
index ca5f17a..bb20964 100644
--- a/conf/cassandra-env.sh
+++ b/conf/cassandra-env.sh
@@ -189,20 +189,22 @@ case "`uname -s`" in
dirs=`echo $dirs | tr " " ":"`
CASSANDRA_LIBJEMALLOC=$(find_library '.*/libjemalloc\.so\(\.1\)*'
$dirs)
fi
-if [ ! -z $CASSANDRA_LIBJEMALLOC ] ; then
-if [ "-" != "$CASSANDRA_LIBJEMALLOC" ] ; then
-export LD_PRELOAD=$CASSANDRA_LIBJEMALLOC
-fi
+if [ ! -z $CASSANDRA_LIBJEMALLOC ] && [ "-" !=
"$CASSANDRA_LIBJEMALLOC" ] ; then
+echo "INFO preloading $CASSANDRA_LIBJEMALLOC"
+export LD_PRELOAD=$CASSANDRA_LIBJEMALLOC
+else
+echo "WARNING could not find libjemalloc.dylib, please install for
better performance - search path: $dirs"
fi
;;
Darwin)
if [ -z $CASSANDRA_LIBJEMALLOC ] ; then
CASSANDRA_LIBJEMALLOC=$(find_library '.*/libjemalloc\.dylib'
$DYLD_LIBRARY_PATH:${DYLD_FALLBACK_LIBRARY_PATH-$HOME/lib:/usr/local/lib:/lib:/usr/lib})
fi
-if [ ! -z $CASSANDRA_LIBJEMALLOC ] ; then
-if [ "-" != "$CASSANDRA_LIBJEMALLOC" ] ; then
-export DYLD_INSERT_LIBRARIES=$CASSANDRA_LIBJEMALLOC
-fi
+if [ ! -z $CASSANDRA_LIBJEMALLOC ] && [ "-" !=
"$CASSANDRA_LIBJEMALLOC" ] ; then
+echo "INFO preloading $CASSANDRA_LIBJEMALLOC"
+export DYLD_INSERT_LIBRARIES=$CASSANDRA_LIBJEMALLOC
+else
+echo "WARNING could not find libjemalloc.dylib, please install for
better performance - search path:
$DYLD_LIBRARY_PATH:${DYLD_FALLBACK_LIBRARY_PATH-$HOME/lib:/usr/local/lib:/lib:/usr/lib}"
fi
;;
esac
@@ -295,11 +297,6 @@ fi
# JVM_OPTS="$JVM_OPTS -XX:NumberOfGCLogFiles=10"
# JVM_OPTS="$JVM_OPTS -XX:GCLogFileSize=10M"
-# Configure the following for JEMallocAllocator and if jemalloc is not
available in the system
-# library path (Example: /usr/local/lib/). Usually "make install" will do the
right thing.
-# export LD_LIBRARY_PATH=/lib/
-# JVM_OPTS="$JVM_OPTS -Djava.library.path=/lib/"
-
# uncomment to have Cassandra JVM listen for remote debuggers/profilers on
port 1414
# JVM_OPTS="$JVM_OPTS
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=1414"
http://git-wip-us.apache.org/repos/asf/cassandra/blob/83fcc926/conf/cassandra.yaml
--
[2/3] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0
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/4b47d711 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/4b47d711 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/4b47d711 Branch: refs/heads/trunk Commit: 4b47d711ec5dd8e9b31679c2810f57503077985a Parents: 8210075 83fcc92 Author: Robert Stupp Authored: Wed Oct 28 20:13:49 2015 +0100 Committer: Robert Stupp Committed: Wed Oct 28 20:13:49 2015 +0100 -- CHANGES.txt | 1 + NEWS.txt| 4 conf/cassandra-env.sh | 23 +--- conf/cassandra.yaml | 13 --- .../org/apache/cassandra/config/Config.java | 3 --- 5 files changed, 15 insertions(+), 29 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/4b47d711/CHANGES.txt -- diff --cc CHANGES.txt index c945bd2,cc4a8bd..3f2f493 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,21 -1,10 +1,22 @@@ -2.2.4 - * Deprecate memory_allocator in cassandra.yaml (CASSANDRA-10581) +3.0 ++ * Remove memory_allocator paramter from cassandra.yaml (CASSANDRA-10581) + * Execute the metadata reload task of all registered indexes on CFS::reload (CASSANDRA-10604) + * Fix thrift cas operations with defined columns (CASSANDRA-10576) + * Fix PartitionUpdate.operationCount()for updates with static column operations (CASSANDRA-10606) + * Fix thrift get() queries with defined columns (CASSANDRA-10586) + * Fix marking of indexes as built and removed (CASSANDRA-10601) + * Skip initialization of non-registered 2i instances, remove Index::getIndexName (CASSANDRA-10595) + * Fix batches on multiple tables (CASSANDRA-10554) + * Ensure compaction options are validated when updating KeyspaceMetadata (CASSANDRA-10569) + * Flatten Iterator Transformation Hierarchy (CASSANDRA-9975) + * Remove token generator (CASSANDRA-5261) + * RolesCache should not be created for any authenticator that does not requireAuthentication (CASSANDRA-10562) + * Fix LogTransaction checking only a single directory for files (CASSANDRA-10421) + * Fix handling of range tombstones when reading old format sstables (CASSANDRA-10360) + * Aggregate with Initial Condition fails with C* 3.0 (CASSANDRA-10367) +Merged from 2.2: * Expose phi values from failure detector via JMX and tweak debug and trace logging (CASSANDRA-9526) - * Fix RangeNamesQueryPager (CASSANDRA-10509) - * Deprecate Pig support (CASSANDRA-10542) - * Reduce contention getting instances of CompositeType (CASSANDRA-10433) Merged from 2.1: * Support encrypted and plain traffic on the same port (CASSANDRA-10559) * Do STCS in DTCS windows (CASSANDRA-10276) http://git-wip-us.apache.org/repos/asf/cassandra/blob/4b47d711/NEWS.txt -- diff --cc NEWS.txt index dd20970,b67814a..aa19fcb --- a/NEWS.txt +++ b/NEWS.txt @@@ -13,110 -13,6 +13,111 @@@ restore snapshots created with the prev 'sstableloader' tool. You can upgrade the file format of your snapshots using the provided 'sstableupgrade' tool. +3.0 +=== + +New features + + - EACH_QUORUM is now a supported consistency level for read requests. + - Support for IN restrictions on any partition key component or clustering key + as well as support for EQ and IN multicolumn restrictions has been added to + UPDATE and DELETE statement. + - Support for single-column and multi-colum slice restrictions (>, >=, <= and <) + has been added to DELETE statements + - nodetool rebuild_index accepts the index argument without + the redundant table name + - Materialized Views, which allow for server-side denormalization, is now + available. Materialized views provide an alternative to secondary indexes + for non-primary key queries, and perform much better for indexing high + cardinality columns. + See http://www.datastax.com/dev/blog/new-in-cassandra-3-0-materialized-views + - Hinted handoff has been completely rewritten. Hints are now stored in flat + files, with less overhead for storage and more efficient dispatch. + See CASSANDRA-6230 for full details. + - Option to not purge unrepaired tombstones. To avoid users having data resurrected + if repair has not been run within gc_grace_seconds, an option has been added to + only allow tombstones from repaired sstables to be purged. To enable, set the + compaction option 'only_purge_repaired_tombstones':true but keep in mind that if + you do not run repair for a long time, you will keep all tombston
[1/2] cassandra git commit: Update cassandra.yaml comments to reflect memory_allocator deprecation, remove in 3.0
Repository: cassandra
Updated Branches:
refs/heads/cassandra-3.0 8210075c5 -> 4b47d711e
Update cassandra.yaml comments to reflect memory_allocator deprecation, remove
in 3.0
patch by Robert Stupp; reviewed by Jim Witschey for CASSANDRA-10581
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/83fcc926
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/83fcc926
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/83fcc926
Branch: refs/heads/cassandra-3.0
Commit: 83fcc926eb6e5f8667f31dfec3605d7358e0cfd0
Parents: 734a3bf
Author: Robert Stupp
Authored: Wed Oct 28 20:12:25 2015 +0100
Committer: Robert Stupp
Committed: Wed Oct 28 20:12:25 2015 +0100
--
CHANGES.txt | 1 +
NEWS.txt| 3 +++
conf/cassandra-env.sh | 23 +---
conf/cassandra.yaml | 13 ---
.../cassandra/config/DatabaseDescriptor.java| 3 +++
5 files changed, 17 insertions(+), 26 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/83fcc926/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index c4f606f..cc4a8bd 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.2.4
+ * Deprecate memory_allocator in cassandra.yaml (CASSANDRA-10581)
* Expose phi values from failure detector via JMX and tweak debug
and trace logging (CASSANDRA-9526)
* Fix RangeNamesQueryPager (CASSANDRA-10509)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/83fcc926/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index 94567d6..b67814a 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -20,6 +20,9 @@ Deprecation
---
- Pig support has been deprecated, and will be removed in 3.0.
Please see CASSANDRA-10542 for more details.
+- Configuration parameter memory_allocator in cassandra.yaml has been
deprecated
+ and will be removed in 3.0.0. As mentioned below for 2.2.0, jemalloc is
+ automatically preloaded on Unix platforms.
Operations
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/83fcc926/conf/cassandra-env.sh
--
diff --git a/conf/cassandra-env.sh b/conf/cassandra-env.sh
index ca5f17a..bb20964 100644
--- a/conf/cassandra-env.sh
+++ b/conf/cassandra-env.sh
@@ -189,20 +189,22 @@ case "`uname -s`" in
dirs=`echo $dirs | tr " " ":"`
CASSANDRA_LIBJEMALLOC=$(find_library '.*/libjemalloc\.so\(\.1\)*'
$dirs)
fi
-if [ ! -z $CASSANDRA_LIBJEMALLOC ] ; then
-if [ "-" != "$CASSANDRA_LIBJEMALLOC" ] ; then
-export LD_PRELOAD=$CASSANDRA_LIBJEMALLOC
-fi
+if [ ! -z $CASSANDRA_LIBJEMALLOC ] && [ "-" !=
"$CASSANDRA_LIBJEMALLOC" ] ; then
+echo "INFO preloading $CASSANDRA_LIBJEMALLOC"
+export LD_PRELOAD=$CASSANDRA_LIBJEMALLOC
+else
+echo "WARNING could not find libjemalloc.dylib, please install for
better performance - search path: $dirs"
fi
;;
Darwin)
if [ -z $CASSANDRA_LIBJEMALLOC ] ; then
CASSANDRA_LIBJEMALLOC=$(find_library '.*/libjemalloc\.dylib'
$DYLD_LIBRARY_PATH:${DYLD_FALLBACK_LIBRARY_PATH-$HOME/lib:/usr/local/lib:/lib:/usr/lib})
fi
-if [ ! -z $CASSANDRA_LIBJEMALLOC ] ; then
-if [ "-" != "$CASSANDRA_LIBJEMALLOC" ] ; then
-export DYLD_INSERT_LIBRARIES=$CASSANDRA_LIBJEMALLOC
-fi
+if [ ! -z $CASSANDRA_LIBJEMALLOC ] && [ "-" !=
"$CASSANDRA_LIBJEMALLOC" ] ; then
+echo "INFO preloading $CASSANDRA_LIBJEMALLOC"
+export DYLD_INSERT_LIBRARIES=$CASSANDRA_LIBJEMALLOC
+else
+echo "WARNING could not find libjemalloc.dylib, please install for
better performance - search path:
$DYLD_LIBRARY_PATH:${DYLD_FALLBACK_LIBRARY_PATH-$HOME/lib:/usr/local/lib:/lib:/usr/lib}"
fi
;;
esac
@@ -295,11 +297,6 @@ fi
# JVM_OPTS="$JVM_OPTS -XX:NumberOfGCLogFiles=10"
# JVM_OPTS="$JVM_OPTS -XX:GCLogFileSize=10M"
-# Configure the following for JEMallocAllocator and if jemalloc is not
available in the system
-# library path (Example: /usr/local/lib/). Usually "make install" will do the
right thing.
-# export LD_LIBRARY_PATH=/lib/
-# JVM_OPTS="$JVM_OPTS -Djava.library.path=/lib/"
-
# uncomment to have Cassandra JVM listen for remote debuggers/profilers on
port 1414
# JVM_OPTS="$JVM_OPTS
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=1414"
http://git-wip-us.apache.org/repos/asf/cassandra/blob/83fcc926/conf/cassandra.yaml
--
[2/2] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0
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/4b47d711 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/4b47d711 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/4b47d711 Branch: refs/heads/cassandra-3.0 Commit: 4b47d711ec5dd8e9b31679c2810f57503077985a Parents: 8210075 83fcc92 Author: Robert Stupp Authored: Wed Oct 28 20:13:49 2015 +0100 Committer: Robert Stupp Committed: Wed Oct 28 20:13:49 2015 +0100 -- CHANGES.txt | 1 + NEWS.txt| 4 conf/cassandra-env.sh | 23 +--- conf/cassandra.yaml | 13 --- .../org/apache/cassandra/config/Config.java | 3 --- 5 files changed, 15 insertions(+), 29 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/4b47d711/CHANGES.txt -- diff --cc CHANGES.txt index c945bd2,cc4a8bd..3f2f493 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,21 -1,10 +1,22 @@@ -2.2.4 - * Deprecate memory_allocator in cassandra.yaml (CASSANDRA-10581) +3.0 ++ * Remove memory_allocator paramter from cassandra.yaml (CASSANDRA-10581) + * Execute the metadata reload task of all registered indexes on CFS::reload (CASSANDRA-10604) + * Fix thrift cas operations with defined columns (CASSANDRA-10576) + * Fix PartitionUpdate.operationCount()for updates with static column operations (CASSANDRA-10606) + * Fix thrift get() queries with defined columns (CASSANDRA-10586) + * Fix marking of indexes as built and removed (CASSANDRA-10601) + * Skip initialization of non-registered 2i instances, remove Index::getIndexName (CASSANDRA-10595) + * Fix batches on multiple tables (CASSANDRA-10554) + * Ensure compaction options are validated when updating KeyspaceMetadata (CASSANDRA-10569) + * Flatten Iterator Transformation Hierarchy (CASSANDRA-9975) + * Remove token generator (CASSANDRA-5261) + * RolesCache should not be created for any authenticator that does not requireAuthentication (CASSANDRA-10562) + * Fix LogTransaction checking only a single directory for files (CASSANDRA-10421) + * Fix handling of range tombstones when reading old format sstables (CASSANDRA-10360) + * Aggregate with Initial Condition fails with C* 3.0 (CASSANDRA-10367) +Merged from 2.2: * Expose phi values from failure detector via JMX and tweak debug and trace logging (CASSANDRA-9526) - * Fix RangeNamesQueryPager (CASSANDRA-10509) - * Deprecate Pig support (CASSANDRA-10542) - * Reduce contention getting instances of CompositeType (CASSANDRA-10433) Merged from 2.1: * Support encrypted and plain traffic on the same port (CASSANDRA-10559) * Do STCS in DTCS windows (CASSANDRA-10276) http://git-wip-us.apache.org/repos/asf/cassandra/blob/4b47d711/NEWS.txt -- diff --cc NEWS.txt index dd20970,b67814a..aa19fcb --- a/NEWS.txt +++ b/NEWS.txt @@@ -13,110 -13,6 +13,111 @@@ restore snapshots created with the prev 'sstableloader' tool. You can upgrade the file format of your snapshots using the provided 'sstableupgrade' tool. +3.0 +=== + +New features + + - EACH_QUORUM is now a supported consistency level for read requests. + - Support for IN restrictions on any partition key component or clustering key + as well as support for EQ and IN multicolumn restrictions has been added to + UPDATE and DELETE statement. + - Support for single-column and multi-colum slice restrictions (>, >=, <= and <) + has been added to DELETE statements + - nodetool rebuild_index accepts the index argument without + the redundant table name + - Materialized Views, which allow for server-side denormalization, is now + available. Materialized views provide an alternative to secondary indexes + for non-primary key queries, and perform much better for indexing high + cardinality columns. + See http://www.datastax.com/dev/blog/new-in-cassandra-3-0-materialized-views + - Hinted handoff has been completely rewritten. Hints are now stored in flat + files, with less overhead for storage and more efficient dispatch. + See CASSANDRA-6230 for full details. + - Option to not purge unrepaired tombstones. To avoid users having data resurrected + if repair has not been run within gc_grace_seconds, an option has been added to + only allow tombstones from repaired sstables to be purged. To enable, set the + compaction option 'only_purge_repaired_tombstones':true but keep in mind that if + you do not run repair for a long time, you will keep all
cassandra git commit: Update cassandra.yaml comments to reflect memory_allocator deprecation, remove in 3.0
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.2 734a3bfa7 -> 83fcc926e
Update cassandra.yaml comments to reflect memory_allocator deprecation, remove
in 3.0
patch by Robert Stupp; reviewed by Jim Witschey for CASSANDRA-10581
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/83fcc926
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/83fcc926
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/83fcc926
Branch: refs/heads/cassandra-2.2
Commit: 83fcc926eb6e5f8667f31dfec3605d7358e0cfd0
Parents: 734a3bf
Author: Robert Stupp
Authored: Wed Oct 28 20:12:25 2015 +0100
Committer: Robert Stupp
Committed: Wed Oct 28 20:12:25 2015 +0100
--
CHANGES.txt | 1 +
NEWS.txt| 3 +++
conf/cassandra-env.sh | 23 +---
conf/cassandra.yaml | 13 ---
.../cassandra/config/DatabaseDescriptor.java| 3 +++
5 files changed, 17 insertions(+), 26 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/83fcc926/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index c4f606f..cc4a8bd 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.2.4
+ * Deprecate memory_allocator in cassandra.yaml (CASSANDRA-10581)
* Expose phi values from failure detector via JMX and tweak debug
and trace logging (CASSANDRA-9526)
* Fix RangeNamesQueryPager (CASSANDRA-10509)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/83fcc926/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index 94567d6..b67814a 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -20,6 +20,9 @@ Deprecation
---
- Pig support has been deprecated, and will be removed in 3.0.
Please see CASSANDRA-10542 for more details.
+- Configuration parameter memory_allocator in cassandra.yaml has been
deprecated
+ and will be removed in 3.0.0. As mentioned below for 2.2.0, jemalloc is
+ automatically preloaded on Unix platforms.
Operations
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/83fcc926/conf/cassandra-env.sh
--
diff --git a/conf/cassandra-env.sh b/conf/cassandra-env.sh
index ca5f17a..bb20964 100644
--- a/conf/cassandra-env.sh
+++ b/conf/cassandra-env.sh
@@ -189,20 +189,22 @@ case "`uname -s`" in
dirs=`echo $dirs | tr " " ":"`
CASSANDRA_LIBJEMALLOC=$(find_library '.*/libjemalloc\.so\(\.1\)*'
$dirs)
fi
-if [ ! -z $CASSANDRA_LIBJEMALLOC ] ; then
-if [ "-" != "$CASSANDRA_LIBJEMALLOC" ] ; then
-export LD_PRELOAD=$CASSANDRA_LIBJEMALLOC
-fi
+if [ ! -z $CASSANDRA_LIBJEMALLOC ] && [ "-" !=
"$CASSANDRA_LIBJEMALLOC" ] ; then
+echo "INFO preloading $CASSANDRA_LIBJEMALLOC"
+export LD_PRELOAD=$CASSANDRA_LIBJEMALLOC
+else
+echo "WARNING could not find libjemalloc.dylib, please install for
better performance - search path: $dirs"
fi
;;
Darwin)
if [ -z $CASSANDRA_LIBJEMALLOC ] ; then
CASSANDRA_LIBJEMALLOC=$(find_library '.*/libjemalloc\.dylib'
$DYLD_LIBRARY_PATH:${DYLD_FALLBACK_LIBRARY_PATH-$HOME/lib:/usr/local/lib:/lib:/usr/lib})
fi
-if [ ! -z $CASSANDRA_LIBJEMALLOC ] ; then
-if [ "-" != "$CASSANDRA_LIBJEMALLOC" ] ; then
-export DYLD_INSERT_LIBRARIES=$CASSANDRA_LIBJEMALLOC
-fi
+if [ ! -z $CASSANDRA_LIBJEMALLOC ] && [ "-" !=
"$CASSANDRA_LIBJEMALLOC" ] ; then
+echo "INFO preloading $CASSANDRA_LIBJEMALLOC"
+export DYLD_INSERT_LIBRARIES=$CASSANDRA_LIBJEMALLOC
+else
+echo "WARNING could not find libjemalloc.dylib, please install for
better performance - search path:
$DYLD_LIBRARY_PATH:${DYLD_FALLBACK_LIBRARY_PATH-$HOME/lib:/usr/local/lib:/lib:/usr/lib}"
fi
;;
esac
@@ -295,11 +297,6 @@ fi
# JVM_OPTS="$JVM_OPTS -XX:NumberOfGCLogFiles=10"
# JVM_OPTS="$JVM_OPTS -XX:GCLogFileSize=10M"
-# Configure the following for JEMallocAllocator and if jemalloc is not
available in the system
-# library path (Example: /usr/local/lib/). Usually "make install" will do the
right thing.
-# export LD_LIBRARY_PATH=/lib/
-# JVM_OPTS="$JVM_OPTS -Djava.library.path=/lib/"
-
# uncomment to have Cassandra JVM listen for remote debuggers/profilers on
port 1414
# JVM_OPTS="$JVM_OPTS
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=1414"
http://git-wip-us.apache.org/repos/asf/cassandra/blob/83fcc926/conf/cassandra.yaml
--
[jira] [Assigned] (CASSANDRA-10512) We do not save an upsampled index summaries
[ https://issues.apache.org/jira/browse/CASSANDRA-10512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg reassigned CASSANDRA-10512: -- Assignee: Ariel Weisberg > We do not save an upsampled index summaries > --- > > Key: CASSANDRA-10512 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10512 > Project: Cassandra > Issue Type: Bug >Reporter: Benedict >Assignee: Ariel Weisberg > Fix For: 2.1.x, 2.2.x, 3.1 > > > If we downsample an index summary, we overwrite the existing summary, despite > downsampling being inexpensive. However on upsampling (which is expensive) we > do not, so that on restart all of our index summaries are the smallest they > have ever been adjusted to. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10581) Update cassandra.yaml comments to reflect memory_allocator deprecation, remove in 3.0
[
https://issues.apache.org/jira/browse/CASSANDRA-10581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14979047#comment-14979047
]
Jim Witschey commented on CASSANDRA-10581:
--
Yep, that's about what I had in mind, if that's the best visibility we can get.
I'm +1.
> Update cassandra.yaml comments to reflect memory_allocator deprecation,
> remove in 3.0
> -
>
> Key: CASSANDRA-10581
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10581
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jim Witschey
>Assignee: Robert Stupp
> Fix For: 2.2.x, 3.0.0
>
>
> Looks like in 2.2+ changing the {{memory_allocator}} field in cassandra.yaml
> has no effect:
> https://github.com/apache/cassandra/commit/0d2ec11c7e0abfb84d872289af6d3ac386cf381f#diff-b66584c9ce7b64019b5db5a531deeda1R207
> The instructions in comments on how to use jemalloc haven't been updated to
> reflect this change. [~snazy], is that an accurate assessment?
> [~iamaleksey] How do we want to handle the deprecation more generally? Warn
> on 2.2, remove in 3.0?
> EDIT: I described this in a way that isn't very clear to those unfamiliar
> with Robert's change. To be clear: You can still use JEMAlloc with Cassandra.
> The {{memory_allocator}} option was deprecated in favor of automatically
> detecting if JEMAlloc is installed, and, if so, using it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10581) Update cassandra.yaml comments to reflect memory_allocator deprecation, remove in 3.0
[
https://issues.apache.org/jira/browse/CASSANDRA-10581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14979027#comment-14979027
]
Robert Stupp commented on CASSANDRA-10581:
--
Yes, it's difficult to include a check whether jemalloc is actually used. The
startup code in {{cassandra-env.sh}} preloads the library, which effectively
"links" jemalloc between the java runtime and OS {{malloc}}/{{free}} - i.e.
it's basically "invisible" whether jemalloc is used or not.
I've pushed commits for 2.2 + 3.0 with some logging to {{cassandra-env.sh}}
where preloading happens. Is this what you think of?
> Update cassandra.yaml comments to reflect memory_allocator deprecation,
> remove in 3.0
> -
>
> Key: CASSANDRA-10581
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10581
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jim Witschey
>Assignee: Robert Stupp
> Fix For: 2.2.x, 3.0.0
>
>
> Looks like in 2.2+ changing the {{memory_allocator}} field in cassandra.yaml
> has no effect:
> https://github.com/apache/cassandra/commit/0d2ec11c7e0abfb84d872289af6d3ac386cf381f#diff-b66584c9ce7b64019b5db5a531deeda1R207
> The instructions in comments on how to use jemalloc haven't been updated to
> reflect this change. [~snazy], is that an accurate assessment?
> [~iamaleksey] How do we want to handle the deprecation more generally? Warn
> on 2.2, remove in 3.0?
> EDIT: I described this in a way that isn't very clear to those unfamiliar
> with Robert's change. To be clear: You can still use JEMAlloc with Cassandra.
> The {{memory_allocator}} option was deprecated in favor of automatically
> detecting if JEMAlloc is installed, and, if so, using it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10608) Adding a dynamic column to a compact storage table with the same name as the partition key causes a memtable flush deadlock
[
https://issues.apache.org/jira/browse/CASSANDRA-10608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14978995#comment-14978995
]
T Jake Luciani commented on CASSANDRA-10608:
The change itself looks fine. Do you have a dtest/utest run on cassci you can
link?
> Adding a dynamic column to a compact storage table with the same name as the
> partition key causes a memtable flush deadlock
> ---
>
> Key: CASSANDRA-10608
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10608
> Project: Cassandra
> Issue Type: Bug
>Reporter: Mike Adamson
>Assignee: Mike Adamson
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: 10608.txt
>
>
> The reproduction steps for this are as follows:
> # Create the following schema:
> {noformat}
> CREATE KEYSPACE ks WITH replication = { 'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> CREATE TABLE ks.cf (k int, v int, PRIMARY KEY(k)) WITH COMPACT STORAGE;
> {noformat}
> # Using the thrift client execute the following:
> {noformat}
> Column column = new Column(ByteBufferUtil.bytes("k"));
> column.setValue(ByteBufferUtil.bytes(1));
> column.setTimestamp(1);
> client.insert(key, new ColumnParent(compactCf), column,
> ConsistencyLevel.ONE);
> {noformat}
> This causes an invalid {{PartitionUpdate}} to be added to {{Memtable}}
> containing a {{PartitionColumns}} containing the partition key
> {{ColumnDefinition}}.
> This happens because {{LegacyLayout.decodeCellName}} does not check whether
> the {{ColumnDefinition}} is a partition key
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-10517) Make sure all unit tests run on CassCI
[ https://issues.apache.org/jira/browse/CASSANDRA-10517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Knighton resolved CASSANDRA-10517. --- Resolution: Won't Fix > Make sure all unit tests run on CassCI > -- > > Key: CASSANDRA-10517 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10517 > Project: Cassandra > Issue Type: Sub-task >Reporter: Jim Witschey >Assignee: Joel Knighton > Labels: triage > Fix For: 3.0.0 > > > It seems that some Windows unit tests aren't run sometimes on CassCI, and > there's no error reporting for this. For instance, this test was introduced > around the time build #38 would have happened, but has only run in builds > #50-3 and #64: > http://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_utest_win32/lastCompletedBuild/testReport/org.apache.cassandra.cql3/ViewTest/testPrimaryKeyIsNotNull/history/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8927) Mark libjna-java + libjna-jni as incompatible in debian package
[
https://issues.apache.org/jira/browse/CASSANDRA-8927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14978967#comment-14978967
]
Robert Stupp commented on CASSANDRA-8927:
-
ping [~mshuler]
> Mark libjna-java + libjna-jni as incompatible in debian package
> ---
>
> Key: CASSANDRA-8927
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8927
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
> Environment: Debian
>Reporter: Robert Stupp
>Assignee: Michael Shuler
> Fix For: 2.1.x
>
>
> Current Debian (Wheezy) might bring {{libjna-java}} in version 3.2.7-4, which
> has incompatible {{libjnadispatch.so}} because since C* 2.1 we use JNA 4.0.0
> (the native stuff changed):
> jna.jar includes all binaries for all supported platforms - so there's no
> need for libjna installed separately.
> Since CASSANDRA-8714 has been committed, the incompatibility manifests in
> {{java.lang.NoClassDefFoundError: Could not initialize class
> com.sun.jna.Native}} (which is caused by outdated libjna-java installed via
> apt).
> Note: Debian jessie adds new package {{libjna-jni}} (4.1.0-1) in addition to
> {{libjna-java}} (4.1.0-1) - both contain the {{libjnidispatch.so}}. Although
> these seem to work, we might hit the same issue when there's a need to
> upgrade JNA to 4.2.x sometime.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-4782) Commitlog not replayed after restart
[ https://issues.apache.org/jira/browse/CASSANDRA-4782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14978905#comment-14978905 ] Robert Coli commented on CASSANDRA-4782: [~htoulan] : 1) JIRA is not a support forum, generally. You would get a better response from the #cassandra IRC channel on freenode or the cassandra-user@ mailing list. 2) Cassandra 1.1.0 is an extremely old and extremely broken version. You should update to at least the final released version of the 1.1 line. Much better would be (first 1.2.x and then) at least the most recent 2.0.x version. 3) No commit log replay bug, including this one, should be capable of losing data if you write with a sufficient ConsistencyLevel and Replication Factor and repair regularly. > Commitlog not replayed after restart > > > Key: CASSANDRA-4782 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4782 > Project: Cassandra > Issue Type: Bug >Affects Versions: 1.1.0 >Reporter: Fabien Rousseau >Assignee: Jonathan Ellis >Priority: Critical > Fix For: 1.1.6 > > Attachments: 4782.txt > > > It seems that there are two corner cases where commitlog is not replayed > after a restart : > - After a reboot of a server + restart of cassandra (1.1.0 to 1.1.4) > - After doing an upgrade from cassandra 1.1.X to cassandra 1.1.5 > This is due to the fact that the commitlog segment id should always be an > incrementing number (see this condition : > https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLogReplayer.java#L247 > ) > But this assertion can be broken : > In the first case, it is generated by System.nanoTime() but it seems that > System.nanoTime() is using the boot time as the base/reference (at least on > java6 & linux), thus after a reboot, System.nanoTime() can return a lower > number than before the reboot (and the javadoc says the reference is a > relative point in time...) > In the second case, this was introduced by #4601 (which changes > System.nanoTime() by System.currentTimeMillis() thus people starting with > 1.1.5 are safe) > This could explain the following tickets : #4741 and #4481 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[1/3] cassandra git commit: On CFS::reload, execute the reload task for each secondary index
Repository: cassandra
Updated Branches:
refs/heads/cassandra-3.0 5034f4495 -> 8210075c5
refs/heads/trunk 74ee6684c -> a88d3e896
On CFS::reload, execute the reload task for each secondary index
Patch by Sam Tunnicliffe; reviewed by Tyler Hobbs for CASSANDRA-10604
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/8210075c
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/8210075c
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/8210075c
Branch: refs/heads/cassandra-3.0
Commit: 8210075c57af696e78000e8cd0019737b2373875
Parents: 5034f44
Author: Sam Tunnicliffe
Authored: Wed Oct 28 13:16:15 2015 +
Committer: Sam Tunnicliffe
Committed: Wed Oct 28 17:23:57 2015 +
--
CHANGES.txt | 1 +
src/java/org/apache/cassandra/index/Index.java | 11 ++
.../cassandra/index/SecondaryIndexManager.java | 16 +++-
.../index/internal/CassandraIndex.java | 1 -
.../apache/cassandra/index/CustomIndexTest.java | 40
.../index/internal/CassandraIndexTest.java | 9 +
6 files changed, 66 insertions(+), 12 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/8210075c/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 4ead854..c945bd2 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
3.0
+ * Execute the metadata reload task of all registered indexes on CFS::reload
(CASSANDRA-10604)
* Fix thrift cas operations with defined columns (CASSANDRA-10576)
* Fix PartitionUpdate.operationCount()for updates with static column
operations (CASSANDRA-10606)
* Fix thrift get() queries with defined columns (CASSANDRA-10586)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/8210075c/src/java/org/apache/cassandra/index/Index.java
--
diff --git a/src/java/org/apache/cassandra/index/Index.java
b/src/java/org/apache/cassandra/index/Index.java
index 0f4ecbd..b6c12a9 100644
--- a/src/java/org/apache/cassandra/index/Index.java
+++ b/src/java/org/apache/cassandra/index/Index.java
@@ -296,9 +296,20 @@ public interface Index
* Listener for processing events emitted during a single partition update.
* Instances of this are responsible for applying modifications to the
index in response to a single update
* operation on a particular partition of the base table.
+ *
* That update may be generated by the normal write path, by iterating
SSTables during streaming operations or when
* building or rebuilding an index from source. Updates also occur during
compaction when multiple versions of a
* source partition from different SSTables are merged.
+ *
+ * Implementations should not make assumptions about resolution or
filtering of the partition update being
+ * processed. That is to say that it is possible for an Indexer instance
to receive notification of a
+ * PartitionDelete or RangeTombstones which shadow a Row it then receives
via insertRow/updateRow.
+ *
+ * It is important to note that the only ordering guarantee made for the
methods here is that the first call will
+ * be to begin() and the last call to finish(). The other methods may be
called to process update events in any
+ * order. This can also include duplicate calls, in cases where a memtable
partition is under contention from
+ * several updates. In that scenario, the same set of events may be
delivered to the Indexer as memtable update
+ * which failed due to contention is re-applied.
*/
public interface Indexer
{
http://git-wip-us.apache.org/repos/asf/cassandra/blob/8210075c/src/java/org/apache/cassandra/index/SecondaryIndexManager.java
--
diff --git a/src/java/org/apache/cassandra/index/SecondaryIndexManager.java
b/src/java/org/apache/cassandra/index/SecondaryIndexManager.java
index 3ed9714..92b04fe 100644
--- a/src/java/org/apache/cassandra/index/SecondaryIndexManager.java
+++ b/src/java/org/apache/cassandra/index/SecondaryIndexManager.java
@@ -142,17 +142,11 @@ public class SecondaryIndexManager implements
IndexRegistry
private Future reloadIndex(IndexMetadata indexDef)
{
-// if the index metadata has changed, reload the index
-IndexMetadata registered =
indexes.get(indexDef.name).getIndexMetadata();
-if (!registered.equals(indexDef))
-{
-Index index = indexes.remove(registered.name);
-index.register(this);
-return
blockingExecutor.submit(index.getMetadataReloadTask(indexDef));
-}
-
-// otherwise, nothing to do
[3/3] cassandra git commit: Merge branch 'cassandra-3.0' into trunk
Merge branch 'cassandra-3.0' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/a88d3e89 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a88d3e89 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a88d3e89 Branch: refs/heads/trunk Commit: a88d3e89628df6fb9e6ff3332c546d92168284f1 Parents: 74ee668 8210075 Author: Sam Tunnicliffe Authored: Wed Oct 28 17:26:43 2015 + Committer: Sam Tunnicliffe Committed: Wed Oct 28 17:26:43 2015 + -- CHANGES.txt | 1 + src/java/org/apache/cassandra/index/Index.java | 11 ++ .../cassandra/index/SecondaryIndexManager.java | 16 +++- .../index/internal/CassandraIndex.java | 1 - .../apache/cassandra/index/CustomIndexTest.java | 40 .../index/internal/CassandraIndexTest.java | 9 + 6 files changed, 66 insertions(+), 12 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/a88d3e89/CHANGES.txt -- diff --cc CHANGES.txt index 1b6ede7,c945bd2..114e2aa --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,10 -1,5 +1,11 @@@ +3.2 + * Added graphing option to cassandra-stress (CASSANDRA-7918) + * Abort in-progress queries that time out (CASSANDRA-7392) + * Add transparent data encryption core classes (CASSANDRA-9945) + + 3.0 + * Execute the metadata reload task of all registered indexes on CFS::reload (CASSANDRA-10604) * Fix thrift cas operations with defined columns (CASSANDRA-10576) * Fix PartitionUpdate.operationCount()for updates with static column operations (CASSANDRA-10606) * Fix thrift get() queries with defined columns (CASSANDRA-10586) http://git-wip-us.apache.org/repos/asf/cassandra/blob/a88d3e89/src/java/org/apache/cassandra/index/Index.java -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/a88d3e89/test/unit/org/apache/cassandra/index/internal/CassandraIndexTest.java --
[2/3] cassandra git commit: On CFS::reload, execute the reload task for each secondary index
On CFS::reload, execute the reload task for each secondary index
Patch by Sam Tunnicliffe; reviewed by Tyler Hobbs for CASSANDRA-10604
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/8210075c
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/8210075c
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/8210075c
Branch: refs/heads/trunk
Commit: 8210075c57af696e78000e8cd0019737b2373875
Parents: 5034f44
Author: Sam Tunnicliffe
Authored: Wed Oct 28 13:16:15 2015 +
Committer: Sam Tunnicliffe
Committed: Wed Oct 28 17:23:57 2015 +
--
CHANGES.txt | 1 +
src/java/org/apache/cassandra/index/Index.java | 11 ++
.../cassandra/index/SecondaryIndexManager.java | 16 +++-
.../index/internal/CassandraIndex.java | 1 -
.../apache/cassandra/index/CustomIndexTest.java | 40
.../index/internal/CassandraIndexTest.java | 9 +
6 files changed, 66 insertions(+), 12 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/8210075c/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 4ead854..c945bd2 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
3.0
+ * Execute the metadata reload task of all registered indexes on CFS::reload
(CASSANDRA-10604)
* Fix thrift cas operations with defined columns (CASSANDRA-10576)
* Fix PartitionUpdate.operationCount()for updates with static column
operations (CASSANDRA-10606)
* Fix thrift get() queries with defined columns (CASSANDRA-10586)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/8210075c/src/java/org/apache/cassandra/index/Index.java
--
diff --git a/src/java/org/apache/cassandra/index/Index.java
b/src/java/org/apache/cassandra/index/Index.java
index 0f4ecbd..b6c12a9 100644
--- a/src/java/org/apache/cassandra/index/Index.java
+++ b/src/java/org/apache/cassandra/index/Index.java
@@ -296,9 +296,20 @@ public interface Index
* Listener for processing events emitted during a single partition update.
* Instances of this are responsible for applying modifications to the
index in response to a single update
* operation on a particular partition of the base table.
+ *
* That update may be generated by the normal write path, by iterating
SSTables during streaming operations or when
* building or rebuilding an index from source. Updates also occur during
compaction when multiple versions of a
* source partition from different SSTables are merged.
+ *
+ * Implementations should not make assumptions about resolution or
filtering of the partition update being
+ * processed. That is to say that it is possible for an Indexer instance
to receive notification of a
+ * PartitionDelete or RangeTombstones which shadow a Row it then receives
via insertRow/updateRow.
+ *
+ * It is important to note that the only ordering guarantee made for the
methods here is that the first call will
+ * be to begin() and the last call to finish(). The other methods may be
called to process update events in any
+ * order. This can also include duplicate calls, in cases where a memtable
partition is under contention from
+ * several updates. In that scenario, the same set of events may be
delivered to the Indexer as memtable update
+ * which failed due to contention is re-applied.
*/
public interface Indexer
{
http://git-wip-us.apache.org/repos/asf/cassandra/blob/8210075c/src/java/org/apache/cassandra/index/SecondaryIndexManager.java
--
diff --git a/src/java/org/apache/cassandra/index/SecondaryIndexManager.java
b/src/java/org/apache/cassandra/index/SecondaryIndexManager.java
index 3ed9714..92b04fe 100644
--- a/src/java/org/apache/cassandra/index/SecondaryIndexManager.java
+++ b/src/java/org/apache/cassandra/index/SecondaryIndexManager.java
@@ -142,17 +142,11 @@ public class SecondaryIndexManager implements
IndexRegistry
private Future reloadIndex(IndexMetadata indexDef)
{
-// if the index metadata has changed, reload the index
-IndexMetadata registered =
indexes.get(indexDef.name).getIndexMetadata();
-if (!registered.equals(indexDef))
-{
-Index index = indexes.remove(registered.name);
-index.register(this);
-return
blockingExecutor.submit(index.getMetadataReloadTask(indexDef));
-}
-
-// otherwise, nothing to do
-return Futures.immediateFuture(null);
+Index index = indexes.get(indexDef.name);
+Callable reloadTask = index.getMeta
[jira] [Commented] (CASSANDRA-10511) Index summary downsampling prevents mmap access of large files after restart
[
https://issues.apache.org/jira/browse/CASSANDRA-10511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14978827#comment-14978827
]
Ariel Weisberg commented on CASSANDRA-10511:
I noticed that
[SSTableReader.load()|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java#L725]
can rebuild the index summary if it fails to load due to an exception. However
it doesn't reconstruct the ibuilder and dbuilder which may be partially
populated with readable boundaries from the fail index summary load. Kind of
looks like a bug.
Fix for this looks straightforward. Extract the readable boundaries from the
ifile and dfile segments and provide them to the SegmentedFile.Builders that
are being used to downsample the summary. Working on a test now.
> Index summary downsampling prevents mmap access of large files after restart
>
>
> Key: CASSANDRA-10511
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10511
> Project: Cassandra
> Issue Type: Bug
>Reporter: Benedict
>Assignee: Ariel Weisberg
> Fix For: 2.1.x, 2.2.x, 3.1
>
>
> {{SSTableReader.cloneWithNewSummarySampleLevel}} constructs a
> {{SegmentedFile.Builder}} but never populates it with any boundaries. For
> files larger than 2Gb, this will result in their being accessed via buffered
> io after a restart.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10070) Automatic repair scheduling
[ https://issues.apache.org/jira/browse/CASSANDRA-10070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14978802#comment-14978802 ] Avinash Mandava commented on CASSANDRA-10070: - Right now streaming between Cassandra versions isn't recommended, but I'm wondering how we would upgrade to a new version with automatic repairs running. If I'm doing a rolling upgrade, right now I have to stop the repair process to prevent streaming between nodes and then upgrade, and then resume the repair process. But if we are thinking of including automatic repairs, might it be valuable to allow people to keep the repair process going while they upgrade? I can see how an upgrade is infrequent enough for this suggestion to be overkill, but curious what people think. > Automatic repair scheduling > --- > > Key: CASSANDRA-10070 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10070 > Project: Cassandra > Issue Type: Improvement >Reporter: Marcus Olsson >Assignee: Marcus Olsson >Priority: Minor > Fix For: 3.x > > > Scheduling and running repairs in a Cassandra cluster is most often a > required task, but this can both be hard for new users and it also requires a > bit of manual configuration. There are good tools out there that can be used > to simplify things, but wouldn't this be a good feature to have inside of > Cassandra? To automatically schedule and run repairs, so that when you start > up your cluster it basically maintains itself in terms of normal > anti-entropy, with the possibility for manual configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[2/3] cassandra git commit: Fix Thrift CAS operations for columns with defined metadata
Fix Thrift CAS operations for columns with defined metadata
Patch by Sam Tunnicliffe; reviewed by Sylvain Lebresne for
CASSANDRA-10576
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/5034f449
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/5034f449
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/5034f449
Branch: refs/heads/trunk
Commit: 5034f449575a4648f67b50c1ff535518ce2f00e9
Parents: 3615da5
Author: Sam Tunnicliffe
Authored: Fri Oct 23 13:51:29 2015 +0100
Committer: Sam Tunnicliffe
Committed: Wed Oct 28 17:11:04 2015 +
--
CHANGES.txt | 1 +
.../cassandra/thrift/CassandraServer.java | 40 +---
2 files changed, 28 insertions(+), 13 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/5034f449/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index c51cb51..4ead854 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
3.0
+ * Fix thrift cas operations with defined columns (CASSANDRA-10576)
* Fix PartitionUpdate.operationCount()for updates with static column
operations (CASSANDRA-10606)
* Fix thrift get() queries with defined columns (CASSANDRA-10586)
* Fix marking of indexes as built and removed (CASSANDRA-10601)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/5034f449/src/java/org/apache/cassandra/thrift/CassandraServer.java
--
diff --git a/src/java/org/apache/cassandra/thrift/CassandraServer.java
b/src/java/org/apache/cassandra/thrift/CassandraServer.java
index 2a3f73d..02c0871 100644
--- a/src/java/org/apache/cassandra/thrift/CassandraServer.java
+++ b/src/java/org/apache/cassandra/thrift/CassandraServer.java
@@ -945,15 +945,11 @@ public class CassandraServer implements Cassandra.Iface
// Indexed column values cannot be larger than 64K. See
CASSANDRA-3057/4240 for more details
Keyspace.open(metadata.ksName).getColumnFamilyStore(metadata.cfName).indexManager.validate(partitionUpdates);
-FilteredPartition partitionExpected = null;
-if (!expected.isEmpty())
-partitionExpected =
FilteredPartition.create(LegacyLayout.toRowIterator(metadata, dk,
toLegacyCells(metadata, expected, nowInSec).iterator(), nowInSec));
-
schedule(DatabaseDescriptor.getWriteRpcTimeout());
try (RowIterator result = StorageProxy.cas(cState.getKeyspace(),
column_family,
dk,
- new
ThriftCASRequest(partitionExpected, partitionUpdates),
+ new
ThriftCASRequest(toLegacyCells(metadata, expected, nowInSec), partitionUpdates,
nowInSec),
ThriftConversion.fromThrift(serial_consistency_level),
ThriftConversion.fromThrift(commit_consistency_level),
cState))
@@ -2509,21 +2505,22 @@ public class CassandraServer implements Cassandra.Iface
{
private final CFMetaData metadata;
private final DecoratedKey key;
-
-private final FilteredPartition expected;
+private final List expected;
private final PartitionUpdate updates;
+private final int nowInSec;
-private ThriftCASRequest(FilteredPartition expected, PartitionUpdate
updates)
+private ThriftCASRequest(List expected,
PartitionUpdate updates, int nowInSec)
{
this.metadata = updates.metadata();
this.key = updates.partitionKey();
this.expected = expected;
this.updates = updates;
+this.nowInSec = nowInSec;
}
public SinglePartitionReadCommand readCommand(int nowInSec)
{
-if (expected == null || expected.isEmpty())
+if (expected.isEmpty())
{
// We want to know if the partition exists, so just fetch a
single cell.
ClusteringIndexSliceFilter filter = new
ClusteringIndexSliceFilter(Slices.ALL, false);
@@ -2533,9 +2530,13 @@ public class CassandraServer implements Cassandra.Iface
// Gather the clustering for the expected values and query those.
BTreeSet.Builder clusterings =
BTreeSet.builder(metadata.comparator);
-for (Row row : expected)
+FilteredPartition expectedPartition =
+FilteredPartition.create(LegacyLayout.toRowIterator(metadata,
[1/3] cassandra git commit: Fix Thrift CAS operations for columns with defined metadata
Repository: cassandra
Updated Branches:
refs/heads/cassandra-3.0 3615da583 -> 5034f4495
refs/heads/trunk a4fe865d4 -> 74ee6684c
Fix Thrift CAS operations for columns with defined metadata
Patch by Sam Tunnicliffe; reviewed by Sylvain Lebresne for
CASSANDRA-10576
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/5034f449
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/5034f449
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/5034f449
Branch: refs/heads/cassandra-3.0
Commit: 5034f449575a4648f67b50c1ff535518ce2f00e9
Parents: 3615da5
Author: Sam Tunnicliffe
Authored: Fri Oct 23 13:51:29 2015 +0100
Committer: Sam Tunnicliffe
Committed: Wed Oct 28 17:11:04 2015 +
--
CHANGES.txt | 1 +
.../cassandra/thrift/CassandraServer.java | 40 +---
2 files changed, 28 insertions(+), 13 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/5034f449/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index c51cb51..4ead854 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
3.0
+ * Fix thrift cas operations with defined columns (CASSANDRA-10576)
* Fix PartitionUpdate.operationCount()for updates with static column
operations (CASSANDRA-10606)
* Fix thrift get() queries with defined columns (CASSANDRA-10586)
* Fix marking of indexes as built and removed (CASSANDRA-10601)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/5034f449/src/java/org/apache/cassandra/thrift/CassandraServer.java
--
diff --git a/src/java/org/apache/cassandra/thrift/CassandraServer.java
b/src/java/org/apache/cassandra/thrift/CassandraServer.java
index 2a3f73d..02c0871 100644
--- a/src/java/org/apache/cassandra/thrift/CassandraServer.java
+++ b/src/java/org/apache/cassandra/thrift/CassandraServer.java
@@ -945,15 +945,11 @@ public class CassandraServer implements Cassandra.Iface
// Indexed column values cannot be larger than 64K. See
CASSANDRA-3057/4240 for more details
Keyspace.open(metadata.ksName).getColumnFamilyStore(metadata.cfName).indexManager.validate(partitionUpdates);
-FilteredPartition partitionExpected = null;
-if (!expected.isEmpty())
-partitionExpected =
FilteredPartition.create(LegacyLayout.toRowIterator(metadata, dk,
toLegacyCells(metadata, expected, nowInSec).iterator(), nowInSec));
-
schedule(DatabaseDescriptor.getWriteRpcTimeout());
try (RowIterator result = StorageProxy.cas(cState.getKeyspace(),
column_family,
dk,
- new
ThriftCASRequest(partitionExpected, partitionUpdates),
+ new
ThriftCASRequest(toLegacyCells(metadata, expected, nowInSec), partitionUpdates,
nowInSec),
ThriftConversion.fromThrift(serial_consistency_level),
ThriftConversion.fromThrift(commit_consistency_level),
cState))
@@ -2509,21 +2505,22 @@ public class CassandraServer implements Cassandra.Iface
{
private final CFMetaData metadata;
private final DecoratedKey key;
-
-private final FilteredPartition expected;
+private final List expected;
private final PartitionUpdate updates;
+private final int nowInSec;
-private ThriftCASRequest(FilteredPartition expected, PartitionUpdate
updates)
+private ThriftCASRequest(List expected,
PartitionUpdate updates, int nowInSec)
{
this.metadata = updates.metadata();
this.key = updates.partitionKey();
this.expected = expected;
this.updates = updates;
+this.nowInSec = nowInSec;
}
public SinglePartitionReadCommand readCommand(int nowInSec)
{
-if (expected == null || expected.isEmpty())
+if (expected.isEmpty())
{
// We want to know if the partition exists, so just fetch a
single cell.
ClusteringIndexSliceFilter filter = new
ClusteringIndexSliceFilter(Slices.ALL, false);
@@ -2533,9 +2530,13 @@ public class CassandraServer implements Cassandra.Iface
// Gather the clustering for the expected values and query those.
BTreeSet.Builder clusterings =
BTreeSet.builder(metadata.comparator);
-for (Row row
[jira] [Commented] (CASSANDRA-10614) AssertionError while flushing memtables
[
https://issues.apache.org/jira/browse/CASSANDRA-10614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14978789#comment-14978789
]
Tyler Hobbs commented on CASSANDRA-10614:
-
It looks like this was introduced by CASSANDRA-9664, and is likely the cause of
CASSANDRA-10609.
> AssertionError while flushing memtables
> ---
>
> Key: CASSANDRA-10614
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10614
> Project: Cassandra
> Issue Type: Bug
> Components: Core, Local Write-Read Paths
>Reporter: Tyler Hobbs
>Assignee: T Jake Luciani
>Priority: Critical
> Fix For: 3.0.0
>
>
> While running mvbench against a single local node, I noticed this stacktrace
> showing up multiple times in the logs:
> {noformat}
> ERROR 16:40:01 Exception in thread Thread[MemtableFlushWriter:1,5,main]
> java.lang.AssertionError: null
> at org.apache.cassandra.db.rows.Rows.collectStats(Rows.java:70)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter$StatsCollector.applyToRow(BigTableWriter.java:197)
> ~[main/:na]
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:116)
> ~[main/:na]
> at
> org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:38)
> ~[main/:na]
> at
> org.apache.cassandra.db.ColumnIndex.writeAndBuildIndex(ColumnIndex.java:49)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(BigTableWriter.java:149)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.SimpleSSTableMultiWriter.append(SimpleSSTableMultiWriter.java:45)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.SSTableTxnWriter.append(SSTableTxnWriter.java:52)
> ~[main/:na]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents(Memtable.java:389)
> ~[main/:na]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.runMayThrow(Memtable.java:352)
> ~[main/:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[main/:na]
> at
> com.google.common.util.concurrent.MoreExecutors$DirectExecutorService.execute(MoreExecutors.java:299)
> ~[guava-18.0.jar:na]
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1037)
> ~[main/:na]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> ~[na:1.8.0_45]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> ~[na:1.8.0_45]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_45]
> {noformat}
> To reproduce, run mvbench with the regular schema and the following arguments:
> {noformat}
> mvn exec:java -Dexec.args="--num-users 10 --num-songs 100
> --num-artists 1 -n 50 --endpoint 127.0.0.1"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[3/3] cassandra git commit: Merge branch 'cassandra-3.0' into trunk
Merge branch 'cassandra-3.0' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/74ee6684 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/74ee6684 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/74ee6684 Branch: refs/heads/trunk Commit: 74ee6684ca1f93ccb737b68bc401dba23045610f Parents: a4fe865 5034f44 Author: Sam Tunnicliffe Authored: Wed Oct 28 17:15:10 2015 + Committer: Sam Tunnicliffe Committed: Wed Oct 28 17:15:10 2015 + -- CHANGES.txt | 1 + .../cassandra/thrift/CassandraServer.java | 40 +--- 2 files changed, 28 insertions(+), 13 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/74ee6684/CHANGES.txt -- diff --cc CHANGES.txt index 29117e0,4ead854..1b6ede7 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,10 -1,5 +1,11 @@@ +3.2 + * Added graphing option to cassandra-stress (CASSANDRA-7918) + * Abort in-progress queries that time out (CASSANDRA-7392) + * Add transparent data encryption core classes (CASSANDRA-9945) + + 3.0 + * Fix thrift cas operations with defined columns (CASSANDRA-10576) * Fix PartitionUpdate.operationCount()for updates with static column operations (CASSANDRA-10606) * Fix thrift get() queries with defined columns (CASSANDRA-10586) * Fix marking of indexes as built and removed (CASSANDRA-10601)
[jira] [Assigned] (CASSANDRA-10614) AssertionError while flushing memtables
[
https://issues.apache.org/jira/browse/CASSANDRA-10614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tyler Hobbs reassigned CASSANDRA-10614:
---
Assignee: Tyler Hobbs (was: T Jake Luciani)
> AssertionError while flushing memtables
> ---
>
> Key: CASSANDRA-10614
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10614
> Project: Cassandra
> Issue Type: Bug
> Components: Core, Local Write-Read Paths
>Reporter: Tyler Hobbs
>Assignee: Tyler Hobbs
>Priority: Critical
> Fix For: 3.0.0
>
>
> While running mvbench against a single local node, I noticed this stacktrace
> showing up multiple times in the logs:
> {noformat}
> ERROR 16:40:01 Exception in thread Thread[MemtableFlushWriter:1,5,main]
> java.lang.AssertionError: null
> at org.apache.cassandra.db.rows.Rows.collectStats(Rows.java:70)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter$StatsCollector.applyToRow(BigTableWriter.java:197)
> ~[main/:na]
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:116)
> ~[main/:na]
> at
> org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:38)
> ~[main/:na]
> at
> org.apache.cassandra.db.ColumnIndex.writeAndBuildIndex(ColumnIndex.java:49)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(BigTableWriter.java:149)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.SimpleSSTableMultiWriter.append(SimpleSSTableMultiWriter.java:45)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.SSTableTxnWriter.append(SSTableTxnWriter.java:52)
> ~[main/:na]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents(Memtable.java:389)
> ~[main/:na]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.runMayThrow(Memtable.java:352)
> ~[main/:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[main/:na]
> at
> com.google.common.util.concurrent.MoreExecutors$DirectExecutorService.execute(MoreExecutors.java:299)
> ~[guava-18.0.jar:na]
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1037)
> ~[main/:na]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> ~[na:1.8.0_45]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> ~[na:1.8.0_45]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_45]
> {noformat}
> To reproduce, run mvbench with the regular schema and the following arguments:
> {noformat}
> mvn exec:java -Dexec.args="--num-users 10 --num-songs 100
> --num-artists 1 -n 50 --endpoint 127.0.0.1"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10092) Generalize PerRowSecondaryIndex validation
[
https://issues.apache.org/jira/browse/CASSANDRA-10092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14978759#comment-14978759
]
Sam Tunnicliffe commented on CASSANDRA-10092:
-
[~adelapena] thanks for the updated patch. I appreciate the thrift API is a bit
esoteric, so thanks for persevering with it. I've backported the v3 patch to
2.1 and pushed both 2.1 & 2.2 branches to my local repo for CI. Once those test
results are clean I'll commit. Thanks again.
||2.1||2.2||
|[branch|https://github.com/beobal/cassandra/tree/10092-2.1]|[branch|https://github.com/beobal/cassandra/tree/10092-2.2]|
|[testall|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-10092-2.1-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-10092-2.2-testall/]|
|[dtests|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-10092-2.1-dtest/]|[dtests|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-10092-2.2-dtest/]|
> Generalize PerRowSecondaryIndex validation
> --
>
> Key: CASSANDRA-10092
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10092
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Andrés de la Peña
>Assignee: Andrés de la Peña
>Priority: Minor
> Labels: 2i, secondary_index, validation
> Fix For: 2.1.x, 2.2.x
>
> Attachments: CASSANDRA-10092_v2.patch, CASSANDRA-10092_v3.patch,
> improve_2i_validation.patch
>
>
> Index validation is currently done in a per-cell basis. However, per-row
> secondary index developers can be interested in validating all the written
> columns at once, because some implementations need to check the validity of a
> row write by comparing some column values against others. For example, a per
> row 2i implementation indexing time ranges (composed by a start date column
> and an end date column) should check that the start date is before the stop
> date.
> I'm attaching a patch adding a new method to {{PerRowSecondaryIndex}}:
> {code:java}
> public void validate(ByteBuffer key, ColumnFamily cf) throws
> InvalidRequestException {}
> {code}
> and a new method to {{SecondaryIndexManager}}:
> {code:java}
> public void validateRowLevelIndexes(ByteBuffer key, ColumnFamily cf) throws
> InvalidRequestException
> {
> for (SecondaryIndex index : rowLevelIndexMap.values())
> {
> ((PerRowSecondaryIndex) index).validate(key, cf);
> }
> }
> {code}
> This method is invoked in CQL {{UpdateStatement#validateIndexedColumns}}.
> This way, {{PerRowSecondaryIndex}} could perform complex write validation.
> I have tried to do the patch in the least invasive way possible. Maybe the
> current method {{SecondaryIndex#validate(ByteBuffer, Cell)}} should be moved
> to {{PerColumnSecondaryIndex}}, and the {{InvalidRequestException}} that
> informs about the particular 64k limitation should be thrown by
> {{AbstractSimplePerColumnSecondaryIndex}}. However, given the incoming
> [CASSANDRA-9459|https://issues.apache.org/jira/browse/CASSANDRA-9459], I
> think that the proposed patch is more than enough to provide rich validation
> features to 2i implementations based on 2.1.x and 2.2.x.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-10614) AssertionError while flushing memtables
[
https://issues.apache.org/jira/browse/CASSANDRA-10614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
T Jake Luciani reassigned CASSANDRA-10614:
--
Assignee: T Jake Luciani
> AssertionError while flushing memtables
> ---
>
> Key: CASSANDRA-10614
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10614
> Project: Cassandra
> Issue Type: Bug
> Components: Core, Local Write-Read Paths
>Reporter: Tyler Hobbs
>Assignee: T Jake Luciani
>Priority: Critical
> Fix For: 3.0.0
>
>
> While running mvbench against a single local node, I noticed this stacktrace
> showing up multiple times in the logs:
> {noformat}
> ERROR 16:40:01 Exception in thread Thread[MemtableFlushWriter:1,5,main]
> java.lang.AssertionError: null
> at org.apache.cassandra.db.rows.Rows.collectStats(Rows.java:70)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter$StatsCollector.applyToRow(BigTableWriter.java:197)
> ~[main/:na]
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:116)
> ~[main/:na]
> at
> org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:38)
> ~[main/:na]
> at
> org.apache.cassandra.db.ColumnIndex.writeAndBuildIndex(ColumnIndex.java:49)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(BigTableWriter.java:149)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.SimpleSSTableMultiWriter.append(SimpleSSTableMultiWriter.java:45)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.SSTableTxnWriter.append(SSTableTxnWriter.java:52)
> ~[main/:na]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents(Memtable.java:389)
> ~[main/:na]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.runMayThrow(Memtable.java:352)
> ~[main/:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[main/:na]
> at
> com.google.common.util.concurrent.MoreExecutors$DirectExecutorService.execute(MoreExecutors.java:299)
> ~[guava-18.0.jar:na]
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1037)
> ~[main/:na]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> ~[na:1.8.0_45]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> ~[na:1.8.0_45]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_45]
> {noformat}
> To reproduce, run mvbench with the regular schema and the following arguments:
> {noformat}
> mvn exec:java -Dexec.args="--num-users 10 --num-songs 100
> --num-artists 1 -n 50 --endpoint 127.0.0.1"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10614) AssertionError while flushing memtables
[
https://issues.apache.org/jira/browse/CASSANDRA-10614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
T Jake Luciani updated CASSANDRA-10614:
---
Assignee: (was: T Jake Luciani)
> AssertionError while flushing memtables
> ---
>
> Key: CASSANDRA-10614
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10614
> Project: Cassandra
> Issue Type: Bug
> Components: Core, Local Write-Read Paths
>Reporter: Tyler Hobbs
>Priority: Critical
> Fix For: 3.0.0
>
>
> While running mvbench against a single local node, I noticed this stacktrace
> showing up multiple times in the logs:
> {noformat}
> ERROR 16:40:01 Exception in thread Thread[MemtableFlushWriter:1,5,main]
> java.lang.AssertionError: null
> at org.apache.cassandra.db.rows.Rows.collectStats(Rows.java:70)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter$StatsCollector.applyToRow(BigTableWriter.java:197)
> ~[main/:na]
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:116)
> ~[main/:na]
> at
> org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:38)
> ~[main/:na]
> at
> org.apache.cassandra.db.ColumnIndex.writeAndBuildIndex(ColumnIndex.java:49)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(BigTableWriter.java:149)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.SimpleSSTableMultiWriter.append(SimpleSSTableMultiWriter.java:45)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.SSTableTxnWriter.append(SSTableTxnWriter.java:52)
> ~[main/:na]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents(Memtable.java:389)
> ~[main/:na]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.runMayThrow(Memtable.java:352)
> ~[main/:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[main/:na]
> at
> com.google.common.util.concurrent.MoreExecutors$DirectExecutorService.execute(MoreExecutors.java:299)
> ~[guava-18.0.jar:na]
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1037)
> ~[main/:na]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> ~[na:1.8.0_45]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> ~[na:1.8.0_45]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_45]
> {noformat}
> To reproduce, run mvbench with the regular schema and the following arguments:
> {noformat}
> mvn exec:java -Dexec.args="--num-users 10 --num-songs 100
> --num-artists 1 -n 50 --endpoint 127.0.0.1"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10606) PartitionUpdate.operationCount() return the wrong number of operation for compact tables
[
https://issues.apache.org/jira/browse/CASSANDRA-10606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14978739#comment-14978739
]
Benjamin Lerer commented on CASSANDRA-10606:
Committed in 3.0 at 3615da58310a778c7ee6d9b2d77fd3fb7a6700f4 and merged into
trunk.
> PartitionUpdate.operationCount() return the wrong number of operation for
> compact tables
>
>
> Key: CASSANDRA-10606
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10606
> Project: Cassandra
> Issue Type: Bug
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
> Fix For: 3.0.0
>
> Attachments: 10606-3.0-V2.txt, 10606-3.0-V3.txt, 10606-3.0.txt
>
>
> For compact tables {{PartitionUpdate.operationCount()}} return the wrong
> number of operation as it does not take into operation on static rows.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10614) AssertionError while flushing memtables
[
https://issues.apache.org/jira/browse/CASSANDRA-10614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tyler Hobbs updated CASSANDRA-10614:
Summary: AssertionError while flushing memtables (was: AsertionError while
flushing memtables)
> AssertionError while flushing memtables
> ---
>
> Key: CASSANDRA-10614
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10614
> Project: Cassandra
> Issue Type: Bug
> Components: Core, Local Write-Read Paths
>Reporter: Tyler Hobbs
>Assignee: T Jake Luciani
>Priority: Critical
> Fix For: 3.0.0
>
>
> While running mvbench against a single local node, I noticed this stacktrace
> showing up multiple times in the logs:
> {noformat}
> ERROR 16:40:01 Exception in thread Thread[MemtableFlushWriter:1,5,main]
> java.lang.AssertionError: null
> at org.apache.cassandra.db.rows.Rows.collectStats(Rows.java:70)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter$StatsCollector.applyToRow(BigTableWriter.java:197)
> ~[main/:na]
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:116)
> ~[main/:na]
> at
> org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:38)
> ~[main/:na]
> at
> org.apache.cassandra.db.ColumnIndex.writeAndBuildIndex(ColumnIndex.java:49)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(BigTableWriter.java:149)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.SimpleSSTableMultiWriter.append(SimpleSSTableMultiWriter.java:45)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.SSTableTxnWriter.append(SSTableTxnWriter.java:52)
> ~[main/:na]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents(Memtable.java:389)
> ~[main/:na]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.runMayThrow(Memtable.java:352)
> ~[main/:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[main/:na]
> at
> com.google.common.util.concurrent.MoreExecutors$DirectExecutorService.execute(MoreExecutors.java:299)
> ~[guava-18.0.jar:na]
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1037)
> ~[main/:na]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> ~[na:1.8.0_45]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> ~[na:1.8.0_45]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_45]
> {noformat}
> To reproduce, run mvbench with the regular schema and the following arguments:
> {noformat}
> mvn exec:java -Dexec.args="--num-users 10 --num-songs 100
> --num-artists 1 -n 50 --endpoint 127.0.0.1"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10614) AsertionError while flushing memtables
[
https://issues.apache.org/jira/browse/CASSANDRA-10614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joshua McKenzie updated CASSANDRA-10614:
Component/s: Local Write-Read Paths
> AsertionError while flushing memtables
> --
>
> Key: CASSANDRA-10614
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10614
> Project: Cassandra
> Issue Type: Bug
> Components: Core, Local Write-Read Paths
>Reporter: Tyler Hobbs
>Priority: Critical
> Fix For: 3.0.0
>
>
> While running mvbench against a single local node, I noticed this stacktrace
> showing up multiple times in the logs:
> {noformat}
> ERROR 16:40:01 Exception in thread Thread[MemtableFlushWriter:1,5,main]
> java.lang.AssertionError: null
> at org.apache.cassandra.db.rows.Rows.collectStats(Rows.java:70)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter$StatsCollector.applyToRow(BigTableWriter.java:197)
> ~[main/:na]
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:116)
> ~[main/:na]
> at
> org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:38)
> ~[main/:na]
> at
> org.apache.cassandra.db.ColumnIndex.writeAndBuildIndex(ColumnIndex.java:49)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(BigTableWriter.java:149)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.SimpleSSTableMultiWriter.append(SimpleSSTableMultiWriter.java:45)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.SSTableTxnWriter.append(SSTableTxnWriter.java:52)
> ~[main/:na]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents(Memtable.java:389)
> ~[main/:na]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.runMayThrow(Memtable.java:352)
> ~[main/:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[main/:na]
> at
> com.google.common.util.concurrent.MoreExecutors$DirectExecutorService.execute(MoreExecutors.java:299)
> ~[guava-18.0.jar:na]
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1037)
> ~[main/:na]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> ~[na:1.8.0_45]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> ~[na:1.8.0_45]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_45]
> {noformat}
> To reproduce, run mvbench with the regular schema and the following arguments:
> {noformat}
> mvn exec:java -Dexec.args="--num-users 10 --num-songs 100
> --num-artists 1 -n 50 --endpoint 127.0.0.1"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10614) AsertionError while flushing memtables
[
https://issues.apache.org/jira/browse/CASSANDRA-10614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14978735#comment-14978735
]
Sylvain Lebresne commented on CASSANDRA-10614:
--
>From the assertion, it sounds like an empty row had made its way in the
>memtable. Maybe the MV code can generate an empty row in some conditions?
> AsertionError while flushing memtables
> --
>
> Key: CASSANDRA-10614
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10614
> Project: Cassandra
> Issue Type: Bug
> Components: Core, Local Write-Read Paths
>Reporter: Tyler Hobbs
>Assignee: T Jake Luciani
>Priority: Critical
> Fix For: 3.0.0
>
>
> While running mvbench against a single local node, I noticed this stacktrace
> showing up multiple times in the logs:
> {noformat}
> ERROR 16:40:01 Exception in thread Thread[MemtableFlushWriter:1,5,main]
> java.lang.AssertionError: null
> at org.apache.cassandra.db.rows.Rows.collectStats(Rows.java:70)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter$StatsCollector.applyToRow(BigTableWriter.java:197)
> ~[main/:na]
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:116)
> ~[main/:na]
> at
> org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:38)
> ~[main/:na]
> at
> org.apache.cassandra.db.ColumnIndex.writeAndBuildIndex(ColumnIndex.java:49)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(BigTableWriter.java:149)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.SimpleSSTableMultiWriter.append(SimpleSSTableMultiWriter.java:45)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.SSTableTxnWriter.append(SSTableTxnWriter.java:52)
> ~[main/:na]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents(Memtable.java:389)
> ~[main/:na]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.runMayThrow(Memtable.java:352)
> ~[main/:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[main/:na]
> at
> com.google.common.util.concurrent.MoreExecutors$DirectExecutorService.execute(MoreExecutors.java:299)
> ~[guava-18.0.jar:na]
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1037)
> ~[main/:na]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> ~[na:1.8.0_45]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> ~[na:1.8.0_45]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_45]
> {noformat}
> To reproduce, run mvbench with the regular schema and the following arguments:
> {noformat}
> mvn exec:java -Dexec.args="--num-users 10 --num-songs 100
> --num-artists 1 -n 50 --endpoint 127.0.0.1"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-10614) AsertionError while flushing memtables
[
https://issues.apache.org/jira/browse/CASSANDRA-10614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joshua McKenzie reassigned CASSANDRA-10614:
---
Assignee: T Jake Luciani
> AsertionError while flushing memtables
> --
>
> Key: CASSANDRA-10614
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10614
> Project: Cassandra
> Issue Type: Bug
> Components: Core, Local Write-Read Paths
>Reporter: Tyler Hobbs
>Assignee: T Jake Luciani
>Priority: Critical
> Fix For: 3.0.0
>
>
> While running mvbench against a single local node, I noticed this stacktrace
> showing up multiple times in the logs:
> {noformat}
> ERROR 16:40:01 Exception in thread Thread[MemtableFlushWriter:1,5,main]
> java.lang.AssertionError: null
> at org.apache.cassandra.db.rows.Rows.collectStats(Rows.java:70)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter$StatsCollector.applyToRow(BigTableWriter.java:197)
> ~[main/:na]
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:116)
> ~[main/:na]
> at
> org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:38)
> ~[main/:na]
> at
> org.apache.cassandra.db.ColumnIndex.writeAndBuildIndex(ColumnIndex.java:49)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(BigTableWriter.java:149)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.SimpleSSTableMultiWriter.append(SimpleSSTableMultiWriter.java:45)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.SSTableTxnWriter.append(SSTableTxnWriter.java:52)
> ~[main/:na]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents(Memtable.java:389)
> ~[main/:na]
> at
> org.apache.cassandra.db.Memtable$FlushRunnable.runMayThrow(Memtable.java:352)
> ~[main/:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[main/:na]
> at
> com.google.common.util.concurrent.MoreExecutors$DirectExecutorService.execute(MoreExecutors.java:299)
> ~[guava-18.0.jar:na]
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1037)
> ~[main/:na]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> ~[na:1.8.0_45]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> ~[na:1.8.0_45]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_45]
> {noformat}
> To reproduce, run mvbench with the regular schema and the following arguments:
> {noformat}
> mvn exec:java -Dexec.args="--num-users 10 --num-songs 100
> --num-artists 1 -n 50 --endpoint 127.0.0.1"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[2/2] cassandra git commit: Merge branch cassandra-3.0 into trunk
Merge branch cassandra-3.0 into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/a4fe865d Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a4fe865d Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a4fe865d Branch: refs/heads/trunk Commit: a4fe865d4f8cb7ca8d14191d6d9ccf6ac1f79eb3 Parents: 9be01e3 3615da5 Author: Benjamin Lerer Authored: Wed Oct 28 17:47:07 2015 +0100 Committer: Benjamin Lerer Committed: Wed Oct 28 17:47:33 2015 +0100 -- CHANGES.txt | 1 + .../db/partitions/PartitionUpdate.java | 1 + .../db/partition/PartitionUpdateTest.java | 67 3 files changed, 69 insertions(+) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/a4fe865d/CHANGES.txt -- diff --cc CHANGES.txt index 04cefae,c51cb51..29117e0 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,10 -1,5 +1,11 @@@ +3.2 + * Added graphing option to cassandra-stress (CASSANDRA-7918) + * Abort in-progress queries that time out (CASSANDRA-7392) + * Add transparent data encryption core classes (CASSANDRA-9945) + + 3.0 + * Fix PartitionUpdate.operationCount()for updates with static column operations (CASSANDRA-10606) * Fix thrift get() queries with defined columns (CASSANDRA-10586) * Fix marking of indexes as built and removed (CASSANDRA-10601) * Skip initialization of non-registered 2i instances, remove Index::getIndexName (CASSANDRA-10595)
[jira] [Commented] (CASSANDRA-10581) Update cassandra.yaml comments to reflect memory_allocator deprecation, remove in 3.0
[
https://issues.apache.org/jira/browse/CASSANDRA-10581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14978730#comment-14978730
]
Jim Witschey commented on CASSANDRA-10581:
--
The documentation changes look good to me. If it's not already logged somewhere
that I missed it, could you add some kind of logging indicating when Cassandra
used JEMAlloc? As is, it's difficult to determine if it's actually used, as far
as I can tell.
> Update cassandra.yaml comments to reflect memory_allocator deprecation,
> remove in 3.0
> -
>
> Key: CASSANDRA-10581
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10581
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jim Witschey
>Assignee: Robert Stupp
> Fix For: 2.2.x, 3.0.0
>
>
> Looks like in 2.2+ changing the {{memory_allocator}} field in cassandra.yaml
> has no effect:
> https://github.com/apache/cassandra/commit/0d2ec11c7e0abfb84d872289af6d3ac386cf381f#diff-b66584c9ce7b64019b5db5a531deeda1R207
> The instructions in comments on how to use jemalloc haven't been updated to
> reflect this change. [~snazy], is that an accurate assessment?
> [~iamaleksey] How do we want to handle the deprecation more generally? Warn
> on 2.2, remove in 3.0?
> EDIT: I described this in a way that isn't very clear to those unfamiliar
> with Robert's change. To be clear: You can still use JEMAlloc with Cassandra.
> The {{memory_allocator}} option was deprecated in favor of automatically
> detecting if JEMAlloc is installed, and, if so, using it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[1/2] cassandra git commit: Fix PartitionUpdate.operationCount()for updates with static column
Repository: cassandra
Updated Branches:
refs/heads/trunk 9be01e34c -> a4fe865d4
Fix PartitionUpdate.operationCount()for updates with static column
patch by Benjamin Lerer; reviewed by Sylvain Lebresne for CASSANDRA-10606
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3615da58
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3615da58
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3615da58
Branch: refs/heads/trunk
Commit: 3615da58310a778c7ee6d9b2d77fd3fb7a6700f4
Parents: 4d00468
Author: Benjamin Lerer
Authored: Wed Oct 28 17:41:03 2015 +0100
Committer: Benjamin Lerer
Committed: Wed Oct 28 17:41:03 2015 +0100
--
CHANGES.txt | 1 +
.../db/partitions/PartitionUpdate.java | 1 +
.../db/partition/PartitionUpdateTest.java | 67
3 files changed, 69 insertions(+)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/3615da58/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 3423a1e..c51cb51 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
3.0
+ * Fix PartitionUpdate.operationCount()for updates with static column
operations (CASSANDRA-10606)
* Fix thrift get() queries with defined columns (CASSANDRA-10586)
* Fix marking of indexes as built and removed (CASSANDRA-10601)
* Skip initialization of non-registered 2i instances, remove
Index::getIndexName (CASSANDRA-10595)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/3615da58/src/java/org/apache/cassandra/db/partitions/PartitionUpdate.java
--
diff --git a/src/java/org/apache/cassandra/db/partitions/PartitionUpdate.java
b/src/java/org/apache/cassandra/db/partitions/PartitionUpdate.java
index b1776ca..52f8f67 100644
--- a/src/java/org/apache/cassandra/db/partitions/PartitionUpdate.java
+++ b/src/java/org/apache/cassandra/db/partitions/PartitionUpdate.java
@@ -334,6 +334,7 @@ public class PartitionUpdate extends AbstractBTreePartition
public int operationCount()
{
return rowCount()
+ + (staticRow().isEmpty() ? 0 : 1)
+ deletionInfo.rangeCount()
+ (deletionInfo.getPartitionDeletion().isLive() ? 0 : 1);
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/3615da58/test/unit/org/apache/cassandra/db/partition/PartitionUpdateTest.java
--
diff --git
a/test/unit/org/apache/cassandra/db/partition/PartitionUpdateTest.java
b/test/unit/org/apache/cassandra/db/partition/PartitionUpdateTest.java
new file mode 100644
index 000..a069db1
--- /dev/null
+++ b/test/unit/org/apache/cassandra/db/partition/PartitionUpdateTest.java
@@ -0,0 +1,67 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.cassandra.db.partition;
+
+import org.apache.cassandra.config.CFMetaData;
+import org.apache.cassandra.cql3.CQLTester;
+import org.apache.cassandra.db.RowUpdateBuilder;
+import org.apache.cassandra.db.partitions.PartitionUpdate;
+import org.apache.cassandra.utils.FBUtilities;
+import org.junit.Test;
+
+import junit.framework.Assert;
+
+public class PartitionUpdateTest extends CQLTester
+{
+@Test
+public void testOperationCount()
+{
+createTable("CREATE TABLE %s (key text, clustering int, a int, s int
static, PRIMARY KEY(key, clustering))");
+CFMetaData cfm = currentTableMetadata();
+
+long timestamp = FBUtilities.timestampMicros();
+PartitionUpdate update = new RowUpdateBuilder(cfm, timestamp,
"key0").clustering(1).add("a", 1).buildUpdate();
+Assert.assertEquals(1, update.operationCount());
+
+update = new RowUpdateBuilder(cfm, timestamp, "key0").buildUpdate();
+Assert.assertEquals(0, update.operationCount());
+
+update = new RowUpdateBuilder(cfm, timestamp, "key0").add("s",
1).buildUpdate();
+Assert.assert
[jira] [Updated] (CASSANDRA-9829) Dynamically adjust LCS level sizes
[ https://issues.apache.org/jira/browse/CASSANDRA-9829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-9829: --- Assignee: (was: Paulo Motta) > Dynamically adjust LCS level sizes > -- > > Key: CASSANDRA-9829 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9829 > Project: Cassandra > Issue Type: New Feature >Reporter: Jonathan Ellis > Labels: compaction, performance > Fix For: 3.x > > > LCS works best when the top level is full. Then 90% of reads can be served > from a single sstable. By contrast if the top level is only 10% full then > 90% of reads will be served from two. This results in worse performance as > well as confused users. > To address this, we can adjust the ideal top level size to how much data is > actually in it (and set each corresponding lower level to 1/10 of the next > one above). > (This is an idea [from > rocksdb|https://www.reddit.com/r/IAmA/comments/3de3cv/we_are_rocksdb_engineering_team_ask_us_anything/ct4asen].) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
cassandra git commit: Fix PartitionUpdate.operationCount()for updates with static column
Repository: cassandra
Updated Branches:
refs/heads/cassandra-3.0 4d00468cc -> 3615da583
Fix PartitionUpdate.operationCount()for updates with static column
patch by Benjamin Lerer; reviewed by Sylvain Lebresne for CASSANDRA-10606
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3615da58
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3615da58
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3615da58
Branch: refs/heads/cassandra-3.0
Commit: 3615da58310a778c7ee6d9b2d77fd3fb7a6700f4
Parents: 4d00468
Author: Benjamin Lerer
Authored: Wed Oct 28 17:41:03 2015 +0100
Committer: Benjamin Lerer
Committed: Wed Oct 28 17:41:03 2015 +0100
--
CHANGES.txt | 1 +
.../db/partitions/PartitionUpdate.java | 1 +
.../db/partition/PartitionUpdateTest.java | 67
3 files changed, 69 insertions(+)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/3615da58/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 3423a1e..c51cb51 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
3.0
+ * Fix PartitionUpdate.operationCount()for updates with static column
operations (CASSANDRA-10606)
* Fix thrift get() queries with defined columns (CASSANDRA-10586)
* Fix marking of indexes as built and removed (CASSANDRA-10601)
* Skip initialization of non-registered 2i instances, remove
Index::getIndexName (CASSANDRA-10595)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/3615da58/src/java/org/apache/cassandra/db/partitions/PartitionUpdate.java
--
diff --git a/src/java/org/apache/cassandra/db/partitions/PartitionUpdate.java
b/src/java/org/apache/cassandra/db/partitions/PartitionUpdate.java
index b1776ca..52f8f67 100644
--- a/src/java/org/apache/cassandra/db/partitions/PartitionUpdate.java
+++ b/src/java/org/apache/cassandra/db/partitions/PartitionUpdate.java
@@ -334,6 +334,7 @@ public class PartitionUpdate extends AbstractBTreePartition
public int operationCount()
{
return rowCount()
+ + (staticRow().isEmpty() ? 0 : 1)
+ deletionInfo.rangeCount()
+ (deletionInfo.getPartitionDeletion().isLive() ? 0 : 1);
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/3615da58/test/unit/org/apache/cassandra/db/partition/PartitionUpdateTest.java
--
diff --git
a/test/unit/org/apache/cassandra/db/partition/PartitionUpdateTest.java
b/test/unit/org/apache/cassandra/db/partition/PartitionUpdateTest.java
new file mode 100644
index 000..a069db1
--- /dev/null
+++ b/test/unit/org/apache/cassandra/db/partition/PartitionUpdateTest.java
@@ -0,0 +1,67 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.cassandra.db.partition;
+
+import org.apache.cassandra.config.CFMetaData;
+import org.apache.cassandra.cql3.CQLTester;
+import org.apache.cassandra.db.RowUpdateBuilder;
+import org.apache.cassandra.db.partitions.PartitionUpdate;
+import org.apache.cassandra.utils.FBUtilities;
+import org.junit.Test;
+
+import junit.framework.Assert;
+
+public class PartitionUpdateTest extends CQLTester
+{
+@Test
+public void testOperationCount()
+{
+createTable("CREATE TABLE %s (key text, clustering int, a int, s int
static, PRIMARY KEY(key, clustering))");
+CFMetaData cfm = currentTableMetadata();
+
+long timestamp = FBUtilities.timestampMicros();
+PartitionUpdate update = new RowUpdateBuilder(cfm, timestamp,
"key0").clustering(1).add("a", 1).buildUpdate();
+Assert.assertEquals(1, update.operationCount());
+
+update = new RowUpdateBuilder(cfm, timestamp, "key0").buildUpdate();
+Assert.assertEquals(0, update.operationCount());
+
+update = new RowUpdateBuilder(cfm, timestamp, "key0").add("s",
1).buildUpdate();
+
[jira] [Created] (CASSANDRA-10614) AsertionError while flushing memtables
Tyler Hobbs created CASSANDRA-10614:
---
Summary: AsertionError while flushing memtables
Key: CASSANDRA-10614
URL: https://issues.apache.org/jira/browse/CASSANDRA-10614
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Tyler Hobbs
Priority: Critical
Fix For: 3.0.0
While running mvbench against a single local node, I noticed this stacktrace
showing up multiple times in the logs:
{noformat}
ERROR 16:40:01 Exception in thread Thread[MemtableFlushWriter:1,5,main]
java.lang.AssertionError: null
at org.apache.cassandra.db.rows.Rows.collectStats(Rows.java:70)
~[main/:na]
at
org.apache.cassandra.io.sstable.format.big.BigTableWriter$StatsCollector.applyToRow(BigTableWriter.java:197)
~[main/:na]
at
org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:116)
~[main/:na]
at
org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:38)
~[main/:na]
at
org.apache.cassandra.db.ColumnIndex.writeAndBuildIndex(ColumnIndex.java:49)
~[main/:na]
at
org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(BigTableWriter.java:149)
~[main/:na]
at
org.apache.cassandra.io.sstable.SimpleSSTableMultiWriter.append(SimpleSSTableMultiWriter.java:45)
~[main/:na]
at
org.apache.cassandra.io.sstable.SSTableTxnWriter.append(SSTableTxnWriter.java:52)
~[main/:na]
at
org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents(Memtable.java:389)
~[main/:na]
at
org.apache.cassandra.db.Memtable$FlushRunnable.runMayThrow(Memtable.java:352)
~[main/:na]
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
~[main/:na]
at
com.google.common.util.concurrent.MoreExecutors$DirectExecutorService.execute(MoreExecutors.java:299)
~[guava-18.0.jar:na]
at
org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1037)
~[main/:na]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
~[na:1.8.0_45]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
~[na:1.8.0_45]
at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_45]
{noformat}
To reproduce, run mvbench with the regular schema and the following arguments:
{noformat}
mvn exec:java -Dexec.args="--num-users 10 --num-songs 100 --num-artists
1 -n 50 --endpoint 127.0.0.1"
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10581) Update cassandra.yaml comments to reflect memory_allocator deprecation, remove in 3.0
[
https://issues.apache.org/jira/browse/CASSANDRA-10581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Witschey updated CASSANDRA-10581:
-
Description:
Looks like in 2.2+ changing the {{memory_allocator}} field in cassandra.yaml
has no effect:
https://github.com/apache/cassandra/commit/0d2ec11c7e0abfb84d872289af6d3ac386cf381f#diff-b66584c9ce7b64019b5db5a531deeda1R207
The instructions in comments on how to use jemalloc haven't been updated to
reflect this change. [~snazy], is that an accurate assessment?
[~iamaleksey] How do we want to handle the deprecation more generally? Warn on
2.2, remove in 3.0?
EDIT: I described this in a way that isn't very clear to those unfamiliar with
Robert's change. To be clear: You can still use JEMAlloc with Cassandra. The
{{memory_allocator}} option was deprecated in favor of automatically detecting
if JEMAlloc is installed, and, if so, using it.
was:
Looks like in 2.2+ changing the {{memory_allocator}} field in cassandra.yaml
has no effect:
https://github.com/apache/cassandra/commit/0d2ec11c7e0abfb84d872289af6d3ac386cf381f#diff-b66584c9ce7b64019b5db5a531deeda1R207
The instructions in comments on how to use jemalloc haven't been updated to
reflect this change. [~snazy], is that an accurate assessment?
[~iamaleksey] How do we want to handle the deprecation more generally? Warn on
2.2, remove in 3.0?
> Update cassandra.yaml comments to reflect memory_allocator deprecation,
> remove in 3.0
> -
>
> Key: CASSANDRA-10581
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10581
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jim Witschey
>Assignee: Robert Stupp
> Fix For: 2.2.x, 3.0.0
>
>
> Looks like in 2.2+ changing the {{memory_allocator}} field in cassandra.yaml
> has no effect:
> https://github.com/apache/cassandra/commit/0d2ec11c7e0abfb84d872289af6d3ac386cf381f#diff-b66584c9ce7b64019b5db5a531deeda1R207
> The instructions in comments on how to use jemalloc haven't been updated to
> reflect this change. [~snazy], is that an accurate assessment?
> [~iamaleksey] How do we want to handle the deprecation more generally? Warn
> on 2.2, remove in 3.0?
> EDIT: I described this in a way that isn't very clear to those unfamiliar
> with Robert's change. To be clear: You can still use JEMAlloc with Cassandra.
> The {{memory_allocator}} option was deprecated in favor of automatically
> detecting if JEMAlloc is installed, and, if so, using it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8844) Change Data Capture (CDC)
[ https://issues.apache.org/jira/browse/CASSANDRA-8844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joshua McKenzie updated CASSANDRA-8844: --- Component/s: Local Write-Read Paths Coordination > Change Data Capture (CDC) > - > > Key: CASSANDRA-8844 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8844 > Project: Cassandra > Issue Type: New Feature > Components: Coordination, Local Write-Read Paths >Reporter: Tupshin Harper >Assignee: Joshua McKenzie >Priority: Critical > Fix For: 3.x > > > "In databases, change data capture (CDC) is a set of software design patterns > used to determine (and track) the data that has changed so that action can be > taken using the changed data. Also, Change data capture (CDC) is an approach > to data integration that is based on the identification, capture and delivery > of the changes made to enterprise data sources." > -Wikipedia > As Cassandra is increasingly being used as the Source of Record (SoR) for > mission critical data in large enterprises, it is increasingly being called > upon to act as the central hub of traffic and data flow to other systems. In > order to try to address the general need, we (cc [~brianmhess]), propose > implementing a simple data logging mechanism to enable per-table CDC patterns. > h2. The goals: > # Use CQL as the primary ingestion mechanism, in order to leverage its > Consistency Level semantics, and in order to treat it as the single > reliable/durable SoR for the data. > # To provide a mechanism for implementing good and reliable > (deliver-at-least-once with possible mechanisms for deliver-exactly-once ) > continuous semi-realtime feeds of mutations going into a Cassandra cluster. > # To eliminate the developmental and operational burden of users so that they > don't have to do dual writes to other systems. > # For users that are currently doing batch export from a Cassandra system, > give them the opportunity to make that realtime with a minimum of coding. > h2. The mechanism: > We propose a durable logging mechanism that functions similar to a commitlog, > with the following nuances: > - Takes place on every node, not just the coordinator, so RF number of copies > are logged. > - Separate log per table. > - Per-table configuration. Only tables that are specified as CDC_LOG would do > any logging. > - Per DC. We are trying to keep the complexity to a minimum to make this an > easy enhancement, but most likely use cases would prefer to only implement > CDC logging in one (or a subset) of the DCs that are being replicated to > - In the critical path of ConsistencyLevel acknowledgment. Just as with the > commitlog, failure to write to the CDC log should fail that node's write. If > that means the requested consistency level was not met, then clients *should* > experience UnavailableExceptions. > - Be written in a Row-centric manner such that it is easy for consumers to > reconstitute rows atomically. > - Written in a simple format designed to be consumed *directly* by daemons > written in non JVM languages > h2. Nice-to-haves > I strongly suspect that the following features will be asked for, but I also > believe that they can be deferred for a subsequent release, and to guage > actual interest. > - Multiple logs per table. This would make it easy to have multiple > "subscribers" to a single table's changes. A workaround would be to create a > forking daemon listener, but that's not a great answer. > - Log filtering. Being able to apply filters, including UDF-based filters > would make Casandra a much more versatile feeder into other systems, and > again, reduce complexity that would otherwise need to be built into the > daemons. > h2. Format and Consumption > - Cassandra would only write to the CDC log, and never delete from it. > - Cleaning up consumed logfiles would be the client daemon's responibility > - Logfile size should probably be configurable. > - Logfiles should be named with a predictable naming schema, making it > triivial to process them in order. > - Daemons should be able to checkpoint their work, and resume from where they > left off. This means they would have to leave some file artifact in the CDC > log's directory. > - A sophisticated daemon should be able to be written that could > -- Catch up, in written-order, even when it is multiple logfiles behind in > processing > -- Be able to continuously "tail" the most recent logfile and get > low-latency(ms?) access to the data as it is written. > h2. Alternate approach > In order to make consuming a change log easy and efficient to do with low > latency, the following could supplement the approach outlined above > - Instead of writing to a logfile, by default, Cassandra could expose a > socket for a daemon
[jira] [Updated] (CASSANDRA-8895) Compressed sstables should only compress if the win is above a certain threshold, and should use a variable block size
[ https://issues.apache.org/jira/browse/CASSANDRA-8895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-8895: --- Assignee: (was: Paulo Motta) > Compressed sstables should only compress if the win is above a certain > threshold, and should use a variable block size > -- > > Key: CASSANDRA-8895 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8895 > Project: Cassandra > Issue Type: Improvement >Reporter: Benedict > Labels: performance > Fix For: 3.x > > > On performing a flush to disk, we should assess if the data we're flushing > will actually be substantively compressed, and how large the page should be > to get optimal compression ratio versus read latency. Decompressing 64Kb > chunks is wasteful when reading small records. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10604) Secondary index metadata is not reloaded when table is altered
[
https://issues.apache.org/jira/browse/CASSANDRA-10604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14978661#comment-14978661
]
Tyler Hobbs commented on CASSANDRA-10604:
-
+1 on the code changes. The testall failures either don't seem to be related
or are not regressions. Assuming the dtest results look okay, you should be
good to commit.
> Secondary index metadata is not reloaded when table is altered
> --
>
> Key: CASSANDRA-10604
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10604
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Tyler Hobbs
>Assignee: Sam Tunnicliffe
> Fix For: 3.x
>
>
> The javadocs for {{Index.getMetadataReloadTask()}} state the following:
> {quote}
> Returns a task to reload the internal metadata of an index.
> Called when the base table metadata is modified or when the configuration of
> the Index is updated.
> {quote}
> However, altering a table does not result in the reload task being executed.
> I think the root of the problem is that in
> {{SecondaryIndexManager.reloadIndex()}}, we only execute the reload task when
> the old {{IndexMetadata}} does not equal the current {{IndexMetadata}}.
> Altering the table does not change the index metadata, so this check always
> fails.
> This especially affects per-row secondary indexes, where the index may need
> to handle columns being added or dropped.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10605) MessagingService: COUNTER_MUTATION verb is associated with MUTATION stage
[
https://issues.apache.org/jira/browse/CASSANDRA-10605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anubhav Kale updated CASSANDRA-10605:
-
Reproduced In: 3.x (was: 2.1.11)
> MessagingService: COUNTER_MUTATION verb is associated with MUTATION stage
> -
>
> Key: CASSANDRA-10605
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10605
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Anubhav Kale
> Fix For: 2.1.10
>
> Attachments: trunk-10605.patch
>
>
> In MessagingService.java, I see that the verb COUNTER_MUTATION is associated
> with COUNTER_MUTATION stage first, and later with MUTATION stage. We should
> remove appropriate entry.
> I marked this as Major because I think the stage assignment is wrong.
> What should this be assigned to ?
> public static final EnumMap verbStages = new
> EnumMap(MessagingService.Verb.class)
> {{
> put(Verb.MUTATION, Stage.MUTATION);
> put(Verb.COUNTER_MUTATION, Stage.COUNTER_MUTATION);*
> put(Verb.READ_REPAIR, Stage.MUTATION);
> put(Verb.HINT, Stage.MUTATION);
> put(Verb.TRUNCATE, Stage.MUTATION);
> put(Verb.PAXOS_PREPARE, Stage.MUTATION);
> put(Verb.PAXOS_PROPOSE, Stage.MUTATION);
> put(Verb.PAXOS_COMMIT, Stage.MUTATION);
> put(Verb.BATCH_STORE, Stage.MUTATION);
> put(Verb.BATCH_REMOVE, Stage.MUTATION);
> put(Verb.READ, Stage.READ);
> put(Verb.RANGE_SLICE, Stage.READ);
> put(Verb.INDEX_SCAN, Stage.READ);
> put(Verb.PAGED_RANGE, Stage.READ);
> put(Verb.REQUEST_RESPONSE, Stage.REQUEST_RESPONSE);
> put(Verb.INTERNAL_RESPONSE, Stage.INTERNAL_RESPONSE);
> put(Verb.STREAM_REPLY, Stage.MISC); // actually handled by
> FileStreamTask and streamExecutors
> put(Verb.STREAM_REQUEST, Stage.MISC);
> put(Verb.REPLICATION_FINISHED, Stage.MISC);
> put(Verb.SNAPSHOT, Stage.MISC);
> put(Verb.TREE_REQUEST, Stage.ANTI_ENTROPY);
> put(Verb.TREE_RESPONSE, Stage.ANTI_ENTROPY);
> put(Verb.STREAMING_REPAIR_REQUEST, Stage.ANTI_ENTROPY);
> put(Verb.STREAMING_REPAIR_RESPONSE, Stage.ANTI_ENTROPY);
> put(Verb.REPAIR_MESSAGE, Stage.ANTI_ENTROPY);
> put(Verb.GOSSIP_DIGEST_ACK, Stage.GOSSIP);
> put(Verb.GOSSIP_DIGEST_ACK2, Stage.GOSSIP);
> put(Verb.GOSSIP_DIGEST_SYN, Stage.GOSSIP);
> put(Verb.GOSSIP_SHUTDOWN, Stage.GOSSIP);
> put(Verb.DEFINITIONS_UPDATE, Stage.MIGRATION);
> put(Verb.SCHEMA_CHECK, Stage.MIGRATION);
> put(Verb.MIGRATION_REQUEST, Stage.MIGRATION);
> put(Verb.INDEX_SCAN, Stage.READ);
> put(Verb.REPLICATION_FINISHED, Stage.MISC);
> *put(Verb.COUNTER_MUTATION, Stage.MUTATION);**
> put(Verb.SNAPSHOT, Stage.MISC);
> put(Verb.ECHO, Stage.GOSSIP);
> put(Verb.UNUSED_1, Stage.INTERNAL_RESPONSE);
> put(Verb.UNUSED_2, Stage.INTERNAL_RESPONSE);
> put(Verb.UNUSED_3, Stage.INTERNAL_RESPONSE);
> }};
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10605) MessagingService: COUNTER_MUTATION verb is associated with MUTATION stage
[
https://issues.apache.org/jira/browse/CASSANDRA-10605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anubhav Kale updated CASSANDRA-10605:
-
Priority: Major (was: Minor)
> MessagingService: COUNTER_MUTATION verb is associated with MUTATION stage
> -
>
> Key: CASSANDRA-10605
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10605
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Anubhav Kale
> Fix For: 2.1.10
>
> Attachments: trunk-10605.patch
>
>
> In MessagingService.java, I see that the verb COUNTER_MUTATION is associated
> with COUNTER_MUTATION stage first, and later with MUTATION stage. We should
> remove appropriate entry.
> I marked this as Major because I think the stage assignment is wrong.
> What should this be assigned to ?
> public static final EnumMap verbStages = new
> EnumMap(MessagingService.Verb.class)
> {{
> put(Verb.MUTATION, Stage.MUTATION);
> put(Verb.COUNTER_MUTATION, Stage.COUNTER_MUTATION);*
> put(Verb.READ_REPAIR, Stage.MUTATION);
> put(Verb.HINT, Stage.MUTATION);
> put(Verb.TRUNCATE, Stage.MUTATION);
> put(Verb.PAXOS_PREPARE, Stage.MUTATION);
> put(Verb.PAXOS_PROPOSE, Stage.MUTATION);
> put(Verb.PAXOS_COMMIT, Stage.MUTATION);
> put(Verb.BATCH_STORE, Stage.MUTATION);
> put(Verb.BATCH_REMOVE, Stage.MUTATION);
> put(Verb.READ, Stage.READ);
> put(Verb.RANGE_SLICE, Stage.READ);
> put(Verb.INDEX_SCAN, Stage.READ);
> put(Verb.PAGED_RANGE, Stage.READ);
> put(Verb.REQUEST_RESPONSE, Stage.REQUEST_RESPONSE);
> put(Verb.INTERNAL_RESPONSE, Stage.INTERNAL_RESPONSE);
> put(Verb.STREAM_REPLY, Stage.MISC); // actually handled by
> FileStreamTask and streamExecutors
> put(Verb.STREAM_REQUEST, Stage.MISC);
> put(Verb.REPLICATION_FINISHED, Stage.MISC);
> put(Verb.SNAPSHOT, Stage.MISC);
> put(Verb.TREE_REQUEST, Stage.ANTI_ENTROPY);
> put(Verb.TREE_RESPONSE, Stage.ANTI_ENTROPY);
> put(Verb.STREAMING_REPAIR_REQUEST, Stage.ANTI_ENTROPY);
> put(Verb.STREAMING_REPAIR_RESPONSE, Stage.ANTI_ENTROPY);
> put(Verb.REPAIR_MESSAGE, Stage.ANTI_ENTROPY);
> put(Verb.GOSSIP_DIGEST_ACK, Stage.GOSSIP);
> put(Verb.GOSSIP_DIGEST_ACK2, Stage.GOSSIP);
> put(Verb.GOSSIP_DIGEST_SYN, Stage.GOSSIP);
> put(Verb.GOSSIP_SHUTDOWN, Stage.GOSSIP);
> put(Verb.DEFINITIONS_UPDATE, Stage.MIGRATION);
> put(Verb.SCHEMA_CHECK, Stage.MIGRATION);
> put(Verb.MIGRATION_REQUEST, Stage.MIGRATION);
> put(Verb.INDEX_SCAN, Stage.READ);
> put(Verb.REPLICATION_FINISHED, Stage.MISC);
> *put(Verb.COUNTER_MUTATION, Stage.MUTATION);**
> put(Verb.SNAPSHOT, Stage.MISC);
> put(Verb.ECHO, Stage.GOSSIP);
> put(Verb.UNUSED_1, Stage.INTERNAL_RESPONSE);
> put(Verb.UNUSED_2, Stage.INTERNAL_RESPONSE);
> put(Verb.UNUSED_3, Stage.INTERNAL_RESPONSE);
> }};
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10365) Consider storing types by their CQL names in schema tables instead of fully-qualified internal class names
[ https://issues.apache.org/jira/browse/CASSANDRA-10365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14978622#comment-14978622 ] Adam Holmberg commented on CASSANDRA-10365: --- Repeating here for additional contributors. Python dev branch for this is [422|https://github.com/datastax/python-driver/tree/422] - Requires CASSANDRA-10513 patch for use with cqlsh - Still testing functionality outside of metadata integration > Consider storing types by their CQL names in schema tables instead of > fully-qualified internal class names > -- > > Key: CASSANDRA-10365 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10365 > Project: Cassandra > Issue Type: Improvement >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko > Labels: client-impacting > Fix For: 3.0.0 > > > Consider saving CQL types names for column, UDF/UDA arguments and return > types, and UDT components. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10576) Thrift CAS on static columns doesn't work as expected
[
https://issues.apache.org/jira/browse/CASSANDRA-10576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14978604#comment-14978604
]
Sylvain Lebresne commented on CASSANDRA-10576:
--
+1
Nit: in {{ThriftCasRequest}}, there is 2 places where we do {{if (expected ==
null || expected.isEmpty())}}: we can ditch the {{expected == null}} now.
> Thrift CAS on static columns doesn't work as expected
> -
>
> Key: CASSANDRA-10576
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10576
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
> Fix For: 3.0.0
>
>
> Although the thrift cas call works as expected for dynamic column families,
> using it on tables with statically defined columns produces unexpected
> results. The problem, in {{ThriftCASRequest}}, is that while the {{expected}}
> partition contains a static row, the {{current}} partition has been processed
> by {{ThriftResultsMerger}} during the read, converting the static columns to
> clusterings. If {{expected}} contains only a static row, no further checking
> is carried out, {{appliesTo}} erroneously returns true and the conditional
> update is performed regardless of the current state of the partition.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10606) PartitionUpdate.operationCount() return the wrong number of operation for compact tables
[
https://issues.apache.org/jira/browse/CASSANDRA-10606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joshua McKenzie updated CASSANDRA-10606:
Reviewer: Sylvain Lebresne
> PartitionUpdate.operationCount() return the wrong number of operation for
> compact tables
>
>
> Key: CASSANDRA-10606
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10606
> Project: Cassandra
> Issue Type: Bug
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
> Fix For: 3.0.0
>
> Attachments: 10606-3.0-V2.txt, 10606-3.0-V3.txt, 10606-3.0.txt
>
>
> For compact tables {{PartitionUpdate.operationCount()}} return the wrong
> number of operation as it does not take into operation on static rows.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10608) Adding a dynamic column to a compact storage table with the same name as the partition key causes a memtable flush deadlock
[
https://issues.apache.org/jira/browse/CASSANDRA-10608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joshua McKenzie updated CASSANDRA-10608:
Reviewer: T Jake Luciani
> Adding a dynamic column to a compact storage table with the same name as the
> partition key causes a memtable flush deadlock
> ---
>
> Key: CASSANDRA-10608
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10608
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Mike Adamson
>Assignee: Mike Adamson
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: 10608.txt
>
>
> The reproduction steps for this are as follows:
> # Create the following schema:
> {noformat}
> CREATE KEYSPACE ks WITH replication = { 'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> CREATE TABLE ks.cf (k int, v int, PRIMARY KEY(k)) WITH COMPACT STORAGE;
> {noformat}
> # Using the thrift client execute the following:
> {noformat}
> Column column = new Column(ByteBufferUtil.bytes("k"));
> column.setValue(ByteBufferUtil.bytes(1));
> column.setTimestamp(1);
> client.insert(key, new ColumnParent(compactCf), column,
> ConsistencyLevel.ONE);
> {noformat}
> This causes an invalid {{PartitionUpdate}} to be added to {{Memtable}}
> containing a {{PartitionColumns}} containing the partition key
> {{ColumnDefinition}}.
> This happens because {{LegacyLayout.decodeCellName}} does not check whether
> the {{ColumnDefinition}} is a partition key
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[2/2] cassandra git commit: Merge branch 'cassandra-3.0' into trunk
Merge branch 'cassandra-3.0' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9be01e34 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9be01e34 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9be01e34 Branch: refs/heads/trunk Commit: 9be01e34c8adaa9558458e864969d22b05cb8e87 Parents: 30d5b65 4d00468 Author: Sylvain Lebresne Authored: Wed Oct 28 16:14:10 2015 +0100 Committer: Sylvain Lebresne Committed: Wed Oct 28 16:14:10 2015 +0100 -- CHANGES.txt| 1 + .../apache/cassandra/thrift/CassandraServer.java | 17 +++-- 2 files changed, 16 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/9be01e34/CHANGES.txt -- diff --cc CHANGES.txt index 5f3abbe,3423a1e..04cefae --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,10 -1,5 +1,11 @@@ +3.2 + * Added graphing option to cassandra-stress (CASSANDRA-7918) + * Abort in-progress queries that time out (CASSANDRA-7392) + * Add transparent data encryption core classes (CASSANDRA-9945) + + 3.0 + * Fix thrift get() queries with defined columns (CASSANDRA-10586) * Fix marking of indexes as built and removed (CASSANDRA-10601) * Skip initialization of non-registered 2i instances, remove Index::getIndexName (CASSANDRA-10595) * Fix batches on multiple tables (CASSANDRA-10554)
[1/2] cassandra git commit: Fix thrift get() when reading regular columns
Repository: cassandra
Updated Branches:
refs/heads/trunk 30d5b6543 -> 9be01e34c
Fix thrift get() when reading regular columns
patch by slebresne; reviewed by iamaleksey for CASSANDRA-10586
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/4d00468c
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/4d00468c
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/4d00468c
Branch: refs/heads/trunk
Commit: 4d00468cc38014ed1bd7f9da93ef3a339682f7c1
Parents: 6903727
Author: Sylvain Lebresne
Authored: Tue Oct 27 14:46:56 2015 +0100
Committer: Sylvain Lebresne
Committed: Wed Oct 28 16:10:51 2015 +0100
--
CHANGES.txt| 1 +
.../apache/cassandra/thrift/CassandraServer.java | 17 +++--
2 files changed, 16 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4d00468c/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index b4cc43b..3423a1e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
3.0
+ * Fix thrift get() queries with defined columns (CASSANDRA-10586)
* Fix marking of indexes as built and removed (CASSANDRA-10601)
* Skip initialization of non-registered 2i instances, remove
Index::getIndexName (CASSANDRA-10595)
* Fix batches on multiple tables (CASSANDRA-10554)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4d00468c/src/java/org/apache/cassandra/thrift/CassandraServer.java
--
diff --git a/src/java/org/apache/cassandra/thrift/CassandraServer.java
b/src/java/org/apache/cassandra/thrift/CassandraServer.java
index 538d128..2a3f73d 100644
--- a/src/java/org/apache/cassandra/thrift/CassandraServer.java
+++ b/src/java/org/apache/cassandra/thrift/CassandraServer.java
@@ -623,8 +623,21 @@ public class CassandraServer implements Cassandra.Iface
else
{
LegacyLayout.LegacyCellName cellname =
LegacyLayout.decodeCellName(metadata, column_path.super_column,
column_path.column);
-columns =
ColumnFilter.selection(PartitionColumns.of(cellname.column));
-filter = new
ClusteringIndexNamesFilter(FBUtilities.singleton(cellname.clustering,
metadata.comparator), false);
+if (cellname.clustering == Clustering.STATIC_CLUSTERING)
+{
+// Same as above: even if we're querying a static column,
we still query the equivalent dynamic column and value as some
+// values might have been created post creation of the
column (ThriftResultMerger then ensures we get only one result).
+ColumnFilter.Builder builder =
ColumnFilter.selectionBuilder();
+builder.add(cellname.column);
+builder.add(metadata.compactValueColumn());
+columns = builder.build();
+filter = new
ClusteringIndexNamesFilter(FBUtilities.singleton(new
Clustering(column_path.column), metadata.comparator), false);
+}
+else
+{
+columns =
ColumnFilter.selection(PartitionColumns.of(cellname.column));
+filter = new
ClusteringIndexNamesFilter(FBUtilities.singleton(cellname.clustering,
metadata.comparator), false);
+}
}
DecoratedKey dk = metadata.decorateKey(key);
cassandra git commit: Fix thrift get() when reading regular columns
Repository: cassandra
Updated Branches:
refs/heads/cassandra-3.0 690372755 -> 4d00468cc
Fix thrift get() when reading regular columns
patch by slebresne; reviewed by iamaleksey for CASSANDRA-10586
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/4d00468c
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/4d00468c
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/4d00468c
Branch: refs/heads/cassandra-3.0
Commit: 4d00468cc38014ed1bd7f9da93ef3a339682f7c1
Parents: 6903727
Author: Sylvain Lebresne
Authored: Tue Oct 27 14:46:56 2015 +0100
Committer: Sylvain Lebresne
Committed: Wed Oct 28 16:10:51 2015 +0100
--
CHANGES.txt| 1 +
.../apache/cassandra/thrift/CassandraServer.java | 17 +++--
2 files changed, 16 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4d00468c/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index b4cc43b..3423a1e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
3.0
+ * Fix thrift get() queries with defined columns (CASSANDRA-10586)
* Fix marking of indexes as built and removed (CASSANDRA-10601)
* Skip initialization of non-registered 2i instances, remove
Index::getIndexName (CASSANDRA-10595)
* Fix batches on multiple tables (CASSANDRA-10554)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4d00468c/src/java/org/apache/cassandra/thrift/CassandraServer.java
--
diff --git a/src/java/org/apache/cassandra/thrift/CassandraServer.java
b/src/java/org/apache/cassandra/thrift/CassandraServer.java
index 538d128..2a3f73d 100644
--- a/src/java/org/apache/cassandra/thrift/CassandraServer.java
+++ b/src/java/org/apache/cassandra/thrift/CassandraServer.java
@@ -623,8 +623,21 @@ public class CassandraServer implements Cassandra.Iface
else
{
LegacyLayout.LegacyCellName cellname =
LegacyLayout.decodeCellName(metadata, column_path.super_column,
column_path.column);
-columns =
ColumnFilter.selection(PartitionColumns.of(cellname.column));
-filter = new
ClusteringIndexNamesFilter(FBUtilities.singleton(cellname.clustering,
metadata.comparator), false);
+if (cellname.clustering == Clustering.STATIC_CLUSTERING)
+{
+// Same as above: even if we're querying a static column,
we still query the equivalent dynamic column and value as some
+// values might have been created post creation of the
column (ThriftResultMerger then ensures we get only one result).
+ColumnFilter.Builder builder =
ColumnFilter.selectionBuilder();
+builder.add(cellname.column);
+builder.add(metadata.compactValueColumn());
+columns = builder.build();
+filter = new
ClusteringIndexNamesFilter(FBUtilities.singleton(new
Clustering(column_path.column), metadata.comparator), false);
+}
+else
+{
+columns =
ColumnFilter.selection(PartitionColumns.of(cellname.column));
+filter = new
ClusteringIndexNamesFilter(FBUtilities.singleton(cellname.clustering,
metadata.comparator), false);
+}
}
DecoratedKey dk = metadata.decorateKey(key);
[jira] [Created] (CASSANDRA-10613) Upgrade test on 2.1->3.0 path fails with NPE in getExistingFiles (likely known bug)
Jim Witschey created CASSANDRA-10613:
Summary: Upgrade test on 2.1->3.0 path fails with NPE in
getExistingFiles (likely known bug)
Key: CASSANDRA-10613
URL: https://issues.apache.org/jira/browse/CASSANDRA-10613
Project: Cassandra
Issue Type: Sub-task
Reporter: Jim Witschey
Assignee: Russ Hatch
In this job:
http://cassci.datastax.com/view/Upgrades/job/cassandra_upgrade_2.1_to_3.0_proto_v3/10/
The following tests fail due to an NPE in
{{org.apache.cassandra.db.lifecycle.LogRecord.getExistingFiles}}:
upgrade_through_versions_test.py:TestUpgrade_from_3_0_latest_tag_to_3_0_HEAD.bootstrap_test
upgrade_through_versions_test.py:TestUpgrade_from_3_0_latest_tag_to_3_0_HEAD.rolling_upgrade_test
upgrade_through_versions_test.py:TestUpgrade_from_3_0_latest_tag_to_3_0_HEAD.parallel_upgrade_with_internode_ssl_test
upgrade_through_versions_test.py:TestUpgrade_from_3_0_latest_tag_to_3_0_HEAD.rolling_upgrade_with_internode_ssl_test
upgrade_through_versions_test.py:TestUpgrade_from_cassandra_2_1_HEAD_to_cassandra_3_0_HEAD.rolling_upgrade_with_internode_ssl_test
upgrade_through_versions_test.py:TestUpgrade_from_3_0_latest_tag_to_3_0_HEAD.parallel_upgrade_test
I believe this is likely happening because of CASSANDRA-10602, so let's hold
off on messing with this until that's merged.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10365) Consider storing types by their CQL names in schema tables instead of fully-qualified internal class names
[ https://issues.apache.org/jira/browse/CASSANDRA-10365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14978555#comment-14978555 ] Aleksey Yeschenko commented on CASSANDRA-10365: --- bq. Curious if you have given any thought to storing system_schema.aggregates.initcond as a text CQL literal. This is the only thing I have come across in my integration thus far that requires the client to parse types in order to reproduce DDL. [~snazy] was kind enough to volunteer to deal with that bit of the ticket - will most likely be done tomorrow, no objections. > Consider storing types by their CQL names in schema tables instead of > fully-qualified internal class names > -- > > Key: CASSANDRA-10365 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10365 > Project: Cassandra > Issue Type: Improvement >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko > Labels: client-impacting > Fix For: 3.0.0 > > > Consider saving CQL types names for column, UDF/UDA arguments and return > types, and UDT components. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-10612) Protocol v3 upgrade tests on 2.1->3.0 path fail when compaction is interrupted
Jim Witschey created CASSANDRA-10612:
Summary: Protocol v3 upgrade tests on 2.1->3.0 path fail when
compaction is interrupted
Key: CASSANDRA-10612
URL: https://issues.apache.org/jira/browse/CASSANDRA-10612
Project: Cassandra
Issue Type: Sub-task
Reporter: Jim Witschey
Assignee: Russ Hatch
The following tests in the upgrade_through_versions dtest suite fail:
*
upgrade_through_versions_test.py:TestRandomPartitionerUpgrade.rolling_upgrade_test
*
upgrade_through_versions_test.py:TestRandomPartitionerUpgrade.rolling_upgrade_with_internode_ssl_test
*
upgrade_through_versions_test.py:TestUpgradeThroughVersions.rolling_upgrade_with_internode_ssl_test
*
upgrade_through_versions_test.py:TestUpgradeThroughVersions.rolling_upgrade_test
*
upgrade_through_versions_test.py:TestUpgrade_from_2_1_latest_tag_to_cassandra_3_0_HEAD.rolling_upgrade_test
*
upgrade_through_versions_test.py:TestUpgrade_from_2_1_latest_tag_to_cassandra_3_0_HEAD.rolling_upgrade_with_internode_ssl_test
*
upgrade_through_versions_test.py:TestUpgrade_from_cassandra_2_1_HEAD_to_cassandra_3_0_latest_tag.rolling_upgrade_test
*
upgrade_through_versions_test.py:TestUpgrade_from_cassandra_2_1_HEAD_to_cassandra_3_0_latest_tag.rolling_upgrade_with_internode_ssl_test
*
upgrade_through_versions_test.py:TestUpgrade_from_cassandra_2_1_HEAD_to_cassandra_3_0_HEAD.rolling_upgrade_test
See this report:
http://cassci.datastax.com/view/Upgrades/job/cassandra_upgrade_2.1_to_3.0_proto_v3/10/testReport/
They fail with the following error:
{code}
A subprocess has terminated early. Subprocess statuses: Process-41 (is_alive:
True), Process-42 (is_alive: False), Process-43 (is_alive: True), Process-44
(is_alive: False), attempting to terminate remaining subprocesses now.
{code}
and with logs that look like this:
{code}
Unexpected error in node1 node log: ['ERROR [SecondaryIndexManagement:1]
2015-10-27 00:06:52,335 CassandraDaemon.java:195 - Exception in thread
Thread[SecondaryIndexManagement:1,5,main] java.lang.RuntimeException:
java.util.concurrent.ExecutionException:
org.apache.cassandra.db.compaction.CompactionInterruptedException: Compaction
interrupted: Secondary index
build@41202370-7c3e-11e5-9331-6bb6e58f8b1b(upgrade, cf, 578160/1663620)bytes
at org.apache.cassandra.utils.FBUtilities.waitOnFuture(FBUtilities.java:368)
~[main/:na]
at
org.apache.cassandra.index.internal.CassandraIndex.buildBlocking(CassandraIndex.java:688)
~[main/:na]
at
org.apache.cassandra.index.internal.CassandraIndex.lambda$getBuildIndexTask$206(CassandraIndex.java:658)
~[main/:na]
at
org.apache.cassandra.index.internal.CassandraIndex$$Lambda$151/1841229245.call(Unknown
Source) ~[na:na]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[na:1.8.0_51]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
~[na:1.8.0_51]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[na:1.8.0_51]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_51] Caused by:
java.util.concurrent.ExecutionException:
org.apache.cassandra.db.compaction.CompactionInterruptedException: Compaction
interrupted: Secondary index
build@41202370-7c3e-11e5-9331-6bb6e58f8b1b(upgrade, cf,
578160/{code}1663620)bytes
at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[na:1.8.0_51]
at java.util.concurrent.FutureTask.get(FutureTask.java:192) ~[na:1.8.0_51]
at org.apache.cassandra.utils.FBUtilities.waitOnFuture(FBUtilities.java:364)
~[main/:na]
... 7 common frames omitted Caused by:
org.apache.cassandra.db.compaction.CompactionInterruptedException: Compaction
interrupted: Secondary index
build@41202370-7c3e-11e5-9331-6bb6e58f8b1b(upgrade, cf, 578160/1663620)bytes
at
org.apache.cassandra.index.SecondaryIndexBuilder.build(SecondaryIndexBuilder.java:67)
~[main/:na]
at
org.apache.cassandra.db.compaction.CompactionManager$11.run(CompactionManager.java:1269)
~[main/:na]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
~[na:1.8.0_51]
... 4 common frames omitted', 'ERROR [HintsDispatcher:2] 2015-10-27
00:08:48,520 CassandraDaemon.java:195 - Exception in thread
Thread[HintsDispatcher:2,1,main]', 'ERROR [HintsDispatcher:2] 2015-10-27
00:11:58,336 CassandraDaemon.java:195 - Exception in thread
Thread[HintsDispatcher:2,1,main]']
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10586) thrift get on compact storage table broken
[
https://issues.apache.org/jira/browse/CASSANDRA-10586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14978529#comment-14978529
]
Aleksey Yeschenko commented on CASSANDRA-10586:
---
+1
> thrift get on compact storage table broken
> --
>
> Key: CASSANDRA-10586
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10586
> Project: Cassandra
> Issue Type: Sub-task
> Components: Core
>Reporter: Jeremiah Jordan
>Assignee: Sylvain Lebresne
>Priority: Critical
> Fix For: 3.0.0
>
>
> dtest here that triggers the issue:
> https://github.com/riptano/cassandra-dtest/pull/629
> {code}
> class TestCompactStorageThriftAccesses(ThriftTester):
> def test_get(self):
> node1, = self.cluster.nodelist()
> session = self.patient_cql_connection(node1)
> # Create a CQL table with a static column and insert a row
> session.execute("USE \"Keyspace1\"");
> session.execute("CREATE TABLE IF NOT EXISTS cs1 (k int PRIMARY KEY,v
> int) WITH COMPACT STORAGE");
> _set_keyspace('Keyspace1')
> CL = ConsistencyLevel.ONE
> i=1
> client.insert(_i32(i), ColumnParent('cs1'), Column('v', _i32(i), 0),
> CL)
> _assert_column('cs1', _i32(i), 'v', _i32(i), 0)
> {code}
> {noformat}
> $ CASSANDRA_DIR=../cassandra nosetests
> thrift_tests:TestCompactStorageThriftAccesses
> EE
> ==
> ERROR: test_get (thrift_tests.TestCompactStorageThriftAccesses)
> --
> Traceback (most recent call last):
> File "/Users/jeremiah/github/cassandra-dtest/thrift_tests.py", line 2342,
> in test_get
> _assert_column('cs1', _i32(i), 'v', _i32(i), 0)
> File "/Users/jeremiah/github/cassandra-dtest/thrift_tests.py", line 138, in
> _assert_column
> assert client.get(key, ColumnPath(column_family, column=column),
> ConsistencyLevel.ONE).column == Column(column, value, ts)
> File
> "/Users/jeremiah/github/cassandra-dtest/thrift_bindings/v22/Cassandra.py",
> line 585, in get
> return self.recv_get()
> File
> "/Users/jeremiah/github/cassandra-dtest/thrift_bindings/v22/Cassandra.py",
> line 598, in recv_get
> (fname, mtype, rseqid) = self._iprot.readMessageBegin()
> File
> "/Users/jeremiah/.virtualenvs/py27/lib/python2.7/site-packages/thrift/protocol/TBinaryProtocol.py",
> line 126, in readMessageBegin
> sz = self.readI32()
> File
> "/Users/jeremiah/.virtualenvs/py27/lib/python2.7/site-packages/thrift/protocol/TBinaryProtocol.py",
> line 206, in readI32
> buff = self.trans.readAll(4)
> File
> "/Users/jeremiah/.virtualenvs/py27/lib/python2.7/site-packages/thrift/transport/TTransport.py",
> line 58, in readAll
> chunk = self.read(sz - have)
> File
> "/Users/jeremiah/.virtualenvs/py27/lib/python2.7/site-packages/thrift/transport/TTransport.py",
> line 276, in read
> self.readFrame()
> File
> "/Users/jeremiah/.virtualenvs/py27/lib/python2.7/site-packages/thrift/transport/TTransport.py",
> line 280, in readFrame
> buff = self.__trans.readAll(4)
> File
> "/Users/jeremiah/.virtualenvs/py27/lib/python2.7/site-packages/thrift/transport/TTransport.py",
> line 58, in readAll
> chunk = self.read(sz - have)
> File
> "/Users/jeremiah/.virtualenvs/py27/lib/python2.7/site-packages/thrift/transport/TSocket.py",
> line 120, in read
> message='TSocket read 0 bytes')
> TTransportException: TSocket read 0 bytes
> >> begin captured stdout << -
> [node1 ERROR] objc[10539]: Class JavaLaunchHelper is implemented in both
> /Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home//bin/java and
> /Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/jre/lib/libinstrument.dylib.
> One of the two will be used. Which one is undefined.
> - >> end captured stdout << --
> >> begin captured logging <<
> dtest: DEBUG: cluster ccm directory:
> /var/folders/t4/rlc2b6450qbg92762l9l4mt8gn/T/dtest-HtfTkF
> - >> end captured logging << -
> ==
> ERROR: test_get (thrift_tests.TestCompactStorageThriftAccesses)
> --
> Traceback (most recent call last):
> File "/Users/jeremiah/github/cassandra-dtest/dtest.py", line 550, in
> tearDown
> raise AssertionError('Unexpected error in %s node log: %s' % (node.name,
> errors))
> AssertionError: Unexpected error in node1 node log: ['ERROR [Thrift:1]
> 2015-10-24 02:50:02,460 CassandraDaemon.java:195 - Exception in thread
[jira] [Created] (CASSANDRA-10611) Upgrade test on 2.1->3.0 path fails with configuration problems
Jim Witschey created CASSANDRA-10611:
Summary: Upgrade test on 2.1->3.0 path fails with configuration
problems
Key: CASSANDRA-10611
URL: https://issues.apache.org/jira/browse/CASSANDRA-10611
Project: Cassandra
Issue Type: Sub-task
Reporter: Jim Witschey
Assignee: Russ Hatch
The following test fails on the uprgrade path from 2.1 to 3.0:
http://cassci.datastax.com/view/Upgrades/job/cassandra_upgrade_2.1_to_3.0_proto_v3/10/testReport/upgrade_through_versions_test/TestUpgrade_from_3_0_latest_tag_to_3_0_HEAD/bootstrap_multidc_test/
I believe it's basically a configuration error; the cluster likely just needs
to be reconfigured in the test:
{code}
code=2200 [Invalid query] message="User-defined functions are disabled in
cassandra.yaml - set enable_user_defined_functions=true to enable"
{code}
Assigning to [~rhatch] for now.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10608) Adding a dynamic column to a compact storage table with the same name as the partition key causes a memtable flush deadlock
[
https://issues.apache.org/jira/browse/CASSANDRA-10608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Adamson updated CASSANDRA-10608:
-
Attachment: 10608.txt
> Adding a dynamic column to a compact storage table with the same name as the
> partition key causes a memtable flush deadlock
> ---
>
> Key: CASSANDRA-10608
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10608
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Mike Adamson
>Assignee: Mike Adamson
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: 10608.txt
>
>
> The reproduction steps for this are as follows:
> # Create the following schema:
> {noformat}
> CREATE KEYSPACE ks WITH replication = { 'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> CREATE TABLE ks.cf (k int, v int, PRIMARY KEY(k)) WITH COMPACT STORAGE;
> {noformat}
> # Using the thrift client execute the following:
> {noformat}
> Column column = new Column(ByteBufferUtil.bytes("k"));
> column.setValue(ByteBufferUtil.bytes(1));
> column.setTimestamp(1);
> client.insert(key, new ColumnParent(compactCf), column,
> ConsistencyLevel.ONE);
> {noformat}
> This causes an invalid {{PartitionUpdate}} to be added to {{Memtable}}
> containing a {{PartitionColumns}} containing the partition key
> {{ColumnDefinition}}.
> This happens because {{LegacyLayout.decodeCellName}} does not check whether
> the {{ColumnDefinition}} is a partition key
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10365) Consider storing types by their CQL names in schema tables instead of fully-qualified internal class names
[ https://issues.apache.org/jira/browse/CASSANDRA-10365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14978507#comment-14978507 ] Aleksey Yeschenko commented on CASSANDRA-10365: --- Force-pushed updates to the same branch. Everything besides UDTs that refer to other UDTs should work now (except maybe certain parts of UDFs/UDAs, but I need the driver fixed first to verify them). Otherwise the last remaining bits is cross-UDT dependencies. Finalising that, will push soon-ish. > Consider storing types by their CQL names in schema tables instead of > fully-qualified internal class names > -- > > Key: CASSANDRA-10365 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10365 > Project: Cassandra > Issue Type: Improvement >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko > Labels: client-impacting > Fix For: 3.0.0 > > > Consider saving CQL types names for column, UDF/UDA arguments and return > types, and UDT components. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10513) Update cqlsh for new driver execution API
[
https://issues.apache.org/jira/browse/CASSANDRA-10513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14978485#comment-14978485
]
Paulo Motta commented on CASSANDRA-10513:
-
* Added new
[commit|https://github.com/apache/cassandra/commit/c3b58a2925780388d3ee7b9db30e3792edb2351b]
fixing table metadata access on {{cqlsh.py}}.
* Created cassandra-dtest
[PR|https://github.com/riptano/cassandra-dtest/pull/631] with simple fix on
index tests.
* Submitted new test runs:
||2.2||3.0||trunk||
|[branch|https://github.com/apache/cassandra/compare/cassandra-2.2...pauloricardomg:2.2-10513]|[branch|https://github.com/apache/cassandra/compare/cassandra-3.0...pauloricardomg:3.0-10513]|[branch|https://github.com/apache/cassandra/compare/trunk...pauloricardomg:trunk-10513]|
|[dtests|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-2.2-10513-dtest/lastCompletedBuild/testReport/]|[dtests|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-3.0-10513-dtest/lastCompletedBuild/testReport/]|[dtests|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-trunk-10513-dtest/lastCompletedBuild/testReport/]|
> Update cqlsh for new driver execution API
> -
>
> Key: CASSANDRA-10513
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10513
> Project: Cassandra
> Issue Type: New Feature
> Components: Tools
>Reporter: Adam Holmberg
>Assignee: Paulo Motta
>Priority: Minor
> Labels: cqlsh
> Fix For: 2.2.x, 3.0.x
>
> Attachments: 10513-2.1.txt, 10513-2.2.txt, 10513.txt
>
>
> The 3.0 Python driver will have a few tweaks to the execution API. We'll need
> to update cqlsh in a couple of minor ways.
> [Results are always returned as an iterable
> ResultSet|https://datastax-oss.atlassian.net/browse/PYTHON-368]
> [Trace data is always attached to the
> ResultSet|https://datastax-oss.atlassian.net/browse/PYTHON-318] (instead of
> being attached to a statement)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-9664) Allow MV's select statements to be more complex
[
https://issues.apache.org/jira/browse/CASSANDRA-9664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Boudreault resolved CASSANDRA-9664.
Resolution: Fixed
Closing in favor of CASSANDRA-10609.
> Allow MV's select statements to be more complex
> ---
>
> Key: CASSANDRA-9664
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9664
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Carl Yeksigian
>Assignee: Tyler Hobbs
> Labels: client-impacting, doc-impacting
> Fix For: 3.0.0 rc1
>
>
> [Materialized Views|https://issues.apache.org/jira/browse/CASSANDRA-6477] add
> support for a syntax which includes a {{SELECT}} statement, but only allows
> selection of direct columns, and does not allow any filtering to take place.
> We should add support to the MV {{SELECT}} statement to bring better parity
> with the normal CQL {{SELECT}} statement, specifically simple functions in
> the selected columns, as well as specifying a {{WHERE}} clause.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-10610) Protocol upgrade tests for bootstrapping failing on 2.1->3.0 path
Jim Witschey created CASSANDRA-10610:
Summary: Protocol upgrade tests for bootstrapping failing on
2.1->3.0 path
Key: CASSANDRA-10610
URL: https://issues.apache.org/jira/browse/CASSANDRA-10610
Project: Cassandra
Issue Type: Sub-task
Reporter: Jim Witschey
Assignee: Russ Hatch
This ticket is for a couple failures on protocol v3 upgrade test job on CassCI:
http://cassci.datastax.com/view/Upgrades/job/cassandra_upgrade_2.1_to_3.0_proto_v3/10/testReport/
The failures are:
*
[upgrade_through_versions_test.py:TestUpgrade_from_cassandra_2_1_HEAD_to_cassandra_3_0_HEAD.bootstrap_multidc_test|http://cassci.datastax.com/view/Upgrades/job/cassandra_upgrade_2.1_to_3.0_proto_v3/10/testReport/upgrade_through_versions_test/TestUpgrade_from_cassandra_2_1_HEAD_to_cassandra_3_0_HEAD/bootstrap_multidc_test/]
*
[upgrade_through_versions_test.py:TestUpgrade_from_cassandra_2_1_HEAD_to_cassandra_3_0_latest_tag.bootstrap_multidc_test|http://cassci.datastax.com/view/Upgrades/job/cassandra_upgrade_2.1_to_3.0_proto_v3/10/testReport/upgrade_through_versions_test/TestUpgrade_from_cassandra_2_1_HEAD_to_cassandra_3_0_latest_tag/bootstrap_multidc_test/]
They fail with the following error:
{code}
code=1000 [Unavailable exception] message="Cannot achieve consistency level
ALL" info={'required_replicas': 3, 'alive_replicas': 0, 'consistency': 'ALL'}
{code}
Assigning [~rhatch], since you're the most likely to understand what's going on
here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
