[jira] [Resolved] (CASSANDRA-11942) Cannot process role related query just after restart
[ https://issues.apache.org/jira/browse/CASSANDRA-11942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ZhaoYang resolved CASSANDRA-11942. -- Resolution: Not A Problem As Sam explained, the delay is expected to wait for cluster sync. though a smaller default looks better. > Cannot process role related query just after restart > > > Key: CASSANDRA-11942 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11942 > Project: Cassandra > Issue Type: Bug > Environment: Ubuntu 14.04.4 > Cassandra 3.0.6 (single node) > Python (2.7) connector with Native protocol v3 >Reporter: Petr Malik > > I get the following error from Python client when executing ALTER USER 'foo' > WITH PASSWORD %s; just after service restart. > It works if I wait for some 5s before executing the statement. > From system.log: > 2016-06-01 22:07:01.458 InvalidRequest: Error from server: code=2200 [Invalid > query] message="Cannot process role related query as the role manager isn't > yet setup. This is > likely because some of nodes in the cluster are on version 2.1 or earlier. > You need to upgrade all nodes to Cassandra 2.2 or more to use roles." > INFO [main] 2016-06-01 22:06:51,637 Server.java:162 - Starting listening for > CQL clients on /127.0.0.1:9042 (unencrypted)... > WARN [main] 2016-06-01 22:06:54,646 Slf4JLogger.java:136 - Failed to > generate a seed from SecureRandom within 3 seconds. Not enough entrophy? > INFO [main] 2016-06-01 22:06:54,680 CassandraDaemon.java:471 - Not starting > RPC server as requested. Use JMX (StorageService->startRPCServer()) or > nodetool (enablethrift) to start it -- 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-13581) Adding plugins support to Cassandra's webpage
[ https://issues.apache.org/jira/browse/CASSANDRA-13581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16074273#comment-16074273 ] Amitkumar Ghatwal commented on CASSANDRA-13581: --- Any comments/updates on the above please ? - [~jjirsa] [~spo...@gmail.com] > Adding plugins support to Cassandra's webpage > - > > Key: CASSANDRA-13581 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13581 > Project: Cassandra > Issue Type: Improvement > Components: Documentation and Website >Reporter: Amitkumar Ghatwal > Labels: documentation > Fix For: 4.x > > > Hi [~spo...@gmail.com], > As was suggested here : > http://www.mail-archive.com/dev@cassandra.apache.org/msg11183.html . Have > created the necessary *.rst file to create "plugins" link here : > https://cassandra.apache.org/doc/latest/. > Have followed the steps here : > https://cassandra.apache.org/doc/latest/development/documentation.html and > raised a PR : https://github.com/apache/cassandra/pull/118 for introducing > plugins support on Cassandra's Webpage. > Let me know your review comments and if i have not done things correctly to > make changes to cassandra's website i can rectify the same. -- 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=16074271#comment-16074271 ] Amitkumar Ghatwal commented on CASSANDRA-13615: --- Any comments/updates on the above please ? - [~mshuler] [~jjirsa] > 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 > Labels: easyfix > Fix For: 3.0.x, 3.11.x, 4.x > > 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-13601) Changes requested to the cassandra's debian + rpm installers packages
[ https://issues.apache.org/jira/browse/CASSANDRA-13601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16074265#comment-16074265 ] Amitkumar Ghatwal commented on CASSANDRA-13601: --- Any comments/updates on the above please - [~jjirsa] [~mshuler] ? > Changes requested to the cassandra's debian + rpm installers packages > - > > Key: CASSANDRA-13601 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13601 > Project: Cassandra > Issue Type: Improvement > Components: Packaging > Environment: ~$ lscpu > Architecture: ppc64le > Byte Order:Little Endian >Reporter: Amitkumar Ghatwal >Priority: Minor > Labels: lhf > Fix For: 3.0.x, 3.11.x, 4.x > > Attachments: ppc64le_unaligned_memory_access.patch > > > Hi All, > Thanks [~mshuler] for helping in installing cassandra using arch independent > installers for debian + rpm packages from here : > http://cassandra.apache.org/download/ > For my architecture - " ppc64le" , the installation process from debian + rpm > wasn't straightforward. And needed below configuration level changes. > For Ubuntu- Cassandra 3.10 release - below changes were needed > 1) echo "deb [arch=amd64] http://www.apache.org/dist/cassandra/debian 310x > main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list > 2) sed -i -e s/Xss256/Xss512/g /etc/cassandra/jvm.options > 3) Removing jna-4.0.0.jar and replacing it with latest jna-4.4.0.jar in > (/usr/share/cassandra/lib)- Downloaded from here . > 4) Restart cassandra service > For RHEL - Cassandra 3.0.13 release - below changes were needed > 1) sed -i -e s/Xss256/Xss512/g /etc/cassandra/default.conf/cassandra-env.sh > 3) Removing jna-4.0.0.jar and replacing it with latest jna-4.4.0.jar in > (/usr/share/cassandra/lib)- Downloaded from here . > 4) Restart cassandra service > Could you please help in introducing above changes so that cassandra can be > installed from the debian + rpm pcakages and will indeed become architecture > independent. > 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-12960) Pending hinted hand-offs are replayed after TRUNCATE
[
https://issues.apache.org/jira/browse/CASSANDRA-12960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16074244#comment-16074244
]
ZhaoYang commented on CASSANDRA-12960:
--
because hints are not stored based on columnfamilies and it's based on
endpoints..
one possible way is to store a {{truncate/drop time}} for each table metadata
at each node.
when replaying hints, if hint_time older than {{truncate time}}, ignore hints
> Pending hinted hand-offs are replayed after TRUNCATE
>
>
> Key: CASSANDRA-12960
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12960
> Project: Cassandra
> Issue Type: Bug
> Components: Streaming and Messaging
> Environment: Cassandra 2.2.8
> Amazon Linux AMI 2016.03
>Reporter: Yuji Ito
>Priority: Minor
> Attachments: stale_data.sh
>
>
> I could read stale data after truncating a table.
> The issue happens when the truncation is executed while a node is starting.
> According to logs, pending hinted hand-offs were replayed after the
> truncation.
> *cluster*:
> - C* 2.2.8
> - a cluster has 3 nodes
> - replication_factor: 3
> *steps to reproduce* (the attached script):
> # kill a node
> # insert/update some records
> # restart the killed node
> # truncate the table (not to wait for the killed node's startup)
> # kill another node (this step isn't essential)
> # read all data
--
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-12484) Unknown exception caught while attempting to update MaterializedView! findkita.kitas java.lang.AssertionErro
[ https://issues.apache.org/jira/browse/CASSANDRA-12484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16074226#comment-16074226 ] ZhaoYang commented on CASSANDRA-12484: -- [~cordlesswool] I will mark it as resolved in 3.8 by C*-12247. > Unknown exception caught while attempting to update MaterializedView! > findkita.kitas java.lang.AssertionErro > > > Key: CASSANDRA-12484 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12484 > Project: Cassandra > Issue Type: Bug > Components: Materialized Views > Environment: Docker Container with Cassandra version 3.7 running on > local pc >Reporter: cordlessWool >Priority: Critical > > After restart my cassandra node does not start anymore. Ends with following > error message. > ERROR 18:39:37 Unknown exception caught while attempting to update > MaterializedView! findkita.kitas > java.lang.AssertionError: We shouldn't have got there is the base row had no > associated entry > Cassandra has heavy cpu usage and use 2,1 gb of memory there is be 1gb more > available. I run nodetool cleanup and repair, but did not help. > I have 5 materialzied views on this table, but the amount of rows in table is > under 2000, that is not much. > The cassandra runs in a docker container. The container is access able, but > can not call cqlsh and my website cound not connect too -- 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-12484) Unknown exception caught while attempting to update MaterializedView! findkita.kitas java.lang.AssertionErro
[ https://issues.apache.org/jira/browse/CASSANDRA-12484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ZhaoYang resolved CASSANDRA-12484. -- Resolution: Duplicate > Unknown exception caught while attempting to update MaterializedView! > findkita.kitas java.lang.AssertionErro > > > Key: CASSANDRA-12484 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12484 > Project: Cassandra > Issue Type: Bug > Components: Materialized Views > Environment: Docker Container with Cassandra version 3.7 running on > local pc >Reporter: cordlessWool >Priority: Critical > > After restart my cassandra node does not start anymore. Ends with following > error message. > ERROR 18:39:37 Unknown exception caught while attempting to update > MaterializedView! findkita.kitas > java.lang.AssertionError: We shouldn't have got there is the base row had no > associated entry > Cassandra has heavy cpu usage and use 2,1 gb of memory there is be 1gb more > available. I run nodetool cleanup and repair, but did not help. > I have 5 materialzied views on this table, but the amount of rows in table is > under 2000, that is not much. > The cassandra runs in a docker container. The container is access able, but > can not call cqlsh and my website cound not connect too -- 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-13072) Cassandra failed to run on Linux-aarch64
[
https://issues.apache.org/jira/browse/CASSANDRA-13072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16074174#comment-16074174
]
Shunsuke Nakamura edited comment on CASSANDRA-13072 at 7/5/17 2:22 AM:
---
Since jna upgrade to 4.4.0, it causes working the latest Cassandra 3.11 on
stable RHEL6 OS difficult because {{jna-4.4.0}} depends on glibc >= 2.14 but
glibc version is 2.12 there.
In fact, we tried to upgrade from 3.9 to 3.11.0 on CentOS6.8 machine, it failed
on restarting as follows:
{code}
ERROR [main] 2017-07-05 10:13:54,219 NativeLibraryLinux.java:62 - Failed to
link the C library against JNA. Native methods will be unavailable.
java.lang.UnsatisfiedLinkError: /tmp/jna-118167/jna4905164479741635539.tmp:
/lib64/libc.so.6: version `GLIBC_2.14' not found (required by
/tmp/jna-118167/jna4905164479741635539.tmp)
{code}
According to [this elasticsearch's
ticket|https://github.com/elastic/elasticsearch/issues/23640], we could choose
some option.
was (Author: sunsuk7tp):
Since jna upgrade to 4.4.0, it causes working the latest Cassandra 3.11 on
stable RHEL6 OS difficult because {{jna-4.4.0}} depends on glibc > 2.14 but
glibc version is 2.12 there.
In fact, we tried to upgrade from 3.9 to 3.11.0 on CentOS6.8 machine, it failed
on restarting as follows:
{code}
ERROR [main] 2017-07-05 10:13:54,219 NativeLibraryLinux.java:62 - Failed to
link the C library against JNA. Native methods will be unavailable.
java.lang.UnsatisfiedLinkError: /tmp/jna-118167/jna4905164479741635539.tmp:
/lib64/libc.so.6: version `GLIBC_2.14' not found (required by
/tmp/jna-118167/jna4905164479741635539.tmp)
{code}
According to [this elasticsearch's
ticket|https://github.com/elastic/elasticsearch/issues/23640], we could choose
some option.
> Cassandra failed to run on Linux-aarch64
>
>
> Key: CASSANDRA-13072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13072
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Hardware: ARM aarch64
> OS: Ubuntu 16.04.1 LTS
>Reporter: Jun He
>Assignee: Benjamin Lerer
> Labels: incompatible
> Fix For: 3.0.14, 3.11.0, 4.0
>
> Attachments: compat_report.html
>
>
> Steps to reproduce:
> 1. Download cassandra latest source
> 2. Build it with "ant"
> 3. Run with "./bin/cassandra". Daemon is crashed with following error message:
> {quote}
> INFO 05:30:21 Initializing system.schema_functions
> INFO 05:30:21 Initializing system.schema_aggregates
> ERROR 05:30:22 Exception in thread Thread[MemtableFlushWriter:1,5,main]
> java.lang.NoClassDefFoundError: Could not initialize class com.sun.jna.Native
> at
> org.apache.cassandra.utils.memory.MemoryUtil.allocate(MemoryUtil.java:97)
> ~[main/:na]
> at org.apache.cassandra.io.util.Memory.(Memory.java:74)
> ~[main/:na]
> at org.apache.cassandra.io.util.SafeMemory.(SafeMemory.java:32)
> ~[main/:na]
> at
> org.apache.cassandra.io.compress.CompressionMetadata$Writer.(CompressionMetadata.java:316)
> ~[main/:na]
> at
> org.apache.cassandra.io.compress.CompressionMetadata$Writer.open(CompressionMetadata.java:330)
> ~[main/:na]
> at
> org.apache.cassandra.io.compress.CompressedSequentialWriter.(CompressedSequentialWriter.java:76)
> ~[main/:na]
> at
> org.apache.cassandra.io.util.SequentialWriter.open(SequentialWriter.java:163)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.(BigTableWriter.java:73)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.format.big.BigFormat$WriterFactory.open(BigFormat.java:93)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.format.SSTableWriter.create(SSTableWriter.java:96)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.SimpleSSTableMultiWriter.create(SimpleSSTableMultiWriter.java:114)
> ~[main/:na]
> at
> org.apache.cassandra.db.compaction.AbstractCompactionStrategy.createSSTableMultiWriter(AbstractCompactionStrategy.java:519)
> ~[main/:na]
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.createSSTableMultiWriter(CompactionStrategyManager.java:497)
> ~[main/:na]
> at
> org.apache.cassandra.db.ColumnFamilyStore.createSSTableMultiWriter(ColumnFamilyStore.java:480)
> ~[main/:na]
> at
> org.apache.cassandra.db.Memtable.createFlushWriter(Memtable.java:439)
> ~[main/:na]
> at
> org.apache.cassandra.db.Memtable.writeSortedContents(Memtable.java:371)
> ~[main/:na]
> at org.apache.cassandra.db.Memtable.flush(Memtable.java:332)
> ~[main/:na]
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1054)
> ~[main/:na]
> at
> java.util.concurrent.ThreadPoo
[jira] [Commented] (CASSANDRA-13072) Cassandra failed to run on Linux-aarch64
[
https://issues.apache.org/jira/browse/CASSANDRA-13072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16074174#comment-16074174
]
Shunsuke Nakamura commented on CASSANDRA-13072:
---
Since jna upgrade to 4.4.0, it causes working the latest Cassandra 3.11 on
stable RHEL6 OS difficult because {{jna-4.4.0}} depends on glibc > 2.14 but
glibc version is 2.12 there.
In fact, we tried to upgrade from 3.9 to 3.11.0 on CentOS6.8 machine, it failed
on restarting as follows:
{code}
ERROR [main] 2017-07-05 10:13:54,219 NativeLibraryLinux.java:62 - Failed to
link the C library against JNA. Native methods will be unavailable.
java.lang.UnsatisfiedLinkError: /tmp/jna-118167/jna4905164479741635539.tmp:
/lib64/libc.so.6: version `GLIBC_2.14' not found (required by
/tmp/jna-118167/jna4905164479741635539.tmp)
{code}
According to [this elasticsearch's
ticket|https://github.com/elastic/elasticsearch/issues/23640], we could choose
some option.
> Cassandra failed to run on Linux-aarch64
>
>
> Key: CASSANDRA-13072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13072
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Hardware: ARM aarch64
> OS: Ubuntu 16.04.1 LTS
>Reporter: Jun He
>Assignee: Benjamin Lerer
> Labels: incompatible
> Fix For: 3.0.14, 3.11.0, 4.0
>
> Attachments: compat_report.html
>
>
> Steps to reproduce:
> 1. Download cassandra latest source
> 2. Build it with "ant"
> 3. Run with "./bin/cassandra". Daemon is crashed with following error message:
> {quote}
> INFO 05:30:21 Initializing system.schema_functions
> INFO 05:30:21 Initializing system.schema_aggregates
> ERROR 05:30:22 Exception in thread Thread[MemtableFlushWriter:1,5,main]
> java.lang.NoClassDefFoundError: Could not initialize class com.sun.jna.Native
> at
> org.apache.cassandra.utils.memory.MemoryUtil.allocate(MemoryUtil.java:97)
> ~[main/:na]
> at org.apache.cassandra.io.util.Memory.(Memory.java:74)
> ~[main/:na]
> at org.apache.cassandra.io.util.SafeMemory.(SafeMemory.java:32)
> ~[main/:na]
> at
> org.apache.cassandra.io.compress.CompressionMetadata$Writer.(CompressionMetadata.java:316)
> ~[main/:na]
> at
> org.apache.cassandra.io.compress.CompressionMetadata$Writer.open(CompressionMetadata.java:330)
> ~[main/:na]
> at
> org.apache.cassandra.io.compress.CompressedSequentialWriter.(CompressedSequentialWriter.java:76)
> ~[main/:na]
> at
> org.apache.cassandra.io.util.SequentialWriter.open(SequentialWriter.java:163)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.(BigTableWriter.java:73)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.format.big.BigFormat$WriterFactory.open(BigFormat.java:93)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.format.SSTableWriter.create(SSTableWriter.java:96)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.SimpleSSTableMultiWriter.create(SimpleSSTableMultiWriter.java:114)
> ~[main/:na]
> at
> org.apache.cassandra.db.compaction.AbstractCompactionStrategy.createSSTableMultiWriter(AbstractCompactionStrategy.java:519)
> ~[main/:na]
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.createSSTableMultiWriter(CompactionStrategyManager.java:497)
> ~[main/:na]
> at
> org.apache.cassandra.db.ColumnFamilyStore.createSSTableMultiWriter(ColumnFamilyStore.java:480)
> ~[main/:na]
> at
> org.apache.cassandra.db.Memtable.createFlushWriter(Memtable.java:439)
> ~[main/:na]
> at
> org.apache.cassandra.db.Memtable.writeSortedContents(Memtable.java:371)
> ~[main/:na]
> at org.apache.cassandra.db.Memtable.flush(Memtable.java:332)
> ~[main/:na]
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1054)
> ~[main/:na]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> ~[na:1.8.0_111]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> ~[na:1.8.0_111]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_111]
> {quote}
> Analyze:
> This issue is caused by bundled jna-4.0.0.jar which doesn't come with aarch64
> native support. Replace lib/jna-4.0.0.jar with jna-4.2.0.jar from
> http://central.maven.org/maven2/net/java/dev/jna/jna/4.2.0/ can fix this
> problem.
> Attached is the binary compatibility report of jna.jar between 4.0 and 4.2.
> The result is good (97.4%). So is there possibility to upgrade jna to 4.2.0
> in upstream? Should there be any kind of tests to execute, please kindly
> point me. Thanks a lot.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---
[jira] [Comment Edited] (CASSANDRA-13562) nodes in cluster gets into split-brain mode
[ https://issues.apache.org/jira/browse/CASSANDRA-13562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16074128#comment-16074128 ] ZhaoYang edited comment on CASSANDRA-13562 at 7/5/17 12:32 AM: --- you may consider checking `phi_convict_threshold` in cassandra.yaml and turning on the logging for phi value in gossip. then you will get a better idea why c* node thinks another as down node. was (Author: jasonstack): you may consider checking `phi_convict_threshold` in cassandra.yaml and turning the logging for phi value in gossip. then you will get a better idea why c* node thinks another as down node. > nodes in cluster gets into split-brain mode > --- > > Key: CASSANDRA-13562 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13562 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Jaydeepkumar Chovatia > Fix For: 3.0.x > > > We have seen nodes in Cassandra (3.0.11) ring gets into split-brain somehow. > We don't know exact reproducible steps but here is our observation: > Let's assume we have 5 node cluster n1,n2,n3,n4,n5. In this bug when do > nodetool status on each node then each one has different view of DN node > e.g. > n1 sees n3 as DN and other nodes are UN > n3 sees n4 as DN and other nodes are UN > n4 sees n5 as DN and other nodes are UN and so on... > One thing we have observed is once n/w link is broken and restored then > sometimes nodes go into this split-brain mode but we still don't have exact > reproducible steps. > Please let us know if I am missing anything specific here. -- 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-13562) nodes in cluster gets into split-brain mode
[ https://issues.apache.org/jira/browse/CASSANDRA-13562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16074128#comment-16074128 ] ZhaoYang commented on CASSANDRA-13562: -- you may consider checking `phi_convict_threshold` in cassandra.yaml and turning the logging for phi value in gossip. then you will get a better idea why c* node thinks another as down node. > nodes in cluster gets into split-brain mode > --- > > Key: CASSANDRA-13562 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13562 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Jaydeepkumar Chovatia > Fix For: 3.0.x > > > We have seen nodes in Cassandra (3.0.11) ring gets into split-brain somehow. > We don't know exact reproducible steps but here is our observation: > Let's assume we have 5 node cluster n1,n2,n3,n4,n5. In this bug when do > nodetool status on each node then each one has different view of DN node > e.g. > n1 sees n3 as DN and other nodes are UN > n3 sees n4 as DN and other nodes are UN > n4 sees n5 as DN and other nodes are UN and so on... > One thing we have observed is once n/w link is broken and restored then > sometimes nodes go into this split-brain mode but we still don't have exact > reproducible steps. > Please let us know if I am missing anything specific here. -- 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-13666) Secondary index query on partition key columns might not return partitions with only static data
[
https://issues.apache.org/jira/browse/CASSANDRA-13666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-13666:
---
Reviewer: Benjamin Lerer
> Secondary index query on partition key columns might not return partitions
> with only static data
>
>
> Key: CASSANDRA-13666
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13666
> Project: Cassandra
> Issue Type: Bug
>Reporter: Benjamin Lerer
>Assignee: Sam Tunnicliffe
>
> The problem can be reproduced with the following test in {{3.0}}:
> {code}
>@Test
> public void testIndexOnPartitionKeyWithPartitionWithoutRows() throws
> Throwable
> {
> createTable("CREATE TABLE %s (pk1 int, pk2 int, c int, s int static,
> v int, PRIMARY KEY((pk1, pk2), c))");
> createIndex("CREATE INDEX ON %s (pk2)");
> execute("INSERT INTO %s (pk1, pk2, c, s, v) VALUES (?, ?, ?, ?, ?)",
> 1, 1, 1, 9, 1);
> execute("INSERT INTO %s (pk1, pk2, c, s, v) VALUES (?, ?, ?, ?, ?)",
> 1, 1, 2, 9, 2);
> execute("INSERT INTO %s (pk1, pk2, c, s, v) VALUES (?, ?, ?, ?, ?)",
> 3, 1, 1, 9, 1);
> execute("INSERT INTO %s (pk1, pk2, c, s, v) VALUES (?, ?, ?, ?, ?)",
> 4, 1, 1, 9, 1);
> flush();
> assertRows(execute("SELECT * FROM %s WHERE pk2 = ?", 1),
>row(1, 1, 1, 9, 1),
>row(1, 1, 2, 9, 2),
>row(3, 1, 1, 9, 1),
>row(4, 1, 1, 9, 1));
> execute("DELETE FROM %s WHERE pk1 = ? AND pk2 = ? AND c = ?", 3, 1,
> 1);
> assertRows(execute("SELECT * FROM %s WHERE pk2 = ?", 1),
>row(1, 1, 1, 9, 1),
>row(1, 1, 2, 9, 2),
>row(3, 1, null, 9, null), // This row will not be returned
>row(4, 1, 1, 9, 1));
> }
> {code}
> The problem seems to be that the index entries for the static data are
> inserted with an empty clustering key. When the first {{SELECT}} is executed
> those entries are removed by {{CompositesSearcher::filterStaleEntries}} which
> consider that those entries are stales. When the second {{SELECT}} is
> executed the index ignore the (3, 1) partition as there is not entry for it
> anymore.
--
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-13666) Secondary index query on partition key columns might not return partitions with only static data
[
https://issues.apache.org/jira/browse/CASSANDRA-13666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer reassigned CASSANDRA-13666:
--
Assignee: Sam Tunnicliffe (was: Benjamin Lerer)
> Secondary index query on partition key columns might not return partitions
> with only static data
>
>
> Key: CASSANDRA-13666
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13666
> Project: Cassandra
> Issue Type: Bug
>Reporter: Benjamin Lerer
>Assignee: Sam Tunnicliffe
>
> The problem can be reproduced with the following test in {{3.0}}:
> {code}
>@Test
> public void testIndexOnPartitionKeyWithPartitionWithoutRows() throws
> Throwable
> {
> createTable("CREATE TABLE %s (pk1 int, pk2 int, c int, s int static,
> v int, PRIMARY KEY((pk1, pk2), c))");
> createIndex("CREATE INDEX ON %s (pk2)");
> execute("INSERT INTO %s (pk1, pk2, c, s, v) VALUES (?, ?, ?, ?, ?)",
> 1, 1, 1, 9, 1);
> execute("INSERT INTO %s (pk1, pk2, c, s, v) VALUES (?, ?, ?, ?, ?)",
> 1, 1, 2, 9, 2);
> execute("INSERT INTO %s (pk1, pk2, c, s, v) VALUES (?, ?, ?, ?, ?)",
> 3, 1, 1, 9, 1);
> execute("INSERT INTO %s (pk1, pk2, c, s, v) VALUES (?, ?, ?, ?, ?)",
> 4, 1, 1, 9, 1);
> flush();
> assertRows(execute("SELECT * FROM %s WHERE pk2 = ?", 1),
>row(1, 1, 1, 9, 1),
>row(1, 1, 2, 9, 2),
>row(3, 1, 1, 9, 1),
>row(4, 1, 1, 9, 1));
> execute("DELETE FROM %s WHERE pk1 = ? AND pk2 = ? AND c = ?", 3, 1,
> 1);
> assertRows(execute("SELECT * FROM %s WHERE pk2 = ?", 1),
>row(1, 1, 1, 9, 1),
>row(1, 1, 2, 9, 2),
>row(3, 1, null, 9, null), // This row will not be returned
>row(4, 1, 1, 9, 1));
> }
> {code}
> The problem seems to be that the index entries for the static data are
> inserted with an empty clustering key. When the first {{SELECT}} is executed
> those entries are removed by {{CompositesSearcher::filterStaleEntries}} which
> consider that those entries are stales. When the second {{SELECT}} is
> executed the index ignore the (3, 1) partition as there is not entry for it
> anymore.
--
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-13667) DROP KEYSPACE or TABLE cause unrelated flushes and compactions on all tables
Stefano Ortolani created CASSANDRA-13667: Summary: DROP KEYSPACE or TABLE cause unrelated flushes and compactions on all tables Key: CASSANDRA-13667 URL: https://issues.apache.org/jira/browse/CASSANDRA-13667 Project: Cassandra Issue Type: Bug Reporter: Stefano Ortolani Priority: Minor As soon as I drop a keyspace or a table, I see _all_ nodes struggling to acknowledge the new schema because of several flushes and compactions happening on _all_ keyspaces and compactions (completely unrelated to the dropped keyspace/table). -- 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-12700) During writing data into Cassandra 3.7.0 using Python driver 3.7 sometimes Connection get lost, because of Server NullPointerException
[
https://issues.apache.org/jira/browse/CASSANDRA-12700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16073821#comment-16073821
]
ZhaoYang commented on CASSANDRA-12700:
--
[~rajesh_con] could you still reproduce it?
> During writing data into Cassandra 3.7.0 using Python driver 3.7 sometimes
> Connection get lost, because of Server NullPointerException
> --
>
> Key: CASSANDRA-12700
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12700
> Project: Cassandra
> Issue Type: Bug
> Components: Core, Materialized Views
> Environment: Cassandra cluster with two nodes running C* version
> 3.7.0 and Python Driver 3.7 using Python 2.7.11.
> OS: Red Hat Enterprise Linux 6.x x64,
> RAM :8GB
> DISK :210GB
> Cores: 2
> Java 1.8.0_73 JRE
>Reporter: Rajesh Radhakrishnan
>Assignee: Jeff Jirsa
> Fix For: 2.2.9, 3.0.10, 3.10
>
>
> In our C* cluster we are using the latest Cassandra 3.7.0 (datastax-ddc.3.70)
> with Python driver 3.7. Trying to insert 2 million row or more data into the
> database, but sometimes we are getting "Null pointer Exception".
> We are using Python 2.7.11 and Java 1.8.0_73 in the Cassandra nodes and in
> the client its Python 2.7.12.
> {code:title=cassandra server log}
> ERROR [SharedPool-Worker-6] 2016-09-23 09:42:55,002 Message.java:611 -
> Unexpected exception during request; channel = [id: 0xc208da86,
> L:/IP1.IP2.IP3.IP4:9042 - R:/IP5.IP6.IP7.IP8:58418]
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.serializers.BooleanSerializer.deserialize(BooleanSerializer.java:33)
> ~[apache-cassandra-3.7.0.jar:3.7.0]
> at
> org.apache.cassandra.serializers.BooleanSerializer.deserialize(BooleanSerializer.java:24)
> ~[apache-cassandra-3.7.0.jar:3.7.0]
> at
> org.apache.cassandra.db.marshal.AbstractType.compose(AbstractType.java:113)
> ~[apache-cassandra-3.7.0.jar:3.7.0]
> at
> org.apache.cassandra.cql3.UntypedResultSet$Row.getBoolean(UntypedResultSet.java:273)
> ~[apache-cassandra-3.7.0.jar:3.7.0]
> at
> org.apache.cassandra.auth.CassandraRoleManager$1.apply(CassandraRoleManager.java:85)
> ~[apache-cassandra-3.7.0.jar:3.7.0]
> at
> org.apache.cassandra.auth.CassandraRoleManager$1.apply(CassandraRoleManager.java:81)
> ~[apache-cassandra-3.7.0.jar:3.7.0]
> at
> org.apache.cassandra.auth.CassandraRoleManager.getRoleFromTable(CassandraRoleManager.java:503)
> ~[apache-cassandra-3.7.0.jar:3.7.0]
> at
> org.apache.cassandra.auth.CassandraRoleManager.getRole(CassandraRoleManager.java:485)
> ~[apache-cassandra-3.7.0.jar:3.7.0]
> at
> org.apache.cassandra.auth.CassandraRoleManager.canLogin(CassandraRoleManager.java:298)
> ~[apache-cassandra-3.7.0.jar:3.7.0]
> at org.apache.cassandra.service.ClientState.login(ClientState.java:227)
> ~[apache-cassandra-3.7.0.jar:3.7.0]
> at
> org.apache.cassandra.transport.messages.AuthResponse.execute(AuthResponse.java:79)
> ~[apache-cassandra-3.7.0.jar:3.7.0]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:507)
> [apache-cassandra-3.7.0.jar:3.7.0]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:401)
> [apache-cassandra-3.7.0.jar:3.7.0]
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
> [netty-all-4.0.36.Final.jar:4.0.36.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292)
> [netty-all-4.0.36.Final.jar:4.0.36.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:32)
> [netty-all-4.0.36.Final.jar:4.0.36.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:283)
> [netty-all-4.0.36.Final.jar:4.0.36.Final]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0_73]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
> [apache-cassandra-3.7.0.jar:3.7.0]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
> [apache-cassandra-3.7.0.jar:3.7.0]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_73]
> ERROR [SharedPool-Worker-1] 2016-09-23 09:42:56,238 Message.java:611 -
> Unexpected exception during request; channel = [id: 0x8e2eae00,
> L:/IP1.IP2.IP3.IP4:9042 - R:/IP5.IP6.IP7.IP8:58421]
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.serializers.BooleanSerializer.deserialize(BooleanSerializer.java:33)
> ~[apache-cassandra-3.7.0.jar:3.7.0]
> at
> org.apache.cassandra.seria
[jira] [Created] (CASSANDRA-13666) Secondary index query on partition key columns might not return partitions with only static data
Benjamin Lerer created CASSANDRA-13666:
--
Summary: Secondary index query on partition key columns might not
return partitions with only static data
Key: CASSANDRA-13666
URL: https://issues.apache.org/jira/browse/CASSANDRA-13666
Project: Cassandra
Issue Type: Bug
Reporter: Benjamin Lerer
Assignee: Benjamin Lerer
The problem can be reproduced with the following test in {{3.0}}:
{code}
@Test
public void testIndexOnPartitionKeyWithPartitionWithoutRows() throws
Throwable
{
createTable("CREATE TABLE %s (pk1 int, pk2 int, c int, s int static, v
int, PRIMARY KEY((pk1, pk2), c))");
createIndex("CREATE INDEX ON %s (pk2)");
execute("INSERT INTO %s (pk1, pk2, c, s, v) VALUES (?, ?, ?, ?, ?)", 1,
1, 1, 9, 1);
execute("INSERT INTO %s (pk1, pk2, c, s, v) VALUES (?, ?, ?, ?, ?)", 1,
1, 2, 9, 2);
execute("INSERT INTO %s (pk1, pk2, c, s, v) VALUES (?, ?, ?, ?, ?)", 3,
1, 1, 9, 1);
execute("INSERT INTO %s (pk1, pk2, c, s, v) VALUES (?, ?, ?, ?, ?)", 4,
1, 1, 9, 1);
flush();
assertRows(execute("SELECT * FROM %s WHERE pk2 = ?", 1),
row(1, 1, 1, 9, 1),
row(1, 1, 2, 9, 2),
row(3, 1, 1, 9, 1),
row(4, 1, 1, 9, 1));
execute("DELETE FROM %s WHERE pk1 = ? AND pk2 = ? AND c = ?", 3, 1, 1);
assertRows(execute("SELECT * FROM %s WHERE pk2 = ?", 1),
row(1, 1, 1, 9, 1),
row(1, 1, 2, 9, 2),
row(3, 1, null, 9, null), // This row will not be returned
row(4, 1, 1, 9, 1));
}
{code}
The problem seems to be that the index entries for the static data are inserted
with an empty clustering key. When the first {{SELECT}} is executed those
entries are removed by {{CompositesSearcher::filterStaleEntries}} which
consider that those entries are stales. When the second {{SELECT}} is executed
the index ignore the (3, 1) partition as there is not entry for it anymore.
--
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-13665) nodetool clientlist
Jon Haddad created CASSANDRA-13665: -- Summary: nodetool clientlist Key: CASSANDRA-13665 URL: https://issues.apache.org/jira/browse/CASSANDRA-13665 Project: Cassandra Issue Type: Improvement Reporter: Jon Haddad There should exist a nodetool command that lists each client connection. Ideally it would display the following: * host * protocol version * user logged in as * current keyspace * total queries executed -- 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-13664) RangeFetchMapCalculator should not try to optimise 'trivial' ranges
[ https://issues.apache.org/jira/browse/CASSANDRA-13664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-13664: Status: Patch Available (was: Open) https://github.com/krummas/cassandra/commits/marcuse/opt_large simply filters out ranges considered trivial (less than 1000 tokens for RP and M3P, no trivial ranges for BOP etc), then re-adds them once the optimisation is done. > RangeFetchMapCalculator should not try to optimise 'trivial' ranges > --- > > Key: CASSANDRA-13664 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13664 > Project: Cassandra > Issue Type: Bug >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson > Fix For: 4.x > > > RangeFetchMapCalculator (CASSANDRA-4650) tries to make the number of streams > out of each node as even as possible. > In a typical multi-dc ring the nodes in the dcs are setup using token + 1, > creating many tiny ranges. If we only try to optimise over the number of > streams, it is likely that the amount of data streamed out of each node is > unbalanced. > We should ignore those trivial ranges and only optimise the big ones, then > share the tiny ones over the nodes. -- 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-13664) RangeFetchMapCalculator should not try to optimise 'trivial' ranges
Marcus Eriksson created CASSANDRA-13664: --- Summary: RangeFetchMapCalculator should not try to optimise 'trivial' ranges Key: CASSANDRA-13664 URL: https://issues.apache.org/jira/browse/CASSANDRA-13664 Project: Cassandra Issue Type: Bug Reporter: Marcus Eriksson Assignee: Marcus Eriksson Fix For: 4.x RangeFetchMapCalculator (CASSANDRA-4650) tries to make the number of streams out of each node as even as possible. In a typical multi-dc ring the nodes in the dcs are setup using token + 1, creating many tiny ranges. If we only try to optimise over the number of streams, it is likely that the amount of data streamed out of each node is unbalanced. We should ignore those trivial ranges and only optimise the big ones, then share the tiny ones over the nodes. -- 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-13651) Large amount of CPU used by epoll_wait(.., .., .., 0)
[
https://issues.apache.org/jira/browse/CASSANDRA-13651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16073502#comment-16073502
]
Corentin Chary commented on CASSANDRA-13651:
I ran tests on a 3 node cluster, I can confirm that not using scheduled tasks
and using a simpler batcher removes all the {{epoll_wait(..., 0)}} calls. This
reduces the CPU used by epoll threads.
I need to take more time do check how efficient the batching still is, and
compare the context switchs with and without it.
> Large amount of CPU used by epoll_wait(.., .., .., 0)
> -
>
> Key: CASSANDRA-13651
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13651
> Project: Cassandra
> Issue Type: Bug
>Reporter: Corentin Chary
> Fix For: 4.x
>
>
> I was trying to profile Cassandra under my workload and I kept seeing this
> backtrace:
> {code}
> epollEventLoopGroup-2-3 State: RUNNABLE CPU usage on sample: 240ms
> io.netty.channel.epoll.Native.epollWait0(int, long, int, int) Native.java
> (native)
> io.netty.channel.epoll.Native.epollWait(int, EpollEventArray, int)
> Native.java:111
> io.netty.channel.epoll.EpollEventLoop.epollWait(boolean)
> EpollEventLoop.java:230
> io.netty.channel.epoll.EpollEventLoop.run() EpollEventLoop.java:254
> io.netty.util.concurrent.SingleThreadEventExecutor$5.run()
> SingleThreadEventExecutor.java:858
> io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run()
> DefaultThreadFactory.java:138
> java.lang.Thread.run() Thread.java:745
> {code}
> At fist I though that the profiler might not be able to profile native code
> properly, but I wen't further and I realized that most of the CPU was used by
> {{epoll_wait()}} calls with a timeout of zero.
> Here is the output of perf on this system, which confirms that most of the
> overhead was with timeout == 0.
> {code}
> Samples: 11M of event 'syscalls:sys_enter_epoll_wait', Event count (approx.):
> 11594448
> Overhead Trace output
>
> ◆
> 90.06% epfd: 0x0047, events: 0x7f5588c0c000, maxevents: 0x2000,
> timeout: 0x
> ▒
>5.77% epfd: 0x00b5, events: 0x7fca419ef000, maxevents: 0x1000,
> timeout: 0x
> ▒
>1.98% epfd: 0x00b5, events: 0x7fca419ef000, maxevents: 0x1000,
> timeout: 0x03e8
> ▒
>0.04% epfd: 0x0003, events: 0x2f6af77b9c00, maxevents: 0x0020,
> timeout: 0x
> ▒
>0.04% epfd: 0x002b, events: 0x121ebf63ac00, maxevents: 0x0040,
> timeout: 0x
> ▒
>0.03% epfd: 0x0026, events: 0x7f51f80019c0, maxevents: 0x0020,
> timeout: 0x
> ▒
>0.02% epfd: 0x0003, events: 0x7fe4d80019d0, maxevents: 0x0020,
> timeout: 0x
> {code}
> Running this time with perf record -ag for call traces:
> {code}
> # Children Self sys usr Trace output
>
> #
>
> #
> 8.61% 8.61% 0.00% 8.61% epfd: 0x00a7, events:
> 0x7fca452d6000, maxevents: 0x1000, timeout: 0x
> |
> ---0x1000200af313
>|
> --8.61%--0x7fca6117bdac
> 0x7fca60459804
> epoll_wait
> 2.98% 2.98% 0.00% 2.98% epfd: 0x00a7, events:
> 0x7fca452d6000, maxevents: 0x1000, timeout: 0x03e8
> |
> ---0x1000200af313
>0x7fca6117b830
>0x7fca60459804
>epoll_wait
> {code}
> That looks like a lot of CPU used to wait for nothing. I'm not sure if pref
> reports a per-CPU percentage or a per-system percentage, but that would be
> still be 10% of the total CPU usage of Cassandra at the minimum.
> I went further and found the code of all tha
[jira] [Commented] (CASSANDRA-11223) Queries with LIMIT filtering on clustering columns can return less rows than expected
[
https://issues.apache.org/jira/browse/CASSANDRA-11223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16073492#comment-16073492
]
Andrés de la Peña commented on CASSANDRA-11223:
---
[~blerer],
[CASSANDRA-8272|https://issues.apache.org/jira/browse/CASSANDRA-8272] only
fixes 2i queries.
[CASSANDRA-8273|https://issues.apache.org/jira/browse/CASSANDRA-8273] will move
filtering to coordinator side once
[CASSANDRA-8272|https://issues.apache.org/jira/browse/CASSANDRA-8272] is done,
with [{{RowFilter}}-aware
{{DataLimits}}|https://github.com/adelapena/cassandra/blob/1416d9b082d7f93b187cbf67abd9a917735c4804/src/java/org/apache/cassandra/db/filter/DataLimits.java#L208-L221],
and might be a good place to address this problem.
> Queries with LIMIT filtering on clustering columns can return less rows than
> expected
> -
>
> Key: CASSANDRA-11223
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11223
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>
> A query like {{SELECT * FROM %s WHERE b = 1 LIMIT 2 ALLOW FILTERING}} can
> return less row than expected if the table has some static columns and some
> of the partition have no rows matching b = 1.
> The problem can be reproduced with the following unit test:
> {code}
> public void testFilteringOnClusteringColumnsWithLimitAndStaticColumns()
> throws Throwable
> {
> createTable("CREATE TABLE %s (a int, b int, s int static, c int,
> primary key (a, b))");
> for (int i = 0; i < 3; i++)
> {
> execute("INSERT INTO %s (a, s) VALUES (?, ?)", i, i);
> for (int j = 0; j < 3; j++)
> if (!(i == 0 && j == 1))
> execute("INSERT INTO %s (a, b, c) VALUES (?, ?, ?)",
> i, j, i + j);
> }
> assertRows(execute("SELECT * FROM %s"),
> row(1, 0, 1, 1),
> row(1, 1, 1, 2),
> row(1, 2, 1, 3),
> row(0, 0, 0, 0),
> row(0, 2, 0, 2),
> row(2, 0, 2, 2),
> row(2, 1, 2, 3),
> row(2, 2, 2, 4));
> assertRows(execute("SELECT * FROM %s WHERE b = 1 ALLOW FILTERING"),
> row(1, 1, 1, 2),
> row(2, 1, 2, 3));
> assertRows(execute("SELECT * FROM %s WHERE b = 1 LIMIT 2 ALLOW
> FILTERING"),
> row(1, 1, 1, 2),
> row(2, 1, 2, 3)); // < FAIL It returns only one
> row because the static row of partition 0 is counted and filtered out in
> SELECT statement
> }
> {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] [Comment Edited] (CASSANDRA-13142) Upgradesstables cancels compactions unnecessarily
[ https://issues.apache.org/jira/browse/CASSANDRA-13142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16064774#comment-16064774 ] Kurt Greaves edited comment on CASSANDRA-13142 at 7/4/17 10:09 AM: --- Well, I've seriously broken SSTableRewriterTest. Haven't found out why yet though. edit: seems it was actually already broken edit2: seems it wasn't actually ever broken so ignore this completely. :going_slightly_mad: was (Author: kurtg): Well, I've seriously broken SSTableRewriterTest. Haven't found out why yet though. edit: seems it was actually already broken > Upgradesstables cancels compactions unnecessarily > - > > Key: CASSANDRA-13142 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13142 > Project: Cassandra > Issue Type: Bug >Reporter: Kurt Greaves >Assignee: Kurt Greaves > Attachments: 13142-v1.patch > > > Since at least 1.2 upgradesstables will cancel any compactions bar > validations when run. This was originally determined as a non-issue in > CASSANDRA-3430 however can be quite annoying (especially with STCS) as a > compaction will output the new version anyway. Furthermore, as per > CASSANDRA-12243 it also stops things like view builds and I assume secondary > index builds as well which is not ideal. > We should avoid cancelling compactions unnecessarily. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13371) Remove legacy auth tables support
[
https://issues.apache.org/jira/browse/CASSANDRA-13371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-13371:
---
Description:
Starting with Cassandra 3.0, we include support for converting pre
CASSANDRA-7653 user tables, until they will be dropped by the operator.
Converting e.g. permissions happens by simply copying all of them from
{{permissions}} -> {{role_permissions}}, until the {{permissions}} table has
been dropped.
Upgrading to 4.0 will only be possible from 3.0 upwards, so I think it's safe
to assume that the new permissions table has already been populated, whether
the old table was dropped or not. Therefor I'd suggest to just get rid of the
legacy support.
was:
Starting with Cassandra 3.0, we include support for converting pre
CASSANDRA-7653 user permission tables, until they will be dropped by the
operator. Converting permissions happens by simply copying all of them from
{{permissions}} -> {{role_permissions}}, until the {{permissions}} table has
been dropped.
Upgrading to 4.0 will only be possible from 3.0 upwards, so I think it's safe
to assume that the new permissions table has already been populated, whether
the old table was dropped or not. Therefor I'd suggest to just get rid of the
legacy support.
> Remove legacy auth tables support
> -
>
> Key: CASSANDRA-13371
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13371
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
> Fix For: 4.x
>
>
> Starting with Cassandra 3.0, we include support for converting pre
> CASSANDRA-7653 user tables, until they will be dropped by the operator.
> Converting e.g. permissions happens by simply copying all of them from
> {{permissions}} -> {{role_permissions}}, until the {{permissions}} table has
> been dropped.
> Upgrading to 4.0 will only be possible from 3.0 upwards, so I think it's safe
> to assume that the new permissions table has already been populated, whether
> the old table was dropped or not. Therefor I'd suggest to just get rid of the
> legacy support.
--
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-13371) Remove legacy auth tables support
[
https://issues.apache.org/jira/browse/CASSANDRA-13371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-13371:
---
Summary: Remove legacy auth tables support (was: Remove legacy authz
tables support)
> Remove legacy auth tables support
> -
>
> Key: CASSANDRA-13371
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13371
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
> Fix For: 4.x
>
>
> Starting with Cassandra 3.0, we include support for converting pre
> CASSANDRA-7653 user permission tables, until they will be dropped by the
> operator. Converting permissions happens by simply copying all of them from
> {{permissions}} -> {{role_permissions}}, until the {{permissions}} table has
> been dropped.
> Upgrading to 4.0 will only be possible from 3.0 upwards, so I think it's safe
> to assume that the new permissions table has already been populated, whether
> the old table was dropped or not. Therefor I'd suggest to just get rid of the
> legacy support.
--
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-13371) Remove legacy authz tables support
[
https://issues.apache.org/jira/browse/CASSANDRA-13371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-13371:
---
Assignee: Stefan Podkowinski
Fix Version/s: 4.x
Status: Patch Available (was: Open)
* [branch|https://github.com/spodkowinski/cassandra/tree/CASSANDRA-13371]
* [test-all|https://circleci.com/gh/spodkowinski/cassandra/75]
*
[dtest|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/111/]
> Remove legacy authz tables support
> --
>
> Key: CASSANDRA-13371
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13371
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
> Fix For: 4.x
>
>
> Starting with Cassandra 3.0, we include support for converting pre
> CASSANDRA-7653 user permission tables, until they will be dropped by the
> operator. Converting permissions happens by simply copying all of them from
> {{permissions}} -> {{role_permissions}}, until the {{permissions}} table has
> been dropped.
> Upgrading to 4.0 will only be possible from 3.0 upwards, so I think it's safe
> to assume that the new permissions table has already been populated, whether
> the old table was dropped or not. Therefor I'd suggest to just get rid of the
> legacy support.
--
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-11223) Queries with LIMIT filtering on clustering columns can return less rows than expected
[
https://issues.apache.org/jira/browse/CASSANDRA-11223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16073368#comment-16073368
]
Benjamin Lerer edited comment on CASSANDRA-11223 at 7/4/17 9:19 AM:
I had a discussion with [~slebresne] one year ago about the static row
filtering and we both agreed that we should fix that behavior. Unfortunately, I
did not do it straight away and forgot about it.
Now, my understanding is that those problems should be fixed by CASSANDRA-8272.
[~adelapena] will those problems be solved by your patches for CASSANDRA-8272?
was (Author: blerer):
I had a discussion with [~slebresne] one year ago about the static row
filtering and we both agreed that we should fix that behavior. Unfortunately, I
did not do it straight away and forgot about it.
Now, my understanding is that those problems should be fixed by CASSANDRA-8272.
[~adelapena] will those problems be solved by your patches for CASSANDRA-8272?
> Queries with LIMIT filtering on clustering columns can return less rows than
> expected
> -
>
> Key: CASSANDRA-11223
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11223
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>
> A query like {{SELECT * FROM %s WHERE b = 1 LIMIT 2 ALLOW FILTERING}} can
> return less row than expected if the table has some static columns and some
> of the partition have no rows matching b = 1.
> The problem can be reproduced with the following unit test:
> {code}
> public void testFilteringOnClusteringColumnsWithLimitAndStaticColumns()
> throws Throwable
> {
> createTable("CREATE TABLE %s (a int, b int, s int static, c int,
> primary key (a, b))");
> for (int i = 0; i < 3; i++)
> {
> execute("INSERT INTO %s (a, s) VALUES (?, ?)", i, i);
> for (int j = 0; j < 3; j++)
> if (!(i == 0 && j == 1))
> execute("INSERT INTO %s (a, b, c) VALUES (?, ?, ?)",
> i, j, i + j);
> }
> assertRows(execute("SELECT * FROM %s"),
> row(1, 0, 1, 1),
> row(1, 1, 1, 2),
> row(1, 2, 1, 3),
> row(0, 0, 0, 0),
> row(0, 2, 0, 2),
> row(2, 0, 2, 2),
> row(2, 1, 2, 3),
> row(2, 2, 2, 4));
> assertRows(execute("SELECT * FROM %s WHERE b = 1 ALLOW FILTERING"),
> row(1, 1, 1, 2),
> row(2, 1, 2, 3));
> assertRows(execute("SELECT * FROM %s WHERE b = 1 LIMIT 2 ALLOW
> FILTERING"),
> row(1, 1, 1, 2),
> row(2, 1, 2, 3)); // < FAIL It returns only one
> row because the static row of partition 0 is counted and filtered out in
> SELECT statement
> }
> {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-11223) Queries with LIMIT filtering on clustering columns can return less rows than expected
[
https://issues.apache.org/jira/browse/CASSANDRA-11223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16073374#comment-16073374
]
Benjamin Lerer commented on CASSANDRA-11223:
{quote}partitions with only static data are never returned for index
queries{quote}
It is due to following bug: CASSANDRA-13423.
> Queries with LIMIT filtering on clustering columns can return less rows than
> expected
> -
>
> Key: CASSANDRA-11223
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11223
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>
> A query like {{SELECT * FROM %s WHERE b = 1 LIMIT 2 ALLOW FILTERING}} can
> return less row than expected if the table has some static columns and some
> of the partition have no rows matching b = 1.
> The problem can be reproduced with the following unit test:
> {code}
> public void testFilteringOnClusteringColumnsWithLimitAndStaticColumns()
> throws Throwable
> {
> createTable("CREATE TABLE %s (a int, b int, s int static, c int,
> primary key (a, b))");
> for (int i = 0; i < 3; i++)
> {
> execute("INSERT INTO %s (a, s) VALUES (?, ?)", i, i);
> for (int j = 0; j < 3; j++)
> if (!(i == 0 && j == 1))
> execute("INSERT INTO %s (a, b, c) VALUES (?, ?, ?)",
> i, j, i + j);
> }
> assertRows(execute("SELECT * FROM %s"),
> row(1, 0, 1, 1),
> row(1, 1, 1, 2),
> row(1, 2, 1, 3),
> row(0, 0, 0, 0),
> row(0, 2, 0, 2),
> row(2, 0, 2, 2),
> row(2, 1, 2, 3),
> row(2, 2, 2, 4));
> assertRows(execute("SELECT * FROM %s WHERE b = 1 ALLOW FILTERING"),
> row(1, 1, 1, 2),
> row(2, 1, 2, 3));
> assertRows(execute("SELECT * FROM %s WHERE b = 1 LIMIT 2 ALLOW
> FILTERING"),
> row(1, 1, 1, 2),
> row(2, 1, 2, 3)); // < FAIL It returns only one
> row because the static row of partition 0 is counted and filtered out in
> SELECT statement
> }
> {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-11223) Queries with LIMIT filtering on clustering columns can return less rows than expected
[
https://issues.apache.org/jira/browse/CASSANDRA-11223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16073368#comment-16073368
]
Benjamin Lerer commented on CASSANDRA-11223:
I had a discussion with [~slebresne] one year ago about the static row
filtering and we both agreed that we should fix that behavior. Unfortunately, I
did not do it straight away and forgot about it.
Now, my understanding is that those problems should be fixed by CASSANDRA-8272.
[~adelapena] will those problems be solved by your patches for CASSANDRA-8272?
> Queries with LIMIT filtering on clustering columns can return less rows than
> expected
> -
>
> Key: CASSANDRA-11223
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11223
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>
> A query like {{SELECT * FROM %s WHERE b = 1 LIMIT 2 ALLOW FILTERING}} can
> return less row than expected if the table has some static columns and some
> of the partition have no rows matching b = 1.
> The problem can be reproduced with the following unit test:
> {code}
> public void testFilteringOnClusteringColumnsWithLimitAndStaticColumns()
> throws Throwable
> {
> createTable("CREATE TABLE %s (a int, b int, s int static, c int,
> primary key (a, b))");
> for (int i = 0; i < 3; i++)
> {
> execute("INSERT INTO %s (a, s) VALUES (?, ?)", i, i);
> for (int j = 0; j < 3; j++)
> if (!(i == 0 && j == 1))
> execute("INSERT INTO %s (a, b, c) VALUES (?, ?, ?)",
> i, j, i + j);
> }
> assertRows(execute("SELECT * FROM %s"),
> row(1, 0, 1, 1),
> row(1, 1, 1, 2),
> row(1, 2, 1, 3),
> row(0, 0, 0, 0),
> row(0, 2, 0, 2),
> row(2, 0, 2, 2),
> row(2, 1, 2, 3),
> row(2, 2, 2, 4));
> assertRows(execute("SELECT * FROM %s WHERE b = 1 ALLOW FILTERING"),
> row(1, 1, 1, 2),
> row(2, 1, 2, 3));
> assertRows(execute("SELECT * FROM %s WHERE b = 1 LIMIT 2 ALLOW
> FILTERING"),
> row(1, 1, 1, 2),
> row(2, 1, 2, 3)); // < FAIL It returns only one
> row because the static row of partition 0 is counted and filtered out in
> SELECT statement
> }
> {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-13329) max_hints_delivery_threads does not work
[ https://issues.apache.org/jira/browse/CASSANDRA-13329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16073367#comment-16073367 ] Aleksandr Ivanov commented on CASSANDRA-13329: -- Hello [~Ge], do you have plans to create pull request for 3.0.x version? > max_hints_delivery_threads does not work > > > Key: CASSANDRA-13329 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13329 > Project: Cassandra > Issue Type: Bug >Reporter: Fuud >Assignee: Aleksandr Sorokoumov > Labels: lhf > > HintsDispatchExecutor creates JMXEnabledThreadPoolExecutor with corePoolSize > == 1 and maxPoolSize==max_hints_delivery_threads and unbounded > LinkedBlockingQueue. > In this configuration additional threads will not be created. > Same problem with PerSSTableIndexWriter. -- 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-13663) Cassandra 3.10 crashes without dump
[ https://issues.apache.org/jira/browse/CASSANDRA-13663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Otto updated CASSANDRA-13663: -- Description: Hello. My company runs a 5 node Cassandra cluster. For the last few weeks, we have had a sporadic issue where one of the servers crashes without creating a dump file and without any error messages in the logs. If one restarts the service (which we have by now scripted to happen automatically), the servers resumes work with no complaint. Log files of the time of the last crash are attached, thou again they do not log any crash happening. Regarding out setup, we are running these servers on AMazon AWS, with 3 volumes per server, one for the system, one for data and one for the commitlog. When a crash happens, we can observe a sudden spike of read activity on the commitlog volume. All of these have ample free space. Aspecially the system volume has more then enough free space so that a dump could be written. The servers are Ubuntu 16.04 servers and Cassandra is installed from the apt-get packet for version 3.10. It is worth noting that these crashes happen more often when nodetool is running either repair job or a backup job, but this is by no means always the case. As for frequency, we have had about 1-2 crashes per week for the last month. was: Hello. My company runs a 5 node Cassandra cluster. For the last few weeks, we have had a sporadic issue where one of the servers crashes without creating a dump file and without any error messages in the logs. If one restarts the service (which we have by now scripted to happen automatically), the servers resumes work with no complaint. Log files of the time of the last crash are attached, thou again they do not log any crash happening. Regarding out setup, we are running these servers on AMazon AWS, with 3 volumes per server, one for the system, one for data and one for the commitlog. When a crash happens, we can observe a sudden spike of read activity on the commitlog volume. All of these have ample free space. The servers are Ubuntu 16.04 servers and Cassandra is installed from the apt-get packet for version 3.10. It is worth noting that these crashes happen more often when nodetool is running either repair job or a backup job, but this is by no means always the case. As for frequency, we have had about 1-2 crashes per week for the last month. > Cassandra 3.10 crashes without dump > --- > > Key: CASSANDRA-13663 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13663 > Project: Cassandra > Issue Type: Bug >Reporter: Matthias Otto >Priority: Minor > Attachments: 2017-07-04 10_48_34-CloudWatch Management Console.png, > cassandra debug.log, cassandra system.log > > > Hello. My company runs a 5 node Cassandra cluster. For the last few weeks, we > have had a sporadic issue where one of the servers crashes without creating a > dump file and without any error messages in the logs. If one restarts the > service (which we have by now scripted to happen automatically), the servers > resumes work with no complaint. > Log files of the time of the last crash are attached, thou again they do not > log any crash happening. > Regarding out setup, we are running these servers on AMazon AWS, with 3 > volumes per server, one for the system, one for data and one for the > commitlog. When a crash happens, we can observe a sudden spike of read > activity on the commitlog volume. All of these have ample free space. > Aspecially the system volume has more then enough free space so that a dump > could be written. > The servers are Ubuntu 16.04 servers and Cassandra is installed from the > apt-get packet for version 3.10. > It is worth noting that these crashes happen more often when nodetool is > running either repair job or a backup job, but this is by no means always the > case. As for frequency, we have had about 1-2 crashes per week for the last > month. -- 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-13663) Cassandra 3.10 crashes without dump
[ https://issues.apache.org/jira/browse/CASSANDRA-13663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Otto updated CASSANDRA-13663: -- Description: Hello. My company runs a 5 node Cassandra cluster. For the last few weeks, we have had a sporadic issue where one of the servers crashes without creating a dump file and without any error messages in the logs. If one restarts the service (which we have by now scripted to happen automatically), the servers resumes work with no complaint. Log files of the time of the last crash are attached, thou again they do not log any crash happening. Regarding out setup, we are running these servers on AMazon AWS, with 3 volumes per server, one for the system, one for data and one for the commitlog. When a crash happens, we can observe a sudden spike of read activity on the commitlog volume. All of these have ample free space. The servers are Ubuntu 16.04 servers and Cassandra is installed from the apt-get packet for version 3.10. It is worth noting that these crashes happen more often when nodetool is running either repair job or a backup job, but this is by no means always the case. As for frequency, we have had about 1-2 crashes per week for the last month. was: Hello. My company runs a 5 node Cassandra cluster. For the last few weeks, we have had a sporadic issue where one of the servers crashes without creating a dump file and without any error messages in the logs. If one restarts the service (which we have by now scripted to happen automatically), the servers resumes work with no complaint. Log files of the time of the last crash are attached, thou again they do not log any crash happening. Regarding out setup, we are running these servers on AMazon AWS, with 3 volumes per server, one for the system, one for data and one for the commitlog. When a crash happens, we can observe a sudden spike of read activity on the commitlog volume. The servers are Ubuntu 16.04 servers and Cassandra is installed from the apt-get packet for version 3.10. It is worth noting that these crashes happen more often when nodetool is running either repair job or a backup job, but this is by no means always the case. As for frequency, we have had about 1-2 crashes per week for the last month. > Cassandra 3.10 crashes without dump > --- > > Key: CASSANDRA-13663 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13663 > Project: Cassandra > Issue Type: Bug >Reporter: Matthias Otto >Priority: Minor > Attachments: 2017-07-04 10_48_34-CloudWatch Management Console.png, > cassandra debug.log, cassandra system.log > > > Hello. My company runs a 5 node Cassandra cluster. For the last few weeks, we > have had a sporadic issue where one of the servers crashes without creating a > dump file and without any error messages in the logs. If one restarts the > service (which we have by now scripted to happen automatically), the servers > resumes work with no complaint. > Log files of the time of the last crash are attached, thou again they do not > log any crash happening. > Regarding out setup, we are running these servers on AMazon AWS, with 3 > volumes per server, one for the system, one for data and one for the > commitlog. When a crash happens, we can observe a sudden spike of read > activity on the commitlog volume. All of these have ample free space. > The servers are Ubuntu 16.04 servers and Cassandra is installed from the > apt-get packet for version 3.10. > It is worth noting that these crashes happen more often when nodetool is > running either repair job or a backup job, but this is by no means always the > case. As for frequency, we have had about 1-2 crashes per week for the last > month. -- 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-13663) Cassandra 3.10 crashes without dump
Matthias Otto created CASSANDRA-13663: - Summary: Cassandra 3.10 crashes without dump Key: CASSANDRA-13663 URL: https://issues.apache.org/jira/browse/CASSANDRA-13663 Project: Cassandra Issue Type: Bug Reporter: Matthias Otto Priority: Minor Attachments: 2017-07-04 10_48_34-CloudWatch Management Console.png, cassandra debug.log, cassandra system.log Hello. My company runs a 5 node Cassandra cluster. For the last few weeks, we have had a sporadic issue where one of the servers crashes without creating a dump file and without any error messages in the logs. If one restarts the service (which we have by now scripted to happen automatically), the servers resumes work with no complaint. Log files of the time of the last crash are attached, thou again they do not log any crash happening. Regarding out setup, we are running these servers on AMazon AWS, with 3 volumes per server, one for the system, one for data and one for the commitlog. When a crash happens, we can observe a sudden spike of read activity on the commitlog volume. The servers are Ubuntu 16.04 servers and Cassandra is installed from the apt-get packet for version 3.10. It is worth noting that these crashes happen more often when nodetool is running either repair job or a backup job, but this is by no means always the case. As for frequency, we have had about 1-2 crashes per week for the last month. -- 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-11223) Queries with LIMIT filtering on clustering columns can return less rows than expected
[
https://issues.apache.org/jira/browse/CASSANDRA-11223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16073309#comment-16073309
]
Branimir Lambov edited comment on CASSANDRA-11223 at 7/4/17 8:54 AM:
-
I do have some worries about the behaviour of {{CQLFilter}}, namely that we
throw away static-row only partitions if they do not have rows that survive the
filter before we have had a chance to merge data from multiple replicas. We are
also somewhat inconsistent in removing deletions, letting them survive only if
they are together with live data.
I am not sure I understand all the implications, but I think we are
over-filtering in {{CQLFilter}}. AFAICS this patch already removes the main
reason for doing so (counting static-only partitions in {{DataLimits}}), thus I
would prefer to change {{CQLFilter}} to only remove data that does not satisfy
the expressions and leave deletions and static rows in. This may impact the
size of the data we have to send to the coordinator, though; I don't know if
that's acceptable.
was (Author: blambov):
I do have some worries about the behaviour of {{CQLFilter}}, which I've
commented on
[here|https://github.com/blambov/riptanodb/blob/tpc-nopp/src/java/org/apache/cassandra/db/filter/RowFilter.java#L298]
and
[here|https://github.com/blambov/riptanodb/blob/tpc-nopp/src/java/org/apache/cassandra/db/filter/RowFilter.java#L279]
in in-progress work on the TPC branch.
I am not sure I understand all the implications, but I think we are
over-filtering in {{CQLFilter}}. AFAICS this patch already removes the main
reason for doing so (counting static-only partitions in {{DataLimits}}), thus I
would prefer to change {{CQLFilter}} to only remove data that does not satisfy
the expressions and leave deletions and static rows in. This may impact the
size of the data we have to send to the coordinator, though; I don't know if
that's acceptable.
> Queries with LIMIT filtering on clustering columns can return less rows than
> expected
> -
>
> Key: CASSANDRA-11223
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11223
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>
> A query like {{SELECT * FROM %s WHERE b = 1 LIMIT 2 ALLOW FILTERING}} can
> return less row than expected if the table has some static columns and some
> of the partition have no rows matching b = 1.
> The problem can be reproduced with the following unit test:
> {code}
> public void testFilteringOnClusteringColumnsWithLimitAndStaticColumns()
> throws Throwable
> {
> createTable("CREATE TABLE %s (a int, b int, s int static, c int,
> primary key (a, b))");
> for (int i = 0; i < 3; i++)
> {
> execute("INSERT INTO %s (a, s) VALUES (?, ?)", i, i);
> for (int j = 0; j < 3; j++)
> if (!(i == 0 && j == 1))
> execute("INSERT INTO %s (a, b, c) VALUES (?, ?, ?)",
> i, j, i + j);
> }
> assertRows(execute("SELECT * FROM %s"),
> row(1, 0, 1, 1),
> row(1, 1, 1, 2),
> row(1, 2, 1, 3),
> row(0, 0, 0, 0),
> row(0, 2, 0, 2),
> row(2, 0, 2, 2),
> row(2, 1, 2, 3),
> row(2, 2, 2, 4));
> assertRows(execute("SELECT * FROM %s WHERE b = 1 ALLOW FILTERING"),
> row(1, 1, 1, 2),
> row(2, 1, 2, 3));
> assertRows(execute("SELECT * FROM %s WHERE b = 1 LIMIT 2 ALLOW
> FILTERING"),
> row(1, 1, 1, 2),
> row(2, 1, 2, 3)); // < FAIL It returns only one
> row because the static row of partition 0 is counted and filtered out in
> SELECT statement
> }
> {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] [Comment Edited] (CASSANDRA-13142) Upgradesstables cancels compactions unnecessarily
[ https://issues.apache.org/jira/browse/CASSANDRA-13142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16064774#comment-16064774 ] Kurt Greaves edited comment on CASSANDRA-13142 at 7/4/17 8:37 AM: -- Well, I've seriously broken SSTableRewriterTest. Haven't found out why yet though. edit: seems it was actually already broken was (Author: kurtg): Well, I've seriously broken SSTableRewriterTest. Haven't found out why yet though. > Upgradesstables cancels compactions unnecessarily > - > > Key: CASSANDRA-13142 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13142 > Project: Cassandra > Issue Type: Bug >Reporter: Kurt Greaves >Assignee: Kurt Greaves > Attachments: 13142-v1.patch > > > Since at least 1.2 upgradesstables will cancel any compactions bar > validations when run. This was originally determined as a non-issue in > CASSANDRA-3430 however can be quite annoying (especially with STCS) as a > compaction will output the new version anyway. Furthermore, as per > CASSANDRA-12243 it also stops things like view builds and I assume secondary > index builds as well which is not ideal. > We should avoid cancelling compactions unnecessarily. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-11223) Queries with LIMIT filtering on clustering columns can return less rows than expected
[
https://issues.apache.org/jira/browse/CASSANDRA-11223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16073309#comment-16073309
]
Branimir Lambov commented on CASSANDRA-11223:
-
I do have some worries about the behaviour of {{CQLFilter}}, which I've
commented on
[here|https://github.com/blambov/riptanodb/blob/tpc-nopp/src/java/org/apache/cassandra/db/filter/RowFilter.java#L298]
and
[here|https://github.com/blambov/riptanodb/blob/tpc-nopp/src/java/org/apache/cassandra/db/filter/RowFilter.java#L279]
in in-progress work on the TPC branch.
I am not sure I understand all the implications, but I think we are
over-filtering in {{CQLFilter}}. AFAICS this patch already removes the main
reason for doing so (counting static-only partitions in {{DataLimits}}), thus I
would prefer to change {{CQLFilter}} to only remove data that does not satisfy
the expressions and leave deletions and static rows in. This may impact the
size of the data we have to send to the coordinator, though; I don't know if
that's acceptable.
> Queries with LIMIT filtering on clustering columns can return less rows than
> expected
> -
>
> Key: CASSANDRA-11223
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11223
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>
> A query like {{SELECT * FROM %s WHERE b = 1 LIMIT 2 ALLOW FILTERING}} can
> return less row than expected if the table has some static columns and some
> of the partition have no rows matching b = 1.
> The problem can be reproduced with the following unit test:
> {code}
> public void testFilteringOnClusteringColumnsWithLimitAndStaticColumns()
> throws Throwable
> {
> createTable("CREATE TABLE %s (a int, b int, s int static, c int,
> primary key (a, b))");
> for (int i = 0; i < 3; i++)
> {
> execute("INSERT INTO %s (a, s) VALUES (?, ?)", i, i);
> for (int j = 0; j < 3; j++)
> if (!(i == 0 && j == 1))
> execute("INSERT INTO %s (a, b, c) VALUES (?, ?, ?)",
> i, j, i + j);
> }
> assertRows(execute("SELECT * FROM %s"),
> row(1, 0, 1, 1),
> row(1, 1, 1, 2),
> row(1, 2, 1, 3),
> row(0, 0, 0, 0),
> row(0, 2, 0, 2),
> row(2, 0, 2, 2),
> row(2, 1, 2, 3),
> row(2, 2, 2, 4));
> assertRows(execute("SELECT * FROM %s WHERE b = 1 ALLOW FILTERING"),
> row(1, 1, 1, 2),
> row(2, 1, 2, 3));
> assertRows(execute("SELECT * FROM %s WHERE b = 1 LIMIT 2 ALLOW
> FILTERING"),
> row(1, 1, 1, 2),
> row(2, 1, 2, 3)); // < FAIL It returns only one
> row because the static row of partition 0 is counted and filtered out in
> SELECT statement
> }
> {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-13662) Remove unsupported CREDENTIALS message
[ https://issues.apache.org/jira/browse/CASSANDRA-13662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Podkowinski updated CASSANDRA-13662: --- Status: Patch Available (was: Open) * [branch|https://github.com/spodkowinski/cassandra/tree/CASSANDRA-13662] * [test-all|https://circleci.com/gh/spodkowinski/cassandra/74] * [dtest|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/110/] > Remove unsupported CREDENTIALS message > -- > > Key: CASSANDRA-13662 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13662 > Project: Cassandra > Issue Type: Improvement > Components: Auth, CQL >Reporter: Stefan Podkowinski >Assignee: Stefan Podkowinski >Priority: Minor > Labels: security > Fix For: 4.x > > > Remove CREDENTIAL message, as protocol v1 isn't supported anyways. Let's try > not to keep unused legacy classes around for any security relevant features. -- 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-13662) Remove unsupported CREDENTIALS message
Stefan Podkowinski created CASSANDRA-13662: -- Summary: Remove unsupported CREDENTIALS message Key: CASSANDRA-13662 URL: https://issues.apache.org/jira/browse/CASSANDRA-13662 Project: Cassandra Issue Type: Improvement Components: Auth, CQL Reporter: Stefan Podkowinski Assignee: Stefan Podkowinski Priority: Minor Fix For: 4.x Remove CREDENTIAL message, as protocol v1 isn't supported anyways. Let's try not to keep unused legacy classes around for any security relevant features. -- 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
