[jira] [Created] (CASSANDRA-13956) Cannot restrict columns on materialized view
Chema Vinacua created CASSANDRA-13956: - Summary: Cannot restrict columns on materialized view Key: CASSANDRA-13956 URL: https://issues.apache.org/jira/browse/CASSANDRA-13956 Project: Cassandra Issue Type: Bug Components: Materialized Views Environment: [cqlsh 5.0.1 | Cassandra 3.11.1 | CQL spec 3.4.4 | Native protocol v4] Reporter: Chema Vinacua Fix For: 3.11.1 After upgrading from 3.11.0 to 3.11.1 I cannot define materialized views restricted on non primary key columns. I get: InvalidRequest: Error from server: code=2200 [Invalid query] message="Non-primary key columns cannot be restricted in the SELECT statement used for materialized view creation (got restrictions on: d_destination_set)" In my 3.11.0 cluster: $ cqlsh ** Connected to Test Cluster at :9042. [cqlsh 5.0.1 | Cassandra 3.11.0 | CQL spec 3.4.4 | Native protocol v4] Use HELP for help. cqlsh> CREATE TABLE phoenix.test_table ( ... datetime_bucket ascii primary key, ... d_destination_set boolean, ... d_destination_timestamp timestamp ... ); cqlsh> CREATE MATERIALIZED VIEW phoenix.test_view AS ... SELECT datetime_bucket, ... d_destination_set ... FROM phoenix.test_table ... WHERE datetime_bucket IS NOT NULL ... AND d_destination_set = FALSE ... PRIMARY KEY (datetime_bucket, d_destination_set); cqlsh> No errors shown here. In my 3.11.1 cluster: cqlsh> CREATE TABLE phoenix.test_table ( ... datetime_bucket ascii primary key, ... d_destination_set boolean, ... d_destination_timestamp timestamp ... ); cqlsh> CREATE MATERIALIZED VIEW phoenix.test_view AS ... SELECT datetime_bucket, ... d_destination_set ... FROM phoenix.test_table ... WHERE datetime_bucket IS NOT NULL ... AND d_destination_set = FALSE ... PRIMARY KEY (datetime_bucket, d_destination_set); InvalidRequest: Error from server: code=2200 [Invalid query] message="Non-primary key columns cannot be restricted in the SELECT statement used for materialized view creation (got restrictions on: d_destination_set)" -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13956) Cannot restrict columns on materialized view
[ https://issues.apache.org/jira/browse/CASSANDRA-13956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16205669#comment-16205669 ] Kurt Greaves commented on CASSANDRA-13956: -- See CASSANDRA-13798. This was done on purpose. If you absolutely do need it and can handle potential problems, there is a JVM property you can set to enable this functionality. > Cannot restrict columns on materialized view > > > Key: CASSANDRA-13956 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13956 > Project: Cassandra > Issue Type: Bug > Components: Materialized Views > Environment: [cqlsh 5.0.1 | Cassandra 3.11.1 | CQL spec 3.4.4 | > Native protocol v4] >Reporter: Chema Vinacua > Fix For: 3.11.1 > > > After upgrading from 3.11.0 to 3.11.1 I cannot define materialized views > restricted on non primary key columns. > I get: InvalidRequest: Error from server: code=2200 [Invalid query] > message="Non-primary key columns cannot be restricted in the SELECT statement > used for materialized view creation (got restrictions on: d_destination_set)" > In my 3.11.0 cluster: > $ cqlsh ** > Connected to Test Cluster at :9042. > [cqlsh 5.0.1 | Cassandra 3.11.0 | CQL spec 3.4.4 | Native protocol v4] > Use HELP for help. > cqlsh> CREATE TABLE phoenix.test_table ( >... datetime_bucket ascii primary key, >... d_destination_set boolean, >... d_destination_timestamp timestamp >... ); > cqlsh> CREATE MATERIALIZED VIEW phoenix.test_view AS >... SELECT datetime_bucket, >... d_destination_set >... FROM phoenix.test_table >... WHERE datetime_bucket IS NOT NULL >... AND d_destination_set = FALSE >... PRIMARY KEY (datetime_bucket, d_destination_set); > cqlsh> > No errors shown here. > In my 3.11.1 cluster: > cqlsh> CREATE TABLE phoenix.test_table ( >... datetime_bucket ascii primary key, >... d_destination_set boolean, >... d_destination_timestamp timestamp >... ); > cqlsh> CREATE MATERIALIZED VIEW phoenix.test_view AS >... SELECT datetime_bucket, >... d_destination_set >... FROM phoenix.test_table >... WHERE datetime_bucket IS NOT NULL >... AND d_destination_set = FALSE >... PRIMARY KEY (datetime_bucket, d_destination_set); > InvalidRequest: Error from server: code=2200 [Invalid query] > message="Non-primary key columns cannot be restricted in the SELECT statement > used for materialized view creation (got restrictions on: d_destination_set)" -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-13957) upgradesstables fails after upgrading from 2.1.x to 3.0.11
Dan Priscornic created CASSANDRA-13957:
--
Summary: upgradesstables fails after upgrading from 2.1.x to 3.0.11
Key: CASSANDRA-13957
URL: https://issues.apache.org/jira/browse/CASSANDRA-13957
Project: Cassandra
Issue Type: Bug
Reporter: Dan Priscornic
After upgrading DSE from 4.8.14 (cassandra 2.1.18.1463) to 5.0.10 (cassandra
3.0.14.1862) I ran nodetool upgradesstables and it fails with the following
stack trace:
{code:java}
# nodetool -u cassandra -pwf /etc/dse/cassandra/jmxremote.password
upgradesstables
error: null
-- StackTrace --
java.lang.AssertionError
at org.apache.cassandra.db.rows.Rows.collectStats(Rows.java:70)
at
org.apache.cassandra.io.sstable.format.big.BigTableWriter$StatsCollector.applyToRow(BigTableWriter.java:197)
at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:137)
at
org.apache.cassandra.db.ColumnIndex$Builder.build(ColumnIndex.java:111)
at
org.apache.cassandra.db.ColumnIndex.writeAndBuildIndex(ColumnIndex.java:52)
at
org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(BigTableWriter.java:149)
at
org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:125)
at
org.apache.cassandra.db.compaction.writers.DefaultCompactionWriter.realAppend(DefaultCompactionWriter.java:57)
at
org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.append(CompactionAwareWriter.java:109)
at
org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:205)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at
org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:99)
at
org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:61)
at
org.apache.cassandra.db.compaction.CompactionManager$5.execute(CompactionManager.java:427)
at
org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:314)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at
org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:79)
at
org.apache.cassandra.concurrent.NamedThreadFactory$$Lambda$6/61137731.run(Unknown
Source)
at java.lang.Thread.run(Thread.java:745)
{code}
The bug seems similar to CASSANDRA-13320 which says it should be fixed in
cassandra 3.0.11 but does not look fixed in 3.0.14
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13957) upgradesstables fails after upgrading from 2.1.x to 3.0.14
[
https://issues.apache.org/jira/browse/CASSANDRA-13957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Priscornic updated CASSANDRA-13957:
---
Summary: upgradesstables fails after upgrading from 2.1.x to 3.0.14 (was:
upgradesstables fails after upgrading from 2.1.x to 3.0.11)
> upgradesstables fails after upgrading from 2.1.x to 3.0.14
> --
>
> Key: CASSANDRA-13957
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13957
> Project: Cassandra
> Issue Type: Bug
>Reporter: Dan Priscornic
>
> After upgrading DSE from 4.8.14 (cassandra 2.1.18.1463) to 5.0.10 (cassandra
> 3.0.14.1862) I ran nodetool upgradesstables and it fails with the following
> stack trace:
> {code:java}
> # nodetool -u cassandra -pwf /etc/dse/cassandra/jmxremote.password
> upgradesstables
> error: null
> -- StackTrace --
> java.lang.AssertionError
> at org.apache.cassandra.db.rows.Rows.collectStats(Rows.java:70)
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter$StatsCollector.applyToRow(BigTableWriter.java:197)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:137)
> at
> org.apache.cassandra.db.ColumnIndex$Builder.build(ColumnIndex.java:111)
> at
> org.apache.cassandra.db.ColumnIndex.writeAndBuildIndex(ColumnIndex.java:52)
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(BigTableWriter.java:149)
> at
> org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:125)
> at
> org.apache.cassandra.db.compaction.writers.DefaultCompactionWriter.realAppend(DefaultCompactionWriter.java:57)
> at
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.append(CompactionAwareWriter.java:109)
> at
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:205)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:99)
> at
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:61)
> at
> org.apache.cassandra.db.compaction.CompactionManager$5.execute(CompactionManager.java:427)
> at
> org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:314)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:79)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory$$Lambda$6/61137731.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> The bug seems similar to CASSANDRA-13320 which says it should be fixed in
> cassandra 3.0.11 but does not look fixed in 3.0.14
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13953) Switch to CRC32 for sstable metadata checksums
[
https://issues.apache.org/jira/browse/CASSANDRA-13953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16205694#comment-16205694
]
Aleksey Yeschenko commented on CASSANDRA-13953:
---
Pushed a commit with the change
[here|https://github.com/iamaleksey/cassandra/commits/13953-4.0]. Jenkins dtest
run results to be available
[here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/373/],
and circle utests [here|https://circleci.com/gh/iamaleksey/cassandra/55].
Changes made:
1. Simplified {{MetadataSerializer.deserialize()}} method by splitting toc
decoding logic into two loops and removing some nesting/branching in components
decoding loop
2. Switched from MD5 to CRC32
3. Added checksums to size and overall toc, so that we don't allocate buffers
too big because of corruption in either size or toc offsets.
In addition to that, removed {{MetadataSerializerTest.testMcReadNa()}}, as
there is no expectation of compat between majors. Also added a few tests (ma
read ma, mb read mb, mc read mc, and na read na) to cover roundrtip ser/deser.
Also removed the exception for {{MetadataType.STATS}} not being compared. With
all current formats under test we expect everything to come out equal.
> Switch to CRC32 for sstable metadata checksums
> --
>
> Key: CASSANDRA-13953
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13953
> Project: Cassandra
> Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Aleksey Yeschenko
> Fix For: 4.x
>
>
> We should switch to CRC32 for sstable metadata checksumming for consistency
> with the rest of the code base. There are a few other cleanups that should be
> done at the same time.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13953) Switch to CRC32 for sstable metadata checksums
[ https://issues.apache.org/jira/browse/CASSANDRA-13953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-13953: -- Issue Type: Improvement (was: Bug) > Switch to CRC32 for sstable metadata checksums > -- > > Key: CASSANDRA-13953 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13953 > Project: Cassandra > Issue Type: Improvement >Reporter: Marcus Eriksson >Assignee: Aleksey Yeschenko > Fix For: 4.x > > > We should switch to CRC32 for sstable metadata checksumming for consistency > with the rest of the code base. There are a few other cleanups that should be > done at the same time. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13953) Switch to CRC32 for sstable metadata checksums
[ https://issues.apache.org/jira/browse/CASSANDRA-13953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-13953: -- Priority: Minor (was: Major) > Switch to CRC32 for sstable metadata checksums > -- > > Key: CASSANDRA-13953 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13953 > Project: Cassandra > Issue Type: Improvement >Reporter: Marcus Eriksson >Assignee: Aleksey Yeschenko >Priority: Minor > Fix For: 4.x > > > We should switch to CRC32 for sstable metadata checksumming for consistency > with the rest of the code base. There are a few other cleanups that should be > done at the same time. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13953) Switch to CRC32 for sstable metadata checksums
[ https://issues.apache.org/jira/browse/CASSANDRA-13953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-13953: -- Status: Patch Available (was: Open) > Switch to CRC32 for sstable metadata checksums > -- > > Key: CASSANDRA-13953 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13953 > Project: Cassandra > Issue Type: Improvement >Reporter: Marcus Eriksson >Assignee: Aleksey Yeschenko >Priority: Minor > Fix For: 4.x > > > We should switch to CRC32 for sstable metadata checksumming for consistency > with the rest of the code base. There are a few other cleanups that should be > done at the same time. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-13953) Switch to CRC32 for sstable metadata checksums
[
https://issues.apache.org/jira/browse/CASSANDRA-13953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16205694#comment-16205694
]
Aleksey Yeschenko edited comment on CASSANDRA-13953 at 10/16/17 10:53 AM:
--
Pushed a commit with the change
[here|https://github.com/iamaleksey/cassandra/commits/13953-4.0]. Jenkins dtest
run results to be available
[here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/373/],
and circle utests [here|https://circleci.com/gh/iamaleksey/cassandra/56].
Changes made:
1. Simplified {{MetadataSerializer.deserialize()}} method by splitting toc
decoding logic into two loops and removing some nesting/branching in components
decoding loop
2. Switched from MD5 to CRC32
3. Added checksums to size and overall toc, so that we don't allocate buffers
too big because of corruption in either size or toc offsets.
In addition to that, removed {{MetadataSerializerTest.testMcReadNa()}}, as
there is no expectation of compat between majors. Also added a few tests (ma
read ma, mb read mb, mc read mc, and na read na) to cover roundrtip ser/deser.
was (Author: iamaleksey):
Pushed a commit with the change
[here|https://github.com/iamaleksey/cassandra/commits/13953-4.0]. Jenkins dtest
run results to be available
[here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/373/],
and circle utests [here|https://circleci.com/gh/iamaleksey/cassandra/55].
Changes made:
1. Simplified {{MetadataSerializer.deserialize()}} method by splitting toc
decoding logic into two loops and removing some nesting/branching in components
decoding loop
2. Switched from MD5 to CRC32
3. Added checksums to size and overall toc, so that we don't allocate buffers
too big because of corruption in either size or toc offsets.
In addition to that, removed {{MetadataSerializerTest.testMcReadNa()}}, as
there is no expectation of compat between majors. Also added a few tests (ma
read ma, mb read mb, mc read mc, and na read na) to cover roundrtip ser/deser.
Also removed the exception for {{MetadataType.STATS}} not being compared. With
all current formats under test we expect everything to come out equal.
> Switch to CRC32 for sstable metadata checksums
> --
>
> Key: CASSANDRA-13953
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13953
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Marcus Eriksson
>Assignee: Aleksey Yeschenko
>Priority: Minor
> Fix For: 4.x
>
>
> We should switch to CRC32 for sstable metadata checksumming for consistency
> with the rest of the code base. There are a few other cleanups that should be
> done at the same time.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13002) per table slow query times
[ https://issues.apache.org/jira/browse/CASSANDRA-13002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16205761#comment-16205761 ] Aleksey Yeschenko commented on CASSANDRA-13002: --- Sorry I haven't replied yet. Will have a look eventually - with 4.0 being the potential target, there is some time here left. > per table slow query times > -- > > Key: CASSANDRA-13002 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13002 > Project: Cassandra > Issue Type: New Feature > Components: Observability >Reporter: Jon Haddad >Assignee: Murukesh Mohanan > Fix For: 4.x > > Attachments: > 0001-Add-per-table-slow_query_log_timeout_in_ms-property.patch, > 0001-Add-per-table-slow_query_log_timeout_in_ms-property.patch, > 0001-Add-per-table-slow_query_log_timeout_in_ms-property.patch > > > CASSANDRA-12403 made it possible to log slow queries, but the time specified > is a global one. This isn't useful if we know different tables have > different access patterns, as we'll end up with a lot of noise. We should be > able to override the slow query time at a per table level. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13649) Uncaught exceptions in Netty pipeline
[
https://issues.apache.org/jira/browse/CASSANDRA-13649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16205766#comment-16205766
]
Jonathan Ballet commented on CASSANDRA-13649:
-
I also noticed the frequency of this error message increased a lot after
upgrading to 3.11.1:
{code:java}
INFO [epollEventLoopGroup-2-3] 2017-10-16 10:00:37,592 Message.java:623 -
Unexpected exception during request; channel = [id: 0xb253764e,
L:/10.40.3.15:9042 - R:/10.30.0.10:58996]
io.netty.channel.unix.Errors$NativeIoException: syscall:read(...)() failed:
Connection reset by peer
at io.netty.channel.unix.FileDescriptor.readAddress(...)(Unknown
Source) ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
{code}
> Uncaught exceptions in Netty pipeline
> -
>
> Key: CASSANDRA-13649
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13649
> Project: Cassandra
> Issue Type: Bug
> Components: Streaming and Messaging, Testing
>Reporter: Stefan Podkowinski
>Assignee: Norman Maurer
> Labels: patch
> Fix For: 2.2.11, 3.0.15, 3.11.1, 4.0
>
> Attachments:
> 0001-CASSANDRA-13649-Ensure-all-exceptions-are-correctly-.patch,
> test_stdout.txt
>
>
> I've noticed some netty related errors in trunk in [some of the dtest
> results|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/106/#showFailuresLink].
> Just want to make sure that we don't have to change anything related to the
> exception handling in our pipeline and that this isn't a netty issue.
> Actually if this causes flakiness but is otherwise harmless, we should do
> something about it, even if it's just on the dtest side.
> {noformat}
> WARN [epollEventLoopGroup-2-9] 2017-06-28 17:23:49,699 Slf4JLogger.java:151
> - An exceptionCaught() event was fired, and it reached at the tail of the
> pipeline. It usually means the last handler in the pipeline did not handle
> the exception.
> io.netty.channel.unix.Errors$NativeIoException: syscall:read(...)() failed:
> Connection reset by peer
> at io.netty.channel.unix.FileDescriptor.readAddress(...)(Unknown
> Source) ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> {noformat}
> And again in another test:
> {noformat}
> WARN [epollEventLoopGroup-2-8] 2017-06-29 02:27:31,300 Slf4JLogger.java:151
> - An exceptionCaught() event was fired, and it reached at the tail of the
> pipeline. It usually means the last handler in the pipeline did not handle
> the exception.
> io.netty.channel.unix.Errors$NativeIoException: syscall:read(...)() failed:
> Connection reset by peer
> at io.netty.channel.unix.FileDescriptor.readAddress(...)(Unknown
> Source) ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> {noformat}
> Edit:
> The {{io.netty.channel.unix.Errors$NativeIoException: syscall:read(...)()
> failed}} error also causes tests to fail for 3.0 and 3.11.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Resolved] (CASSANDRA-13956) Cannot restrict columns on materialized view
[ https://issues.apache.org/jira/browse/CASSANDRA-13956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta resolved CASSANDRA-13956. - Resolution: Not A Problem > Cannot restrict columns on materialized view > > > Key: CASSANDRA-13956 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13956 > Project: Cassandra > Issue Type: Bug > Components: Materialized Views > Environment: [cqlsh 5.0.1 | Cassandra 3.11.1 | CQL spec 3.4.4 | > Native protocol v4] >Reporter: Chema Vinacua > Fix For: 3.11.1 > > > After upgrading from 3.11.0 to 3.11.1 I cannot define materialized views > restricted on non primary key columns. > I get: InvalidRequest: Error from server: code=2200 [Invalid query] > message="Non-primary key columns cannot be restricted in the SELECT statement > used for materialized view creation (got restrictions on: d_destination_set)" > In my 3.11.0 cluster: > $ cqlsh ** > Connected to Test Cluster at :9042. > [cqlsh 5.0.1 | Cassandra 3.11.0 | CQL spec 3.4.4 | Native protocol v4] > Use HELP for help. > cqlsh> CREATE TABLE phoenix.test_table ( >... datetime_bucket ascii primary key, >... d_destination_set boolean, >... d_destination_timestamp timestamp >... ); > cqlsh> CREATE MATERIALIZED VIEW phoenix.test_view AS >... SELECT datetime_bucket, >... d_destination_set >... FROM phoenix.test_table >... WHERE datetime_bucket IS NOT NULL >... AND d_destination_set = FALSE >... PRIMARY KEY (datetime_bucket, d_destination_set); > cqlsh> > No errors shown here. > In my 3.11.1 cluster: > cqlsh> CREATE TABLE phoenix.test_table ( >... datetime_bucket ascii primary key, >... d_destination_set boolean, >... d_destination_timestamp timestamp >... ); > cqlsh> CREATE MATERIALIZED VIEW phoenix.test_view AS >... SELECT datetime_bucket, >... d_destination_set >... FROM phoenix.test_table >... WHERE datetime_bucket IS NOT NULL >... AND d_destination_set = FALSE >... PRIMARY KEY (datetime_bucket, d_destination_set); > InvalidRequest: Error from server: code=2200 [Invalid query] > message="Non-primary key columns cannot be restricted in the SELECT statement > used for materialized view creation (got restrictions on: d_destination_set)" -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-13260) Add UDT support to Cassandra stress
[ https://issues.apache.org/jira/browse/CASSANDRA-13260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Brown reassigned CASSANDRA-13260: --- Assignee: Jason Brown > Add UDT support to Cassandra stress > --- > > Key: CASSANDRA-13260 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13260 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Jeremy Hanna >Assignee: Jason Brown > Labels: lhf, stress > > Splitting out UDT support in cassandra stress from CASSANDRA-9556. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-13260) Add UDT support to Cassandra stress
[ https://issues.apache.org/jira/browse/CASSANDRA-13260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Brown reassigned CASSANDRA-13260: --- Assignee: Kevin Wern (was: Jason Brown) > Add UDT support to Cassandra stress > --- > > Key: CASSANDRA-13260 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13260 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Jeremy Hanna >Assignee: Kevin Wern > Labels: lhf, stress > > Splitting out UDT support in cassandra stress from CASSANDRA-9556. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13260) Add UDT support to Cassandra stress
[ https://issues.apache.org/jira/browse/CASSANDRA-13260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16205785#comment-16205785 ] Jason Brown commented on CASSANDRA-13260: - [~kwern] Please do, and I've assigned to you. thanks! > Add UDT support to Cassandra stress > --- > > Key: CASSANDRA-13260 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13260 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Jeremy Hanna >Assignee: Kevin Wern > Labels: lhf, stress > > Splitting out UDT support in cassandra stress from CASSANDRA-9556. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13953) Switch to CRC32 for sstable metadata checksums
[ https://issues.apache.org/jira/browse/CASSANDRA-13953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-13953: Status: Ready to Commit (was: Patch Available) > Switch to CRC32 for sstable metadata checksums > -- > > Key: CASSANDRA-13953 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13953 > Project: Cassandra > Issue Type: Improvement >Reporter: Marcus Eriksson >Assignee: Aleksey Yeschenko >Priority: Minor > Fix For: 4.x > > > We should switch to CRC32 for sstable metadata checksumming for consistency > with the rest of the code base. There are a few other cleanups that should be > done at the same time. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13953) Switch to CRC32 for sstable metadata checksums
[ https://issues.apache.org/jira/browse/CASSANDRA-13953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16205802#comment-16205802 ] Marcus Eriksson commented on CASSANDRA-13953: - +1 > Switch to CRC32 for sstable metadata checksums > -- > > Key: CASSANDRA-13953 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13953 > Project: Cassandra > Issue Type: Improvement >Reporter: Marcus Eriksson >Assignee: Aleksey Yeschenko >Priority: Minor > Fix For: 4.x > > > We should switch to CRC32 for sstable metadata checksumming for consistency > with the rest of the code base. There are a few other cleanups that should be > done at the same time. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-13958) [CQL] Inconsistent handling double dollar sign for strings
Hugo Picado created CASSANDRA-13958:
---
Summary: [CQL] Inconsistent handling double dollar sign for strings
Key: CASSANDRA-13958
URL: https://issues.apache.org/jira/browse/CASSANDRA-13958
Project: Cassandra
Issue Type: Bug
Components: CQL
Reporter: Hugo Picado
Priority: Minor
Double dollar signs is a [built-in method for escaping columns that may contain
single quotes in its
content](https://docs.datastax.com/en/cql/3.3/cql/cql_reference/escape_char_r.html).
The way this is handled however is not consistent, in the sense that it allows
for $ to appear in the middle of the string but not in the last char.
*Examples:*
Valid: insert into users(id, name) values(1, $$john$$)
Inserts the string *john*
Valid: insert into users(id, name) values(1, $$jo$hn$$)
Inserts the string *jo$hn*
Valid: insert into users(id, name) values(1, $$$john$$)
Inserts the string *$john*
Invalid: insert into users(id, name) values(1, $$john$$$)
Fails with:
{code}
Invalid syntax at line 1, char 48
insert into users(id, name) values(1, $$john$$$);
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13957) upgradesstables fails after upgrading from 2.1.x to 3.0.14
[
https://issues.apache.org/jira/browse/CASSANDRA-13957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16205814#comment-16205814
]
Dan Priscornic commented on CASSANDRA-13957:
I also tried upgrading to DSE 5.0.4 (cassandra 3.0.10.1443) and upgradesstables
fails in the same way
> upgradesstables fails after upgrading from 2.1.x to 3.0.14
> --
>
> Key: CASSANDRA-13957
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13957
> Project: Cassandra
> Issue Type: Bug
>Reporter: Dan Priscornic
>
> After upgrading DSE from 4.8.14 (cassandra 2.1.18.1463) to 5.0.10 (cassandra
> 3.0.14.1862) I ran nodetool upgradesstables and it fails with the following
> stack trace:
> {code:java}
> # nodetool -u cassandra -pwf /etc/dse/cassandra/jmxremote.password
> upgradesstables
> error: null
> -- StackTrace --
> java.lang.AssertionError
> at org.apache.cassandra.db.rows.Rows.collectStats(Rows.java:70)
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter$StatsCollector.applyToRow(BigTableWriter.java:197)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:137)
> at
> org.apache.cassandra.db.ColumnIndex$Builder.build(ColumnIndex.java:111)
> at
> org.apache.cassandra.db.ColumnIndex.writeAndBuildIndex(ColumnIndex.java:52)
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(BigTableWriter.java:149)
> at
> org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:125)
> at
> org.apache.cassandra.db.compaction.writers.DefaultCompactionWriter.realAppend(DefaultCompactionWriter.java:57)
> at
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.append(CompactionAwareWriter.java:109)
> at
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:205)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:99)
> at
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:61)
> at
> org.apache.cassandra.db.compaction.CompactionManager$5.execute(CompactionManager.java:427)
> at
> org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:314)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:79)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory$$Lambda$6/61137731.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> The bug seems similar to CASSANDRA-13320 which says it should be fixed in
> cassandra 3.0.11 but does not look fixed in 3.0.14
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13957) upgradesstables fails after upgrading from 2.1.x to 3.0.14
[
https://issues.apache.org/jira/browse/CASSANDRA-13957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Priscornic updated CASSANDRA-13957:
---
Description:
After upgrading DSE from 4.8.14 (cassandra 2.1.18.1463) to 5.0.10 (cassandra
3.0.14.1862) I ran nodetool upgradesstables and it fails with the following
stack trace:
{code:java}
# nodetool -u cassandra -pwf /etc/dse/cassandra/jmxremote.password
upgradesstables
error: null
-- StackTrace --
java.lang.AssertionError
at org.apache.cassandra.db.rows.Rows.collectStats(Rows.java:70)
at
org.apache.cassandra.io.sstable.format.big.BigTableWriter$StatsCollector.applyToRow(BigTableWriter.java:197)
at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:137)
at
org.apache.cassandra.db.ColumnIndex$Builder.build(ColumnIndex.java:111)
at
org.apache.cassandra.db.ColumnIndex.writeAndBuildIndex(ColumnIndex.java:52)
at
org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(BigTableWriter.java:149)
at
org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:125)
at
org.apache.cassandra.db.compaction.writers.DefaultCompactionWriter.realAppend(DefaultCompactionWriter.java:57)
at
org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.append(CompactionAwareWriter.java:109)
at
org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:205)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at
org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:99)
at
org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:61)
at
org.apache.cassandra.db.compaction.CompactionManager$5.execute(CompactionManager.java:427)
at
org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:314)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at
org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:79)
at
org.apache.cassandra.concurrent.NamedThreadFactory$$Lambda$6/61137731.run(Unknown
Source)
at java.lang.Thread.run(Thread.java:745)
{code}
The bug seems similar to CASSANDRA-13320 which says it should be fixed in
cassandra 3.0.13 but does not look fixed in 3.0.14
was:
After upgrading DSE from 4.8.14 (cassandra 2.1.18.1463) to 5.0.10 (cassandra
3.0.14.1862) I ran nodetool upgradesstables and it fails with the following
stack trace:
{code:java}
# nodetool -u cassandra -pwf /etc/dse/cassandra/jmxremote.password
upgradesstables
error: null
-- StackTrace --
java.lang.AssertionError
at org.apache.cassandra.db.rows.Rows.collectStats(Rows.java:70)
at
org.apache.cassandra.io.sstable.format.big.BigTableWriter$StatsCollector.applyToRow(BigTableWriter.java:197)
at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:137)
at
org.apache.cassandra.db.ColumnIndex$Builder.build(ColumnIndex.java:111)
at
org.apache.cassandra.db.ColumnIndex.writeAndBuildIndex(ColumnIndex.java:52)
at
org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(BigTableWriter.java:149)
at
org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:125)
at
org.apache.cassandra.db.compaction.writers.DefaultCompactionWriter.realAppend(DefaultCompactionWriter.java:57)
at
org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.append(CompactionAwareWriter.java:109)
at
org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:205)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at
org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:99)
at
org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:61)
at
org.apache.cassandra.db.compaction.CompactionManager$5.execute(CompactionManager.java:427)
at
org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:314)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at
org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:79)
at
org.apache.cassandra.concurrent.NamedThreadFactory$$Lambda$6/61137731.run(Unknown
Source)
at java.lang.Thre
[jira] [Created] (CASSANDRA-13959) Add yaml flag for disabling MVs, log warnings on creation
Blake Eggleston created CASSANDRA-13959: --- Summary: Add yaml flag for disabling MVs, log warnings on creation Key: CASSANDRA-13959 URL: https://issues.apache.org/jira/browse/CASSANDRA-13959 Project: Cassandra Issue Type: Bug Components: Materialized Views Reporter: Blake Eggleston Assignee: Blake Eggleston Priority: Minor Fix For: 4.0, 3.0.x, 3.11.x As discussed on dev@, we should give operators the option to disable materialized view creation, and log warnings when they're created. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13952) C* still sending WriteFailure instead of CDCWriteFailure
[
https://issues.apache.org/jira/browse/CASSANDRA-13952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16206283#comment-16206283
]
Andy Tolbert commented on CASSANDRA-13952:
--
To clarify the intent of this error, should it be its own protocol error
({{CDC_WRITE_FAILURE}}) or should it be a new reason code on {{WRITE_FAILURE}}.
I think if the error only happens on the coordinator node a separate error
may make more sense, but if it can happen on any replica {{WRITE_FAILURE}}
would make more sense as with {{WRITE_FAILURE}} you get a mapping of failed
replicas with their failure codes.
> C* still sending WriteFailure instead of CDCWriteFailure
>
>
> Key: CASSANDRA-13952
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13952
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jaume M
>Assignee: Jaume M
> Fix For: 4.0
>
>
> I've tested this setting setting cdc_total_space_in_mb: 1 and with the
> current python driver master
> {code}
> from cassandra.cluster import Cluster
> cluster = Cluster(protocol_version=5, allow_beta_protocol_version=True)
> session = cluster.connect()
> session.execute("""
> CREATE KEYSPACE IF NOT EXISTS %s
> WITH replication = { 'class': 'SimpleStrategy', 'replication_factor': '2'
> }
> """ % "query_per_range")
> session.execute("""
> CREATE TABLE IF NOT EXISTS query_per_range.mytable_int (
> key_one int,
> key_two int,
> col1 text,
> col2 text,
> PRIMARY KEY ((key_one, key_two), col1)
> ) WITH cdc=true;
> """)
> for i in range(1000):
> session.execute("INSERT INTO query_per_range.mytable_int(key_one,
> key_two, col1, col2) VALUES (%s, %s, %s, %s)",
> (i, i, str(i), str(i)))
> {code}
> I'm receiving a {{WriteFailure}} every time but I was expecting a
> {{CDCWriteFailure}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-13952) C* still sending WriteFailure instead of CDCWriteFailure
[
https://issues.apache.org/jira/browse/CASSANDRA-13952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16206283#comment-16206283
]
Andy Tolbert edited comment on CASSANDRA-13952 at 10/16/17 5:48 PM:
To clarify the intent of this error, should it be its own protocol error
({{CDC_WRITE_FAILURE}}) or should it be a new reason code on {{WRITE_FAILURE}}?
I think if the error only happens on the coordinator node a separate error
may make more sense, but if it can happen on any replica {{WRITE_FAILURE}}
would make more sense as with {{WRITE_FAILURE}} you get a mapping of failed
replicas with their failure codes.
was (Author: andrew.tolbert):
To clarify the intent of this error, should it be its own protocol error
({{CDC_WRITE_FAILURE}}) or should it be a new reason code on {{WRITE_FAILURE}}.
I think if the error only happens on the coordinator node a separate error
may make more sense, but if it can happen on any replica {{WRITE_FAILURE}}
would make more sense as with {{WRITE_FAILURE}} you get a mapping of failed
replicas with their failure codes.
> C* still sending WriteFailure instead of CDCWriteFailure
>
>
> Key: CASSANDRA-13952
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13952
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jaume M
>Assignee: Jaume M
> Fix For: 4.0
>
>
> I've tested this setting setting cdc_total_space_in_mb: 1 and with the
> current python driver master
> {code}
> from cassandra.cluster import Cluster
> cluster = Cluster(protocol_version=5, allow_beta_protocol_version=True)
> session = cluster.connect()
> session.execute("""
> CREATE KEYSPACE IF NOT EXISTS %s
> WITH replication = { 'class': 'SimpleStrategy', 'replication_factor': '2'
> }
> """ % "query_per_range")
> session.execute("""
> CREATE TABLE IF NOT EXISTS query_per_range.mytable_int (
> key_one int,
> key_two int,
> col1 text,
> col2 text,
> PRIMARY KEY ((key_one, key_two), col1)
> ) WITH cdc=true;
> """)
> for i in range(1000):
> session.execute("INSERT INTO query_per_range.mytable_int(key_one,
> key_two, col1, col2) VALUES (%s, %s, %s, %s)",
> (i, i, str(i), str(i)))
> {code}
> I'm receiving a {{WriteFailure}} every time but I was expecting a
> {{CDCWriteFailure}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13442) Support a means of strongly consistent highly available replication with tunable storage requirements
[
https://issues.apache.org/jira/browse/CASSANDRA-13442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16206290#comment-16206290
]
Ariel Weisberg commented on CASSANDRA-13442:
bq. It's still not clear to me what you mean by 10-20x, are you saying you
could need 1-100x more hardware if you don't use a transitive replica?
I mean that if you are running RF=3 in a data center you could switch to RF=5
and the increase in required capacity would be as if you were running at RF=3.1
or 3.2. The ranges each node transiently replicates would contain 10x-20x less
data than a fully replicated range (even during node failures) and would
require 10x-20x less CPU, network IO, disk IO, and CPU.
Put another way. If you want to increase RF by 2 then you need to commit 100%
of the hardware necessary to replicate your data twice and process reads and
writes on that data. With transient replication you don't need to commit 100%
of the hardware you need to commit 5-10% additional hardware.
There is another optimization I talked about at NGCC that I am calling cheap
quorums. Transient replication alone only addresses data footprint it doesn't
do as much to eliminate the per write overhead of increasing RF. With cheap
quorums you only write to a transient replica if you are unable to write to a
full replica. So transient replicas don't even see most writes, and reads that
are routed to transient replicas turn into bloom filter checks that usually
fail instead of IO. If you have a working dynamic snitch and something like
rapid read protection for writes you can handle node failures efficiently on
the write path.
If 16 vnodes were workable that would be enough in most cases to maintain
availability and performance when there are node failures. Without that then
transient replication (and cheap quorums) only reduce footprint in non-failure
conditions which isn't anywhere near as useful. You need enough vnodes to
ensure that a transient replica doesn't get hit with the full load of another
node on failure.
> Support a means of strongly consistent highly available replication with
> tunable storage requirements
> -
>
> Key: CASSANDRA-13442
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13442
> Project: Cassandra
> Issue Type: Improvement
> Components: Compaction, Coordination, Distributed Metadata, Local
> Write-Read Paths
>Reporter: Ariel Weisberg
>
> Replication factors like RF=2 can't provide strong consistency and
> availability because if a single node is lost it's impossible to reach a
> quorum of replicas. Stepping up to RF=3 will allow you to lose a node and
> still achieve quorum for reads and writes, but requires committing additional
> storage.
> The requirement of a quorum for writes/reads doesn't seem to be something
> that can be relaxed without additional constraints on queries, but it seems
> like it should be possible to relax the requirement that 3 full copies of the
> entire data set are kept. What is actually required is a covering data set
> for the range and we should be able to achieve a covering data set and high
> availability without having three full copies.
> After a repair we know that some subset of the data set is fully replicated.
> At that point we don't have to read from a quorum of nodes for the repaired
> data. It is sufficient to read from a single node for the repaired data and a
> quorum of nodes for the unrepaired data.
> One way to exploit this would be to have N replicas, say the last N replicas
> (where N varies with RF) in the preference list, delete all repaired data
> after a repair completes. Subsequent quorum reads will be able to retrieve
> the repaired data from any of the two full replicas and the unrepaired data
> from a quorum read of any replica including the "transient" replicas.
> Configuration for something like this in NTS might be something similar to {
> DC1="3-1", DC2="3-2" } where the first value is the replication factor used
> for consistency and the second values is the number of transient replicas. If
> you specify { DC1=3, DC2=3 } then the number of transient replicas defaults
> to 0 and you get the same behavior you have today.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13442) Support a means of strongly consistent highly available replication with tunable storage requirements
[
https://issues.apache.org/jira/browse/CASSANDRA-13442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16206422#comment-16206422
]
Jeremy Hanna commented on CASSANDRA-13442:
--
The cheap quorums concept was interesting as it seemed like you could do a sort
of wrapper of the normal consistency level with an ANY CL type property, with
the difference being, you could still immediately read from the transient
replica. One of the downsides of classic ANY was that it was locked in hints
which weren't readable.
> Support a means of strongly consistent highly available replication with
> tunable storage requirements
> -
>
> Key: CASSANDRA-13442
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13442
> Project: Cassandra
> Issue Type: Improvement
> Components: Compaction, Coordination, Distributed Metadata, Local
> Write-Read Paths
>Reporter: Ariel Weisberg
>
> Replication factors like RF=2 can't provide strong consistency and
> availability because if a single node is lost it's impossible to reach a
> quorum of replicas. Stepping up to RF=3 will allow you to lose a node and
> still achieve quorum for reads and writes, but requires committing additional
> storage.
> The requirement of a quorum for writes/reads doesn't seem to be something
> that can be relaxed without additional constraints on queries, but it seems
> like it should be possible to relax the requirement that 3 full copies of the
> entire data set are kept. What is actually required is a covering data set
> for the range and we should be able to achieve a covering data set and high
> availability without having three full copies.
> After a repair we know that some subset of the data set is fully replicated.
> At that point we don't have to read from a quorum of nodes for the repaired
> data. It is sufficient to read from a single node for the repaired data and a
> quorum of nodes for the unrepaired data.
> One way to exploit this would be to have N replicas, say the last N replicas
> (where N varies with RF) in the preference list, delete all repaired data
> after a repair completes. Subsequent quorum reads will be able to retrieve
> the repaired data from any of the two full replicas and the unrepaired data
> from a quorum read of any replica including the "transient" replicas.
> Configuration for something like this in NTS might be something similar to {
> DC1="3-1", DC2="3-2" } where the first value is the replication factor used
> for consistency and the second values is the number of transient replicas. If
> you specify { DC1=3, DC2=3 } then the number of transient replicas defaults
> to 0 and you get the same behavior you have today.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-13960) update cassandra.yaml links to point to new docs instead of the wiki
Jon Haddad created CASSANDRA-13960:
--
Summary: update cassandra.yaml links to point to new docs instead
of the wiki
Key: CASSANDRA-13960
URL: https://issues.apache.org/jira/browse/CASSANDRA-13960
Project: Cassandra
Issue Type: Improvement
Components: Documentation and Website
Reporter: Jon Haddad
Priority: Minor
The wiki is dead, let's clean up the links and be sure we have the right into
on cassandra.apache.org.
{code}
# NOTE:
# See http://wiki.apache.org/cassandra/StorageConfiguration for
# full explanations of configuration directives
# /NOTE
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13949) java.lang.ArrayIndexOutOfBoundsException while executing query
[ https://issues.apache.org/jira/browse/CASSANDRA-13949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Jirsa updated CASSANDRA-13949: --- Reviewer: Jeff Jirsa Fix Version/s: 4.x Status: Patch Available (was: Open) > java.lang.ArrayIndexOutOfBoundsException while executing query > -- > > Key: CASSANDRA-13949 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13949 > Project: Cassandra > Issue Type: Bug > Components: CQL > Environment: Setup of 3 servers y using docker image > [https://github.com/docker-library/cassandra/blob/ca3c9df03cab318d34377bba0610c741253b0466/3.11/Dockerfile] >Reporter: Luis E Rodriguez Pupo >Assignee: Jason Brown > Fix For: 3.11.x, 4.x > > Attachments: 13949.png, insert.cql, query.cql, schema.cql > > > While executing a query on a table contaninig a field with a (escaped) json, > the following exception occurs: > java.lang.ArrayIndexOutOfBoundsException: null > at > org.codehaus.jackson.io.JsonStringEncoder.quoteAsString(JsonStringEncoder.java:141) > ~[jackson-core-asl-1.9.2.jar:1.9.2] > at org.apache.cassandra.cql3.Json.quoteAsJsonString(Json.java:45) > ~[apache-cassandra-3.11.0.jar:3.11.0] > at > org.apache.cassandra.db.marshal.UTF8Type.toJSONString(UTF8Type.java:66) > ~[apache-cassandra-3.11.0.jar:3.11.0] > at > org.apache.cassandra.cql3.selection.Selection.rowToJson(Selection.java:291) > ~[apache-cassandra-3.11.0.jar:3.11.0] > at > org.apache.cassandra.cql3.selection.Selection$ResultSetBuilder.getOutputRow(Selection.java:431) > ~[apache-cassandra-3.11.0.jar:3.11.0] > at > org.apache.cassandra.cql3.selection.Selection$ResultSetBuilder.build(Selection.java:417) > ~[apache-cassandra-3.11.0.jar:3.11.0] > at > org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:763) > ~[apache-cassandra-3.11.0.jar:3.11.0] > at > org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:400) > ~[apache-cassandra-3.11.0.jar:3.11.0] > at > org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:378) > ~[apache-cassandra-3.11.0.jar:3.11.0] > at > org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:251) > ~[apache-cassandra-3.11.0.jar:3.11.0] > at > org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:79) > ~[apache-cassandra-3.11.0.jar:3.11.0] > at > org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:217) > ~[apache-cassandra-3.11.0.jar:3.11.0] > at > org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:248) > ~[apache-cassandra-3.11.0.jar:3.11.0] > at > org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:233) > ~[apache-cassandra-3.11.0.jar:3.11.0] > at > org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:116) > ~[apache-cassandra-3.11.0.jar:3.11.0] > at > org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:517) > [apache-cassandra-3.11.0.jar:3.11.0] > at > org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:410) > [apache-cassandra-3.11.0.jar:3.11.0] > at > io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105) > [netty-all-4.0.44.Final.jar:4.0.44.Final] > at > io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:357) > [netty-all-4.0.44.Final.jar:4.0.44.Final] > at > io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:35) > [netty-all-4.0.44.Final.jar:4.0.44.Final] > at > io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:348) > [netty-all-4.0.44.Final.jar:4.0.44.Final] > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > [na:1.8.0_131] > at > org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162) > [apache-cassandra-3.11.0.jar:3.11.0] > at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) > [apache-cassandra-3.11.0.jar:3.11.0] > at java.lang.Thread.run(Thread.java:748) [na:1.8.0_131] > Find attached the schema of the table, the insertion query with the data > provoking the failure, and the failing query. > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commi
[jira] [Commented] (CASSANDRA-13949) java.lang.ArrayIndexOutOfBoundsException while executing query
[ https://issues.apache.org/jira/browse/CASSANDRA-13949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16206545#comment-16206545 ] Jeff Jirsa commented on CASSANDRA-13949: 3.11 patch looks good to me 4.0 patch is obviously the same, though the dtests look pretty messy. Can you run that again. +1 if / once that trunk dtest comes back clean. > java.lang.ArrayIndexOutOfBoundsException while executing query > -- > > Key: CASSANDRA-13949 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13949 > Project: Cassandra > Issue Type: Bug > Components: CQL > Environment: Setup of 3 servers y using docker image > [https://github.com/docker-library/cassandra/blob/ca3c9df03cab318d34377bba0610c741253b0466/3.11/Dockerfile] >Reporter: Luis E Rodriguez Pupo >Assignee: Jason Brown > Fix For: 3.11.x, 4.x > > Attachments: 13949.png, insert.cql, query.cql, schema.cql > > > While executing a query on a table contaninig a field with a (escaped) json, > the following exception occurs: > java.lang.ArrayIndexOutOfBoundsException: null > at > org.codehaus.jackson.io.JsonStringEncoder.quoteAsString(JsonStringEncoder.java:141) > ~[jackson-core-asl-1.9.2.jar:1.9.2] > at org.apache.cassandra.cql3.Json.quoteAsJsonString(Json.java:45) > ~[apache-cassandra-3.11.0.jar:3.11.0] > at > org.apache.cassandra.db.marshal.UTF8Type.toJSONString(UTF8Type.java:66) > ~[apache-cassandra-3.11.0.jar:3.11.0] > at > org.apache.cassandra.cql3.selection.Selection.rowToJson(Selection.java:291) > ~[apache-cassandra-3.11.0.jar:3.11.0] > at > org.apache.cassandra.cql3.selection.Selection$ResultSetBuilder.getOutputRow(Selection.java:431) > ~[apache-cassandra-3.11.0.jar:3.11.0] > at > org.apache.cassandra.cql3.selection.Selection$ResultSetBuilder.build(Selection.java:417) > ~[apache-cassandra-3.11.0.jar:3.11.0] > at > org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:763) > ~[apache-cassandra-3.11.0.jar:3.11.0] > at > org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:400) > ~[apache-cassandra-3.11.0.jar:3.11.0] > at > org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:378) > ~[apache-cassandra-3.11.0.jar:3.11.0] > at > org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:251) > ~[apache-cassandra-3.11.0.jar:3.11.0] > at > org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:79) > ~[apache-cassandra-3.11.0.jar:3.11.0] > at > org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:217) > ~[apache-cassandra-3.11.0.jar:3.11.0] > at > org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:248) > ~[apache-cassandra-3.11.0.jar:3.11.0] > at > org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:233) > ~[apache-cassandra-3.11.0.jar:3.11.0] > at > org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:116) > ~[apache-cassandra-3.11.0.jar:3.11.0] > at > org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:517) > [apache-cassandra-3.11.0.jar:3.11.0] > at > org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:410) > [apache-cassandra-3.11.0.jar:3.11.0] > at > io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105) > [netty-all-4.0.44.Final.jar:4.0.44.Final] > at > io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:357) > [netty-all-4.0.44.Final.jar:4.0.44.Final] > at > io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:35) > [netty-all-4.0.44.Final.jar:4.0.44.Final] > at > io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:348) > [netty-all-4.0.44.Final.jar:4.0.44.Final] > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > [na:1.8.0_131] > at > org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162) > [apache-cassandra-3.11.0.jar:3.11.0] > at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) > [apache-cassandra-3.11.0.jar:3.11.0] > at java.lang.Thread.run(Thread.java:748) [na:1.8.0_131] > Find attached the schema of the table, the insertion query with the data > provoking the failure, and the failing query. > -- This message was sent by Atlassian JIRA (v6.4.14#64029) --
[jira] [Commented] (CASSANDRA-13954) Provide a JMX call to sync schema with local storage
[ https://issues.apache.org/jira/browse/CASSANDRA-13954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16206584#comment-16206584 ] Aleksey Yeschenko commented on CASSANDRA-13954: --- Branches for [3.0|https://github.com/iamaleksey/cassandra/commits/13954-3.0], [3.11|https://github.com/iamaleksey/cassandra/commits/13954-3.11], [4.0|https://github.com/iamaleksey/cassandra/commits/13954-4.0]. Dtest [here|https://github.com/iamaleksey/cassandra-dtest/commits/13954]. CircleCI for [3.0|https://circleci.com/gh/iamaleksey/cassandra/60], [3.11|https://circleci.com/gh/iamaleksey/cassandra/58], [4.0|https://circleci.com/gh/iamaleksey/cassandra/59]. Dtest run just for [3.0|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/375/]. > Provide a JMX call to sync schema with local storage > > > Key: CASSANDRA-13954 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13954 > Project: Cassandra > Issue Type: New Feature > Components: Distributed Metadata >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Minor > Fix For: 3.0.x, 3.11.x > > > As discussed in CASSANDRA-13813 comments, we need such a call / nodetool > command to enable the workaround for CASSANDRA-12701. > This is technically a new feature and shouldn't go into 3.0.x, however in > practical terms it's part of a solution to CASSANDRA-12701, which is a bug, > and an pre-requisite for CASSANDRA-13813 - which is also a bug. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13954) Provide a JMX call to sync schema with local storage
[ https://issues.apache.org/jira/browse/CASSANDRA-13954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-13954: -- Status: Patch Available (was: In Progress) > Provide a JMX call to sync schema with local storage > > > Key: CASSANDRA-13954 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13954 > Project: Cassandra > Issue Type: New Feature > Components: Distributed Metadata >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Minor > Fix For: 3.0.x, 3.11.x > > > As discussed in CASSANDRA-13813 comments, we need such a call / nodetool > command to enable the workaround for CASSANDRA-12701. > This is technically a new feature and shouldn't go into 3.0.x, however in > practical terms it's part of a solution to CASSANDRA-12701, which is a bug, > and an pre-requisite for CASSANDRA-13813 - which is also a bug. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13923) Flushers blocked due to many SSTables
[ https://issues.apache.org/jira/browse/CASSANDRA-13923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16206598#comment-16206598 ] Dan Kinder commented on CASSANDRA-13923: This seems just as related to CASSANDRA-13948 > Flushers blocked due to many SSTables > - > > Key: CASSANDRA-13923 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13923 > Project: Cassandra > Issue Type: Bug > Components: Compaction, Local Write-Read Paths > Environment: Cassandra 3.11.0 > Centos 6 (downgraded JNA) > 64GB RAM > 12-disk JBOD >Reporter: Dan Kinder >Assignee: Marcus Eriksson > Attachments: cassandra-jstack-readstage.txt, cassandra-jstack.txt > > > This started on the mailing list and I'm not 100% sure of the root cause, > feel free to re-title if needed. > I just upgraded Cassandra from 2.2.6 to 3.11.0. Within a few hours of serving > traffic, thread pools begin to back up and grow pending tasks indefinitely. > This happens to multiple different stages (Read, Mutation) and consistently > builds pending tasks for MemtablePostFlush and MemtableFlushWriter. > Using jstack shows that there is blocking going on when trying to call > getCompactionCandidates, which seems to happen on flush. We have fairly large > nodes that have ~15,000 SSTables per node, all LCS. > I seems like this can cause reads to get blocked because they try to acquire > a read lock when calling shouldDefragment. > And writes, of course, block once we can't allocate anymore memtables, > because flushes are backed up. > We did not have this problem in 2.2.6, so it seems like there is some > regression causing it to be incredibly slow trying to do calls like > getCompactionCandidates that list out the SSTables. > In our case this causes nodes to build up pending tasks and simply stop > responding to requests. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13615) Include 'ppc64le' library for sigar-1.6.4.jar
[
https://issues.apache.org/jira/browse/CASSANDRA-13615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16206658#comment-16206658
]
Rei Odaira commented on CASSANDRA-13615:
Hello,
I found the libsigar-ppc64le-linux.so in Cassandra does not work.
{quote}2017-10-02 17:24:15,560 SigarLibrary.java:44 - Initializing SIGAR library
java: symbol lookup error:
/home/rei/CassandraYCSB.work/capi-rowcache/cassandra/lib/sigar-bin/libsigar-ppc64le-linux.so:
undefined symbol: sigar_skip_token
{quote}
The build steps [~amitkumar_ghatwal] proposed used to generate a correct
binary, but it does not any more with gcc version 5 or later. This is because
SIGAR assumes older gcc's {{inline}} semantics, but gcc 5 changed the default
semantics. I created my own sigar branch with a necessary build option change,
so that you can build a correct libsigar-ppc64le-linux.so binary.
Here are the new build steps:
$ git clone https://github.com/odaira/sigar.git
$ cd sigar/bindings/java
$ git checkout sigar-1.6.4-stdgnu89
$ ant
Please check these steps have built a correct binary. If the following command
prints out a {{sigar>}} command prompt, then it is a correct binary:
$ java -jar sigar-bin/lib/sigar.jar
Loaded rc file: ./.sigar_shellrc
sigar> quit
Goodbye.
Please copy the generated binary to Cassandra's lib/sigar-bin:
$ cp sigar-bin/lib/libsigar-ppc64le-linux.so $CASSANDRA_HOME/lib/sigar-bin
Thanks,
> Include 'ppc64le' library for sigar-1.6.4.jar
> -
>
> Key: CASSANDRA-13615
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13615
> Project: Cassandra
> Issue Type: Improvement
> Components: Libraries
> Environment: # arch
> ppc64le
>Reporter: Amitkumar Ghatwal
>Assignee: Michael Shuler
> Labels: easyfix
> Fix For: 4.0
>
> Attachments: libsigar-ppc64le-linux.so
>
>
> Hi All,
> sigar-1.6.4.jar does not include a ppc64le library, so we had to install
> libsigar-ppc64le-linux.so.As the community has been inactive for long
> (https://github.com/hyperic/sigar), requesting the community to include the
> ppc64le library directly here.
> Attaching the ppc64le library ( *.so) file to be included under
> "/lib/sigar-bin". let me know of issues/dependency if any.
> FYI - [~ReiOdaira],[~jjirsa], [~mshuler]
> Regards,
> Amit
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13863) Speculative retry causes read repair even if read_repair_chance is 0.0.
[
https://issues.apache.org/jira/browse/CASSANDRA-13863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16206662#comment-16206662
]
Nate McCall commented on CASSANDRA-13863:
-
Note: removing the *read_repair_chance options entirely is currently being
discussed under CASSANDRA-13910
> Speculative retry causes read repair even if read_repair_chance is 0.0.
> ---
>
> Key: CASSANDRA-13863
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13863
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Hiro Wakabayashi
> Attachments:
> 0001-Use-read_repair_chance-when-starting-repairs-due-to-.patch, speculative
> retries.pdf
>
>
> {{read_repair_chance = 0.0}} and {{dclocal_read_repair_chance = 0.0}} should
> cause no read repair, but read repair happens with speculative retry. I think
> {{read_repair_chance = 0.0}} and {{dclocal_read_repair_chance = 0.0}} should
> stop read repair completely because the user wants to stop read repair in
> some cases.
> {panel:title=Case 1: TWCS users}
> The
> [documentation|http://cassandra.apache.org/doc/latest/operating/compaction.html?highlight=read_repair_chance]
> states how to disable read repair.
> {quote}While TWCS tries to minimize the impact of comingled data, users
> should attempt to avoid this behavior. Specifically, users should avoid
> queries that explicitly set the timestamp via CQL USING TIMESTAMP.
> Additionally, users should run frequent repairs (which streams data in such a
> way that it does not become comingled), and disable background read repair by
> setting the table’s read_repair_chance and dclocal_read_repair_chance to 0.
> {quote}
> {panel}
> {panel:title=Case 2. Strict SLA for read latency}
> In a peak time, read latency is a key for us but, read repair causes latency
> higher than no read repair. We can use anti entropy repair in off peak time
> for consistency.
> {panel}
>
> Here is my procedure to reproduce the problem.
> h3. 1. Create a cluster and set {{hinted_handoff_enabled}} to false.
> {noformat}
> $ ccm create -v 3.0.14 -n 3 cluster_3.0.14
> $ for h in $(seq 1 3) ; do perl -pi -e 's/hinted_handoff_enabled:
> true/hinted_handoff_enabled: false/'
> ~/.ccm/cluster_3.0.14/node$h/conf/cassandra.yaml ; done
> $ for h in $(seq 1 3) ; do grep "hinted_handoff_enabled:"
> ~/.ccm/cluster_3.0.14/node$h/conf/cassandra.yaml ; done
> hinted_handoff_enabled: false
> hinted_handoff_enabled: false
> hinted_handoff_enabled: false
> $ ccm start{noformat}
> h3. 2. Create a keyspace and a table.
> {noformat}
> $ ccm node1 cqlsh
> DROP KEYSPACE IF EXISTS ks1;
> CREATE KEYSPACE ks1 WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '3'} AND durable_writes = true;
> CREATE TABLE ks1.t1 (
> key text PRIMARY KEY,
> value blob
> ) WITH bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.0
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = 'ALWAYS';
> QUIT;
> {noformat}
> h3. 3. Stop node2 and node3. Insert a row.
> {noformat}
> $ ccm node3 stop && ccm node2 stop && ccm status
> Cluster: 'cluster_3.0.14'
> --
> node1: UP
> node3: DOWN
> node2: DOWN
> $ ccm node1 cqlsh -k ks1 -e "consistency; tracing on; insert into ks1.t1
> (key, value) values ('mmullass', bigintAsBlob(1));"
> Current consistency level is ONE.
> Now Tracing is enabled
> Tracing session: 01d74590-97cb-11e7-8ea7-c1bd4d549501
> activity
>| timestamp | source|
> source_elapsed
> -++---+
>
> Execute CQL3 query | 2017-09-12 23:59:42.316000 | 127.0.0.1 |
> 0
> Parsing insert into ks1.t1 (key, value) values ('mmullass',
> bigintAsBlob(1)); [SharedPool-Worker-1] | 2017-09-12 23:59:42.319000 |
> 127.0.0.1 | 4323
>Preparing
[jira] [Updated] (CASSANDRA-13959) Add yaml flag for disabling MVs, log warnings on creation
[ https://issues.apache.org/jira/browse/CASSANDRA-13959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-13959: Status: Patch Available (was: Open) |[3.0|https://github.com/bdeggleston/cassandra/tree/13959-3.0] | [utest|https://circleci.com/gh/bdeggleston/cassandra/138]| |[3.11|https://github.com/bdeggleston/cassandra/tree/13959-3.11]|[utest|https://circleci.com/gh/bdeggleston/cassandra/139]| |[trunk|https://github.com/bdeggleston/cassandra/tree/13959-trunk]|[utest|https://circleci.com/gh/bdeggleston/cassandra/137]| > Add yaml flag for disabling MVs, log warnings on creation > - > > Key: CASSANDRA-13959 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13959 > Project: Cassandra > Issue Type: Bug > Components: Materialized Views >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Minor > Fix For: 4.0, 3.0.x, 3.11.x > > > As discussed on dev@, we should give operators the option to disable > materialized view creation, and log warnings when they're created. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13615) Include 'ppc64le' library for sigar-1.6.4.jar
[ https://issues.apache.org/jira/browse/CASSANDRA-13615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16206672#comment-16206672 ] Jeff Jirsa commented on CASSANDRA-13615: I can't configure it to build your branch, because I can't be 100% positive that you don't swap in malicious code into your branch during the build. I know it's incredibly unlikely, but if we're pushing binaries to the world, I won't take that risk. Instead, I've added a step in https://builds.apache.org/job/cassandra-ppc64le-sigar/ to apply exactly [this diff|https://github.com/odaira/sigar/commit/e7ef9b5bd189bc3ec0f7768ad317324d76c8b493.diff] to the upstream repo. > Include 'ppc64le' library for sigar-1.6.4.jar > - > > Key: CASSANDRA-13615 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13615 > Project: Cassandra > Issue Type: Improvement > Components: Libraries > Environment: # arch > ppc64le >Reporter: Amitkumar Ghatwal >Assignee: Michael Shuler > Labels: easyfix > Fix For: 4.0 > > Attachments: libsigar-ppc64le-linux.so > > > Hi All, > sigar-1.6.4.jar does not include a ppc64le library, so we had to install > libsigar-ppc64le-linux.so.As the community has been inactive for long > (https://github.com/hyperic/sigar), requesting the community to include the > ppc64le library directly here. > Attaching the ppc64le library ( *.so) file to be included under > "/lib/sigar-bin". let me know of issues/dependency if any. > FYI - [~ReiOdaira],[~jjirsa], [~mshuler] > Regards, > Amit -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-13615) Include 'ppc64le' library for sigar-1.6.4.jar
[
https://issues.apache.org/jira/browse/CASSANDRA-13615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16206672#comment-16206672
]
Jeff Jirsa edited comment on CASSANDRA-13615 at 10/16/17 10:16 PM:
---
I can't configure it to build your branch, because I can't be 100% positive
that you don't swap in malicious code into your branch during the build. I know
it's incredibly unlikely, but if we're pushing binaries to the world, I won't
take that risk.
Instead, I've added a step in
https://builds.apache.org/job/cassandra-ppc64le-sigar/ to apply exactly [this
diff|https://github.com/odaira/sigar/commit/e7ef9b5bd189bc3ec0f7768ad317324d76c8b493.diff]
to the upstream repo
This
[creates|https://builds.apache.org/job/cassandra-ppc64le-sigar/ws/bindings/java/sigar-bin/lib/]
a {{libsigar-ppc64le-linux.so}} with md5: {{70e1b6a5be21752ce7bb05afa8541548}}
[~mshuler] agree with this process?
was (Author: jjirsa):
I can't configure it to build your branch, because I can't be 100% positive
that you don't swap in malicious code into your branch during the build. I know
it's incredibly unlikely, but if we're pushing binaries to the world, I won't
take that risk.
Instead, I've added a step in
https://builds.apache.org/job/cassandra-ppc64le-sigar/ to apply exactly [this
diff|https://github.com/odaira/sigar/commit/e7ef9b5bd189bc3ec0f7768ad317324d76c8b493.diff]
to the upstream repo.
> Include 'ppc64le' library for sigar-1.6.4.jar
> -
>
> Key: CASSANDRA-13615
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13615
> Project: Cassandra
> Issue Type: Improvement
> Components: Libraries
> Environment: # arch
> ppc64le
>Reporter: Amitkumar Ghatwal
>Assignee: Michael Shuler
> Labels: easyfix
> Fix For: 4.0
>
> Attachments: libsigar-ppc64le-linux.so
>
>
> Hi All,
> sigar-1.6.4.jar does not include a ppc64le library, so we had to install
> libsigar-ppc64le-linux.so.As the community has been inactive for long
> (https://github.com/hyperic/sigar), requesting the community to include the
> ppc64le library directly here.
> Attaching the ppc64le library ( *.so) file to be included under
> "/lib/sigar-bin". let me know of issues/dependency if any.
> FYI - [~ReiOdaira],[~jjirsa], [~mshuler]
> Regards,
> Amit
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13615) Include 'ppc64le' library for sigar-1.6.4.jar
[ https://issues.apache.org/jira/browse/CASSANDRA-13615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16206687#comment-16206687 ] Michael Shuler commented on CASSANDRA-13615: Looks OK to me, thanks! > Include 'ppc64le' library for sigar-1.6.4.jar > - > > Key: CASSANDRA-13615 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13615 > Project: Cassandra > Issue Type: Improvement > Components: Libraries > Environment: # arch > ppc64le >Reporter: Amitkumar Ghatwal >Assignee: Michael Shuler > Labels: easyfix > Fix For: 4.0 > > Attachments: libsigar-ppc64le-linux.so > > > Hi All, > sigar-1.6.4.jar does not include a ppc64le library, so we had to install > libsigar-ppc64le-linux.so.As the community has been inactive for long > (https://github.com/hyperic/sigar), requesting the community to include the > ppc64le library directly here. > Attaching the ppc64le library ( *.so) file to be included under > "/lib/sigar-bin". let me know of issues/dependency if any. > FYI - [~ReiOdaira],[~jjirsa], [~mshuler] > Regards, > Amit -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Reopened] (CASSANDRA-13615) Include 'ppc64le' library for sigar-1.6.4.jar
[ https://issues.apache.org/jira/browse/CASSANDRA-13615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Jirsa reopened CASSANDRA-13615: > Include 'ppc64le' library for sigar-1.6.4.jar > - > > Key: CASSANDRA-13615 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13615 > Project: Cassandra > Issue Type: Improvement > Components: Libraries > Environment: # arch > ppc64le >Reporter: Amitkumar Ghatwal >Assignee: Michael Shuler > Labels: easyfix > Fix For: 4.0 > > Attachments: libsigar-ppc64le-linux.so > > > Hi All, > sigar-1.6.4.jar does not include a ppc64le library, so we had to install > libsigar-ppc64le-linux.so.As the community has been inactive for long > (https://github.com/hyperic/sigar), requesting the community to include the > ppc64le library directly here. > Attaching the ppc64le library ( *.so) file to be included under > "/lib/sigar-bin". let me know of issues/dependency if any. > FYI - [~ReiOdaira],[~jjirsa], [~mshuler] > Regards, > Amit -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13885) Allow to run full repairs in 3.0 without additional cost of anti-compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-13885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16206922#comment-16206922 ] Kurt Greaves commented on CASSANDRA-13885: -- I don't understand why providing a flag to skip anti-compaction for full repairs is such a big deal? For anyone using vnodes and full repairs this is going to make it much more difficult to repair at the same rate as previous, as they'll only be able to run one repair per table at a time. > Allow to run full repairs in 3.0 without additional cost of anti-compaction > --- > > Key: CASSANDRA-13885 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13885 > Project: Cassandra > Issue Type: Bug >Reporter: Thomas Steinmaurer > > This ticket is basically the result of the discussion in Cassandra user list: > https://www.mail-archive.com/user@cassandra.apache.org/msg53562.html > I was asked to open a ticket by Paulo Motta to think about back-porting > running full repairs without the additional cost of anti-compaction. > Basically there is no way in 3.0 to run full repairs from several nodes > concurrently without troubles caused by (overlapping?) anti-compactions. > Coming from 2.1 this is a major change from an operational POV, basically > breaking any e.g. cron job based solution kicking off -pr based repairs on > several nodes concurrently. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-13885) Allow to run full repairs in 3.0 without additional cost of anti-compaction
[
https://issues.apache.org/jira/browse/CASSANDRA-13885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16206972#comment-16206972
]
Blake Eggleston edited comment on CASSANDRA-13885 at 10/17/17 4:03 AM:
---
[~KurtG] from my previous comment:
{quote}
fixing this would mean some non-trivial changes to repair behavior which have
the potential to affect correctness
{quote}
in other words, the changes that would be needed to add support for this flag
would be invasive enough that there would be a real risk of breaking other,
more critical things
was (Author: bdeggleston):
[~KurtG] from my previous comment:
{quote}
fixing this would mean some non-trivial changes to repair behavior which have
the potential to affect correctness
{quote}
in other words, the changes that would be needed to add support for this flag
would be invasive enough that there would be a real risk of breaking other.
more critical things
> Allow to run full repairs in 3.0 without additional cost of anti-compaction
> ---
>
> Key: CASSANDRA-13885
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13885
> Project: Cassandra
> Issue Type: Bug
>Reporter: Thomas Steinmaurer
>
> This ticket is basically the result of the discussion in Cassandra user list:
> https://www.mail-archive.com/user@cassandra.apache.org/msg53562.html
> I was asked to open a ticket by Paulo Motta to think about back-porting
> running full repairs without the additional cost of anti-compaction.
> Basically there is no way in 3.0 to run full repairs from several nodes
> concurrently without troubles caused by (overlapping?) anti-compactions.
> Coming from 2.1 this is a major change from an operational POV, basically
> breaking any e.g. cron job based solution kicking off -pr based repairs on
> several nodes concurrently.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13885) Allow to run full repairs in 3.0 without additional cost of anti-compaction
[
https://issues.apache.org/jira/browse/CASSANDRA-13885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16206972#comment-16206972
]
Blake Eggleston commented on CASSANDRA-13885:
-
[~KurtG] from my previous comment:
{quote}
fixing this would mean some non-trivial changes to repair behavior which have
the potential to affect correctness
{quote}
in other words, the changes that would be needed to add support for this flag
would be invasive enough that there would be a real risk of breaking other.
more critical things
> Allow to run full repairs in 3.0 without additional cost of anti-compaction
> ---
>
> Key: CASSANDRA-13885
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13885
> Project: Cassandra
> Issue Type: Bug
>Reporter: Thomas Steinmaurer
>
> This ticket is basically the result of the discussion in Cassandra user list:
> https://www.mail-archive.com/user@cassandra.apache.org/msg53562.html
> I was asked to open a ticket by Paulo Motta to think about back-porting
> running full repairs without the additional cost of anti-compaction.
> Basically there is no way in 3.0 to run full repairs from several nodes
> concurrently without troubles caused by (overlapping?) anti-compactions.
> Coming from 2.1 this is a major change from an operational POV, basically
> breaking any e.g. cron job based solution kicking off -pr based repairs on
> several nodes concurrently.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13885) Allow to run full repairs in 3.0 without additional cost of anti-compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-13885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16206984#comment-16206984 ] Kurt Greaves commented on CASSANDRA-13885: -- OK, so you literally meant that it would be complex (code-wise) to skip anti-compaction? Or is this referring to the complexities that Stefan mentioned, i.e, mixing incremental with full repairs would cause problems? > Allow to run full repairs in 3.0 without additional cost of anti-compaction > --- > > Key: CASSANDRA-13885 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13885 > Project: Cassandra > Issue Type: Bug >Reporter: Thomas Steinmaurer > > This ticket is basically the result of the discussion in Cassandra user list: > https://www.mail-archive.com/user@cassandra.apache.org/msg53562.html > I was asked to open a ticket by Paulo Motta to think about back-porting > running full repairs without the additional cost of anti-compaction. > Basically there is no way in 3.0 to run full repairs from several nodes > concurrently without troubles caused by (overlapping?) anti-compactions. > Coming from 2.1 this is a major change from an operational POV, basically > breaking any e.g. cron job based solution kicking off -pr based repairs on > several nodes concurrently. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13897) nodetool compact and flush fail with "error: null"
[
https://issues.apache.org/jira/browse/CASSANDRA-13897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Rhoden updated CASSANDRA-13897:
-
Description:
{{nodetool flush}} and {{nodetool compact}} return an error message that is not
clear. This could probably be improved. Both of my two nodes return this error.
{{node tool flush}} Will return this error the first 2-3 times you invoke it,
then the error temporarily disappears. {{nodetool compress}} always returns
this error message no matter how many times you invoke it.
I have tried deleting saved_caches, commit logs, doing nodetool
compact/rebuild/scrub, and nothing seems to remove the error.
{noformat}
cass@s5:~/apache-cassandra-3.11.0$ nodetool compact
error: null
-- StackTrace --
java.lang.AssertionError
at
org.apache.cassandra.cache.ChunkCache$CachingRebufferer.(ChunkCache.java:222)
at org.apache.cassandra.cache.ChunkCache.wrap(ChunkCache.java:175)
at
org.apache.cassandra.io.util.FileHandle$Builder.maybeCached(FileHandle.java:412)
at
org.apache.cassandra.io.util.FileHandle$Builder.complete(FileHandle.java:381)
at
org.apache.cassandra.io.util.FileHandle$Builder.complete(FileHandle.java:331)
at
org.apache.cassandra.io.sstable.format.big.BigTableWriter.openFinal(BigTableWriter.java:333)
at
org.apache.cassandra.io.sstable.format.big.BigTableWriter.openFinalEarly(BigTableWriter.java:318)
at
org.apache.cassandra.io.sstable.SSTableRewriter.switchWriter(SSTableRewriter.java:322)
at
org.apache.cassandra.io.sstable.SSTableRewriter.doPrepare(SSTableRewriter.java:370)
at
org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.prepareToCommit(Transactional.java:173)
at
org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.doPrepare(CompactionAwareWriter.java:111)
at
org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.prepareToCommit(Transactional.java:173)
at
org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.finish(Transactional.java:184)
at
org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.finish(CompactionAwareWriter.java:121)
at
org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:220)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at
org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:85)
at
org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:61)
at
org.apache.cassandra.db.compaction.CompactionManager$10.runMayThrow(CompactionManager.java:733)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at
org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
at java.lang.Thread.run(Thread.java:748)
{noformat}
was:
{{nodetool flush}} and {{nodetool compact}} return a nonsensical error message.
This could probably be improved.
I have one node that always returns this error when invoking {{nodetool
compress}}. And intermittently returns this error when calling {{nodetool
flush}}. I have tried deleting saved_caches, commit logs, doing nodetool
compact/rebuild/scrub, and nothing seems to remove the error.
{noformat}
cass@s5:~/apache-cassandra-3.11.0$ nodetool compact
error: null
-- StackTrace --
java.lang.AssertionError
at
org.apache.cassandra.cache.ChunkCache$CachingRebufferer.(ChunkCache.java:222)
at org.apache.cassandra.cache.ChunkCache.wrap(ChunkCache.java:175)
at
org.apache.cassandra.io.util.FileHandle$Builder.maybeCached(FileHandle.java:412)
at
org.apache.cassandra.io.util.FileHandle$Builder.complete(FileHandle.java:381)
at
org.apache.cassandra.io.util.FileHandle$Builder.complete(FileHandle.java:331)
at
org.apache.cassandra.io.sstable.format.big.BigTableWriter.openFinal(BigTableWriter.java:333)
at
org.apache.cassandra.io.sstable.format.big.BigTableWriter.openFinalEarly(BigTableWriter.java:318)
at
org.apache.cassandra.io.sstable.SSTableRewriter.switchWriter(SSTableRewriter.java:322)
at
org.apache.cassandra.io.sstable.SSTableRewriter.doPrepare(SSTableRewriter.java:370)
at
org.apache.cassandra.utils.concurrent.Transactio
[jira] [Updated] (CASSANDRA-13897) nodetool compact and flush fail with "error: null"
[
https://issues.apache.org/jira/browse/CASSANDRA-13897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Rhoden updated CASSANDRA-13897:
-
Description:
{{nodetool flush}} and {{nodetool compact}} return an error message that is not
clear. This could probably be improved. Both of my two nodes return this error.
{{nodetool flush}} Will return this error the first 2-3 times you invoke it,
then the error temporarily disappears. {{nodetool compress}} always returns
this error message no matter how many times you invoke it.
I have tried deleting saved_caches, commit logs, doing nodetool
compact/rebuild/scrub, and nothing seems to remove the error.
{noformat}
cass@s5:~/apache-cassandra-3.11.0$ nodetool compact
error: null
-- StackTrace --
java.lang.AssertionError
at
org.apache.cassandra.cache.ChunkCache$CachingRebufferer.(ChunkCache.java:222)
at org.apache.cassandra.cache.ChunkCache.wrap(ChunkCache.java:175)
at
org.apache.cassandra.io.util.FileHandle$Builder.maybeCached(FileHandle.java:412)
at
org.apache.cassandra.io.util.FileHandle$Builder.complete(FileHandle.java:381)
at
org.apache.cassandra.io.util.FileHandle$Builder.complete(FileHandle.java:331)
at
org.apache.cassandra.io.sstable.format.big.BigTableWriter.openFinal(BigTableWriter.java:333)
at
org.apache.cassandra.io.sstable.format.big.BigTableWriter.openFinalEarly(BigTableWriter.java:318)
at
org.apache.cassandra.io.sstable.SSTableRewriter.switchWriter(SSTableRewriter.java:322)
at
org.apache.cassandra.io.sstable.SSTableRewriter.doPrepare(SSTableRewriter.java:370)
at
org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.prepareToCommit(Transactional.java:173)
at
org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.doPrepare(CompactionAwareWriter.java:111)
at
org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.prepareToCommit(Transactional.java:173)
at
org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.finish(Transactional.java:184)
at
org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.finish(CompactionAwareWriter.java:121)
at
org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:220)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at
org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:85)
at
org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:61)
at
org.apache.cassandra.db.compaction.CompactionManager$10.runMayThrow(CompactionManager.java:733)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at
org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
at java.lang.Thread.run(Thread.java:748)
{noformat}
was:
{{nodetool flush}} and {{nodetool compact}} return an error message that is not
clear. This could probably be improved. Both of my two nodes return this error.
{{node tool flush}} Will return this error the first 2-3 times you invoke it,
then the error temporarily disappears. {{nodetool compress}} always returns
this error message no matter how many times you invoke it.
I have tried deleting saved_caches, commit logs, doing nodetool
compact/rebuild/scrub, and nothing seems to remove the error.
{noformat}
cass@s5:~/apache-cassandra-3.11.0$ nodetool compact
error: null
-- StackTrace --
java.lang.AssertionError
at
org.apache.cassandra.cache.ChunkCache$CachingRebufferer.(ChunkCache.java:222)
at org.apache.cassandra.cache.ChunkCache.wrap(ChunkCache.java:175)
at
org.apache.cassandra.io.util.FileHandle$Builder.maybeCached(FileHandle.java:412)
at
org.apache.cassandra.io.util.FileHandle$Builder.complete(FileHandle.java:381)
at
org.apache.cassandra.io.util.FileHandle$Builder.complete(FileHandle.java:331)
at
org.apache.cassandra.io.sstable.format.big.BigTableWriter.openFinal(BigTableWriter.java:333)
at
org.apache.cassandra.io.sstable.format.big.BigTableWriter.openFinalEarly(BigTableWriter.java:318)
at
org.apache.cassandra.io.sstable.SSTableRewriter.switchWriter(SSTableRewriter.java:322)
at
org.apache.cassandra.io.sstable.SSTableRe
[jira] [Updated] (CASSANDRA-13897) nodetool compact and flush fail with "error: null"
[
https://issues.apache.org/jira/browse/CASSANDRA-13897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Rhoden updated CASSANDRA-13897:
-
Reproduced In: 3.11.1, 3.11.0 (was: 3.11.0)
> nodetool compact and flush fail with "error: null"
> --
>
> Key: CASSANDRA-13897
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13897
> Project: Cassandra
> Issue Type: Bug
> Components: Compaction
> Environment: * Apache Cassandra 3.11.0
> * Linux 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:04:33 UTC 2017 x86_64
> x86_64 x86_64 GNU/Linux
> * jdk1.8.0_144
>Reporter: Jacob Rhoden
>Priority: Minor
>
> {{nodetool flush}} and {{nodetool compact}} return an error message that is
> not clear. This could probably be improved. Both of my two nodes return this
> error.
> {{nodetool flush}} Will return this error the first 2-3 times you invoke it,
> then the error temporarily disappears. {{nodetool compress}} always returns
> this error message no matter how many times you invoke it.
> I have tried deleting saved_caches, commit logs, doing nodetool
> compact/rebuild/scrub, and nothing seems to remove the error.
> {noformat}
> cass@s5:~/apache-cassandra-3.11.0$ nodetool compact
> error: null
> -- StackTrace --
> java.lang.AssertionError
> at
> org.apache.cassandra.cache.ChunkCache$CachingRebufferer.(ChunkCache.java:222)
> at org.apache.cassandra.cache.ChunkCache.wrap(ChunkCache.java:175)
> at
> org.apache.cassandra.io.util.FileHandle$Builder.maybeCached(FileHandle.java:412)
> at
> org.apache.cassandra.io.util.FileHandle$Builder.complete(FileHandle.java:381)
> at
> org.apache.cassandra.io.util.FileHandle$Builder.complete(FileHandle.java:331)
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.openFinal(BigTableWriter.java:333)
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.openFinalEarly(BigTableWriter.java:318)
> at
> org.apache.cassandra.io.sstable.SSTableRewriter.switchWriter(SSTableRewriter.java:322)
> at
> org.apache.cassandra.io.sstable.SSTableRewriter.doPrepare(SSTableRewriter.java:370)
> at
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.prepareToCommit(Transactional.java:173)
> at
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.doPrepare(CompactionAwareWriter.java:111)
> at
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.prepareToCommit(Transactional.java:173)
> at
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.finish(Transactional.java:184)
> at
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.finish(CompactionAwareWriter.java:121)
> at
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:220)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:85)
> at
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:61)
> at
> org.apache.cassandra.db.compaction.CompactionManager$10.runMayThrow(CompactionManager.java:733)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13850) Modifying "cassandra-env.sh"
[ https://issues.apache.org/jira/browse/CASSANDRA-13850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16207069#comment-16207069 ] Amitkumar Ghatwal commented on CASSANDRA-13850: --- any updates on this ? > Modifying "cassandra-env.sh" > > > Key: CASSANDRA-13850 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13850 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Amitkumar Ghatwal > Fix For: 4.x > > > Hi All, > Added support for arch in "cassandra-env.sh " with PR : > https://github.com/apache/cassandra/pull/149 > Regards, > Amit -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13615) Include 'ppc64le' library for sigar-1.6.4.jar
[ https://issues.apache.org/jira/browse/CASSANDRA-13615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16207076#comment-16207076 ] Amitkumar Ghatwal commented on CASSANDRA-13615: --- thanks - [~ReiOdaira] for bringing this up and [~jjirsa],[~mshuler] for validating it. now awaiting it to be updated in the trunk !!! > Include 'ppc64le' library for sigar-1.6.4.jar > - > > Key: CASSANDRA-13615 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13615 > Project: Cassandra > Issue Type: Improvement > Components: Libraries > Environment: # arch > ppc64le >Reporter: Amitkumar Ghatwal >Assignee: Michael Shuler > Labels: easyfix > Fix For: 4.0 > > Attachments: libsigar-ppc64le-linux.so > > > Hi All, > sigar-1.6.4.jar does not include a ppc64le library, so we had to install > libsigar-ppc64le-linux.so.As the community has been inactive for long > (https://github.com/hyperic/sigar), requesting the community to include the > ppc64le library directly here. > Attaching the ppc64le library ( *.so) file to be included under > "/lib/sigar-bin". let me know of issues/dependency if any. > FYI - [~ReiOdaira],[~jjirsa], [~mshuler] > Regards, > Amit -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
