[jira] [Updated] (CASSANDRA-7511) Commit log grows infinitely after truncate
[ https://issues.apache.org/jira/browse/CASSANDRA-7511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict updated CASSANDRA-7511: Labels: commitlog (was: ) Commit log grows infinitely after truncate -- Key: CASSANDRA-7511 URL: https://issues.apache.org/jira/browse/CASSANDRA-7511 Project: Cassandra Issue Type: Bug Environment: CentOS 6.5, Oracle Java 7u60, C* 2.0.6, 2.0.9, including earlier 1.0.* versions. Reporter: Viktor Jevdokimov Assignee: Ryan McGuire Priority: Minor Labels: commitlog Commit log grows infinitely after CF truncate operation via cassandra-cli, regardless CF receives writes or not thereafter. CF's could be non-CQL Standard and Super column type. Creation of snapshots after truncate is turned off. Commit log may start grow promptly, may start grow later, on a few only or on all nodes at once. Nothing special in the system log. No idea how to reproduce. After rolling restart commit logs are cleared and back to normal. Just annoying to do rolling restart after each truncate. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CASSANDRA-7561) On DROP we should invalidate CounterKeyCache as well as Key/Row cache
Benedict created CASSANDRA-7561: --- Summary: On DROP we should invalidate CounterKeyCache as well as Key/Row cache Key: CASSANDRA-7561 URL: https://issues.apache.org/jira/browse/CASSANDRA-7561 Project: Cassandra Issue Type: Bug Reporter: Benedict Priority: Minor We should also probably ensure we don't attempt to auto save _any_ of the caches while they are in an inconsistent state (i.e. there are keys present to be saved that should not be restored, or that would throw exceptions when we save (e.g. CounterCacheKey)) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7507) OOM creates unreliable state - die instantly better
[ https://issues.apache.org/jira/browse/CASSANDRA-7507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14064748#comment-14064748 ] Benedict commented on CASSANDRA-7507: - I think we should extend this to include 'Too many open files' - as this usually indicates serious problems that could have unexpected consequences (classnotfoundexception, etc.) OOM creates unreliable state - die instantly better --- Key: CASSANDRA-7507 URL: https://issues.apache.org/jira/browse/CASSANDRA-7507 Project: Cassandra Issue Type: New Feature Reporter: Karl Mueller Assignee: Joshua McKenzie Priority: Minor Fix For: 2.1.1 Attachments: 7507_v1.txt I had a cassandra node run OOM. My heap had enough headroom, there was just something which either was a bug or some unfortunate amount of short-term memory utilization. This resulted in the following error: WARN [StorageServiceShutdownHook] 2014-06-30 09:38:38,251 StorageProxy.java (line 1713) Some hints were not written before shutdown. This is not supposed to happen. You should (a) run repair, and (b) file a bug report There are no other messages of relevance besides the OOM error about 90 minutes earlier. My (limited) understanding of the JVM and Cassandra says that when it goes OOM, it will attempt to signal cassandra to shut down cleanly. The problem, in my view, is that with an OOM situation, nothing is guaranteed anymore. I believe it's impossible to reliably cleanly shut down at this point, and therefore it's wrong to even try. Yes, ideally things could be written out, flushed to disk, memory messages written, other nodes notified, etc. but why is there any reason to believe any of those steps could happen? Would happen? Couldn't bad data be written at this point to disk rather than good data? Some network messages delivered, but not others? I think Cassandra should have the option to (and possibly default) to kill itself immediately upon the OOM condition happening in a hard way, and not rely on the java-based clean shutdown process. Cassandra already handles recovery from unclean shutdown, and it's not a big deal. My node, for example, kept in a sort-of alive state for 90 minutes where who knows what it was doing or not doing. I don't know enough about the JVM and options for it to know the best exact implementation of die instantly on OOM, but it should be something that's possible either with some flags or a C library (which doesn't rely on java memory to do something which it may not be able to get!) Short version: a kill -9 of all C* processes in that instance without needing more java memory, when OOM is raised -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CASSANDRA-7562) Java source code for UDFs
Robert Stupp created CASSANDRA-7562: --- Summary: Java source code for UDFs Key: CASSANDRA-7562 URL: https://issues.apache.org/jira/browse/CASSANDRA-7562 Project: Cassandra Issue Type: New Feature Reporter: Robert Stupp Purpose of this ticket to add support for Java source code for user defined functions (CASSANDRA-7395) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7395) Support for pure user-defined functions (UDF)
[
https://issues.apache.org/jira/browse/CASSANDRA-7395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14064780#comment-14064780
]
Robert Stupp commented on CASSANDRA-7395:
-
Thanks Tyler for taking the time to review the stuff.
* Created CASSANDRA-7562 to cover UDFs with Java source
* The syntax changes ({{LANGUAGE}}, {{RETURNS}}) are fine to me.
* {{DROP TYPE}}, too
* Remove bundle and use {{CREATE FUNCTION namespace::function...}} instead is
ok - in fact there's nothing left in the code that really requires bundle
functionality (was necessary in the first annotation based approach). So C*
code and CQL are conceptually closer.
* PK change is ok
* I think it's better to use java driver as is as a dependency - but this may
cause dependency problems with the Spark driver
I'll start with that this evening.
Support for pure user-defined functions (UDF)
-
Key: CASSANDRA-7395
URL: https://issues.apache.org/jira/browse/CASSANDRA-7395
Project: Cassandra
Issue Type: New Feature
Components: API, Core
Reporter: Jonathan Ellis
Labels: cql
Fix For: 3.0
Attachments: 7395.txt
We have some tickets for various aspects of UDF (CASSANDRA-4914,
CASSANDRA-5970, CASSANDRA-4998) but they all suffer from various degrees of
ocean-boiling.
Let's start with something simple: allowing pure user-defined functions in
the SELECT clause of a CQL query. That's it.
By pure I mean, must depend only on the input parameters. No side effects.
No exposure to C* internals. Column values in, result out.
http://en.wikipedia.org/wiki/Pure_function
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7554) Make CommitLogSegment sync/close asynchronous wrt each other
[ https://issues.apache.org/jira/browse/CASSANDRA-7554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14064816#comment-14064816 ] Benedict commented on CASSANDRA-7554: - Patch available [here|https://github.com/belliottsmith/cassandra/tree/7554-async-cls] Make CommitLogSegment sync/close asynchronous wrt each other Key: CASSANDRA-7554 URL: https://issues.apache.org/jira/browse/CASSANDRA-7554 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Benedict Assignee: Benedict Fix For: 2.1.1 There are a few minor issues with CLS I wanted to tidy up after working on nearby code a bit recently, namely: 1) We use synchronized() for sync() and for various minor accessors, meaning either can block on the other, which is bad since sync() is lengthy 2) Currently close() (and hence recycle()) must wait for a sync() to complete, which means even if we have room available in segments waiting to be recycled an ongoing sync might prevent us from reclaiming the space, prematurely bottlenecking on the disk here 3) recycle() currently depends on close(), which depends on sync(); if we've decided to recycle/close a file before it is synced, this means we do not care about the contents so can actually _avoid_ syncing to disk (which is great in cases where the flush writers get ahead of the CL sync) To solve these problems I've introduced a new fairly simple concurrency primitive called AsyncLock, which only supports tryLock(), or tryLock(Runnable) - with the latter executing the provided runnable on the thread _currently owning the lock_ after it relinquishes it. I've used this to make close() take a Runnable to be executed _when the segment is actually ready to be disposed of_ - which is either immediately, or once any in progress sync has completed. This means the manager thread never blocks on a sync. There is a knock on effect here, which is that we are even less inclined to obey the CL limit (which has always been a soft limit), so I will file a separate minor ticket to introduce a hard limit for CL size in case users want to control this. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CASSANDRA-7563) UserType, TupleType and collections in UDFs
Robert Stupp created CASSANDRA-7563:
---
Summary: UserType, TupleType and collections in UDFs
Key: CASSANDRA-7563
URL: https://issues.apache.org/jira/browse/CASSANDRA-7563
Project: Cassandra
Issue Type: New Feature
Reporter: Robert Stupp
* is Java Driver as a dependency required ?
* is it possible to extract parts of the Java Driver for UDT/TT/coll support ?
* CQL {{DROP TYPE}} must check UDFs
* must check keyspace access permissions (if those exist)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7395) Support for pure user-defined functions (UDF)
[ https://issues.apache.org/jira/browse/CASSANDRA-7395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14064818#comment-14064818 ] Robert Stupp commented on CASSANDRA-7395: - Just thought a bit of UDTs, TupleType and collections for UDFs. There are too many things to take care of regarding such complex types. So I'm pretty sure that it's better to only allow primitive types in this ticket and use CASSANDRA-7563 to support complex types. Support for pure user-defined functions (UDF) - Key: CASSANDRA-7395 URL: https://issues.apache.org/jira/browse/CASSANDRA-7395 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Jonathan Ellis Labels: cql Fix For: 3.0 Attachments: 7395.txt We have some tickets for various aspects of UDF (CASSANDRA-4914, CASSANDRA-5970, CASSANDRA-4998) but they all suffer from various degrees of ocean-boiling. Let's start with something simple: allowing pure user-defined functions in the SELECT clause of a CQL query. That's it. By pure I mean, must depend only on the input parameters. No side effects. No exposure to C* internals. Column values in, result out. http://en.wikipedia.org/wiki/Pure_function -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CASSANDRA-7564) cqlsh does not connect if PasswordAuthenticator is enabled
Mike Adamson created CASSANDRA-7564:
---
Summary: cqlsh does not connect if PasswordAuthenticator is
enabled
Key: CASSANDRA-7564
URL: https://issues.apache.org/jira/browse/CASSANDRA-7564
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Mike Adamson
Priority: Blocker
Fix For: 2.1.0
The python driver was upgraded to v2.1 as part of CASSANDRA-7509. This has
changed it's auth_provider implementation meaning that cqlsh no longer connects
if PasswordAuthenticator is configured and instead returns:
{noformat}
TypeError: auth_provider must implement the cassandra.auth.AuthProvider
interface when protocol_version = 2
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CASSANDRA-7564) cqlsh does not connect if PasswordAuthenticator is enabled
[
https://issues.apache.org/jira/browse/CASSANDRA-7564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Adamson updated CASSANDRA-7564:
Attachment: 7564.patch
cqlsh does not connect if PasswordAuthenticator is enabled
---
Key: CASSANDRA-7564
URL: https://issues.apache.org/jira/browse/CASSANDRA-7564
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Mike Adamson
Priority: Blocker
Fix For: 2.1.0
Attachments: 7564.patch
The python driver was upgraded to v2.1 as part of CASSANDRA-7509. This has
changed it's auth_provider implementation meaning that cqlsh no longer
connects if PasswordAuthenticator is configured and instead returns:
{noformat}
TypeError: auth_provider must implement the cassandra.auth.AuthProvider
interface when protocol_version = 2
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CASSANDRA-7398) Missing flexibility to have file://server/etc vs. file:/// when loading config file cassandra.yaml
[ https://issues.apache.org/jira/browse/CASSANDRA-7398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joshua McKenzie updated CASSANDRA-7398: --- Reviewer: Joshua McKenzie Missing flexibility to have file://server/etc vs. file:/// when loading config file cassandra.yaml -- Key: CASSANDRA-7398 URL: https://issues.apache.org/jira/browse/CASSANDRA-7398 Project: Cassandra Issue Type: Bug Components: Core Environment: Cassandra 2.1.0-rc1-SNAPSHOT, Win 7 Reporter: Marco Tulio Avila Cerón Assignee: Marco Tulio Avila Cerón Priority: Minor Labels: lhf, patch Fix For: 2.1.1 Attachments: CASSANDRA-7398_prefix_v2.patch, CASSANDRA-7398_prefix_v3.patch, CASSANDRA-7398_prefix_v4.patch, trunk-7398_v5.txt, trunk-7398_v6.txt, trunk-7398_v7.txt, trunk-7398_v8.txt, trunk-7398_v8_impl.txt, trunk-7398_v8_test.txt Original Estimate: 2h Remaining Estimate: 2h The parameter in the VM options -Dcassandra.config= needs file:/// Allow the user to have optional file:/// when loading the config file from the filesystem -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CASSANDRA-7561) On DROP we should invalidate CounterKeyCache as well as Key/Row cache
[ https://issues.apache.org/jira/browse/CASSANDRA-7561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-7561: - Assignee: Aleksey Yeschenko On DROP we should invalidate CounterKeyCache as well as Key/Row cache - Key: CASSANDRA-7561 URL: https://issues.apache.org/jira/browse/CASSANDRA-7561 Project: Cassandra Issue Type: Bug Reporter: Benedict Assignee: Aleksey Yeschenko Priority: Minor We should also probably ensure we don't attempt to auto save _any_ of the caches while they are in an inconsistent state (i.e. there are keys present to be saved that should not be restored, or that would throw exceptions when we save (e.g. CounterCacheKey)) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7564) cqlsh does not connect if PasswordAuthenticator is enabled
[
https://issues.apache.org/jira/browse/CASSANDRA-7564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-7564:
--
Reviewer: Tyler Hobbs
Component/s: (was: Core)
Tools
Priority: Major (was: Blocker)
Assignee: Mike Adamson
cqlsh does not connect if PasswordAuthenticator is enabled
---
Key: CASSANDRA-7564
URL: https://issues.apache.org/jira/browse/CASSANDRA-7564
Project: Cassandra
Issue Type: Bug
Components: Tools
Reporter: Mike Adamson
Assignee: Mike Adamson
Fix For: 2.1.0
Attachments: 7564.patch
The python driver was upgraded to v2.1 as part of CASSANDRA-7509. This has
changed it's auth_provider implementation meaning that cqlsh no longer
connects if PasswordAuthenticator is configured and instead returns:
{noformat}
TypeError: auth_provider must implement the cassandra.auth.AuthProvider
interface when protocol_version = 2
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CASSANDRA-7075) Add the ability to automatically distribute your commitlogs across all data volumes
[ https://issues.apache.org/jira/browse/CASSANDRA-7075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tupshin Harper updated CASSANDRA-7075: -- Fix Version/s: 3.0 Add the ability to automatically distribute your commitlogs across all data volumes --- Key: CASSANDRA-7075 URL: https://issues.apache.org/jira/browse/CASSANDRA-7075 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Tupshin Harper Priority: Minor Labels: performance Fix For: 3.0 given the prevalance of ssds (no need to separate commitlog and data), and improved jbod support, along with CASSANDRA-3578, it seems like we should have an option to have one commitlog per data volume, to even the load. i've been seeing more and more cases where there isn't an obvious extra volume to put the commitlog on, and sticking it on only one of the jbodded ssd volumes leads to IO imbalance. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CASSANDRA-7565) Extend diskFailurePolicy to die instantly on failure
T Jake Luciani created CASSANDRA-7565: - Summary: Extend diskFailurePolicy to die instantly on failure Key: CASSANDRA-7565 URL: https://issues.apache.org/jira/browse/CASSANDRA-7565 Project: Cassandra Issue Type: Improvement Reporter: T Jake Luciani Priority: Minor Fix For: 2.1.1 Somewhat related to CASSANDRA-7507 we should extend the diskFailurePolicy to be set to kill. Currently stop only shuts down the transports. This isn't enough since compaction keeps running. In a JBOD setup the dead disk may contain important data like the system tables. In the case that leveled compaction keeps running it will mess up the levels so suddenly the data becomes overlapped if the disk is only temporarily broken (bad firmware). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7239) Nodetool Status Reports Negative Load With VNodes Disabled
[
https://issues.apache.org/jira/browse/CASSANDRA-7239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14064954#comment-14064954
]
Andrew Montalenti commented on CASSANDRA-7239:
--
I can confirm this: https://gist.github.com/amontalenti/71abf24d92e7a3e98f0e --
hit the same thing with 2.1.0-rc3 on my cluster w/ a fresh set of keyspaces.
Nodetool Status Reports Negative Load With VNodes Disabled
--
Key: CASSANDRA-7239
URL: https://issues.apache.org/jira/browse/CASSANDRA-7239
Project: Cassandra
Issue Type: Bug
Components: Tools
Environment: 1000 Nodes EC2 m1.large ubuntu 12.04
Reporter: Russell Alexander Spitzer
Priority: Minor
When I run stress on a large cluster without vnodes (num_token =1 initial
token set) The loads reported by nodetool status are negative, or become
negative after stress is run.
{code}
UN 10.97.155.31-447426217 bytes 1 0.2%
8d40568c-044c-4753-be26-4ab62710beba rack1
UN 10.9.132.53 -447342449 bytes 1 0.2%
58e7f255-803d-493b-a19e-58137466fb78 rack1
UN 10.37.151.202 -447298672 bytes 1 0.2%
ba29b1f1-186f-45d0-9e59-6a528db8df5d rack1
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CASSANDRA-7566) DROP/CREATE TABLE cycle causes unrecognized column family
Ben Hood created CASSANDRA-7566: --- Summary: DROP/CREATE TABLE cycle causes unrecognized column family Key: CASSANDRA-7566 URL: https://issues.apache.org/jira/browse/CASSANDRA-7566 Project: Cassandra Issue Type: Bug Components: Core Environment: OSX 10.9.4 / JDK 1.8.0_05 Reporter: Ben Hood An integration test suite that drops and creates the same column family 3 times causes the following error in the server log: INFO 15:40:34 Initializing gocql_test.wiki_page ERROR 15:40:34 Attempted to write commit log entry for unrecognized column family: b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempting to mutate non-existant column family b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempted to write commit log entry for unrecognized column family: b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempting to mutate non-existant column family b0e167e0-0dc8-11e4-9cbb-29a4872887f2 The test that reproduces this issue is here: https://github.com/gocql/gocql/blob/master/wiki_test.go Interestingly this issue only occurs after the common table is dropped/created for the 3rd time. If only one of the tests is run on its own, this issue does not arise. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (CASSANDRA-7566) DROP/CREATE TABLE cycle causes unrecognized column family
[ https://issues.apache.org/jira/browse/CASSANDRA-7566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams reopened CASSANDRA-7566: - Oops, missed the repro version. DROP/CREATE TABLE cycle causes unrecognized column family - Key: CASSANDRA-7566 URL: https://issues.apache.org/jira/browse/CASSANDRA-7566 Project: Cassandra Issue Type: Bug Components: Core Environment: OSX 10.9.4 / JDK 1.8.0_05 Reporter: Ben Hood Assignee: Yuki Morishita An integration test suite that drops and creates the same column family 3 times causes the following error in the server log: INFO 15:40:34 Initializing gocql_test.wiki_page ERROR 15:40:34 Attempted to write commit log entry for unrecognized column family: b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempting to mutate non-existant column family b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempted to write commit log entry for unrecognized column family: b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempting to mutate non-existant column family b0e167e0-0dc8-11e4-9cbb-29a4872887f2 The test that reproduces this issue is here: https://github.com/gocql/gocql/blob/master/wiki_test.go Interestingly this issue only occurs after the common table is dropped/created for the 3rd time. If only one of the tests is run on its own, this issue does not arise. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CASSANDRA-7566) DROP/CREATE TABLE cycle causes unrecognized column family
[ https://issues.apache.org/jira/browse/CASSANDRA-7566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-7566. - Resolution: Duplicate The short answer is don't do this before 2.1. DROP/CREATE TABLE cycle causes unrecognized column family - Key: CASSANDRA-7566 URL: https://issues.apache.org/jira/browse/CASSANDRA-7566 Project: Cassandra Issue Type: Bug Components: Core Environment: OSX 10.9.4 / JDK 1.8.0_05 Reporter: Ben Hood An integration test suite that drops and creates the same column family 3 times causes the following error in the server log: INFO 15:40:34 Initializing gocql_test.wiki_page ERROR 15:40:34 Attempted to write commit log entry for unrecognized column family: b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempting to mutate non-existant column family b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempted to write commit log entry for unrecognized column family: b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempting to mutate non-existant column family b0e167e0-0dc8-11e4-9cbb-29a4872887f2 The test that reproduces this issue is here: https://github.com/gocql/gocql/blob/master/wiki_test.go Interestingly this issue only occurs after the common table is dropped/created for the 3rd time. If only one of the tests is run on its own, this issue does not arise. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CASSANDRA-7566) DROP/CREATE TABLE cycle causes unrecognized column family
[ https://issues.apache.org/jira/browse/CASSANDRA-7566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-7566: - Assignee: Yuki Morishita DROP/CREATE TABLE cycle causes unrecognized column family - Key: CASSANDRA-7566 URL: https://issues.apache.org/jira/browse/CASSANDRA-7566 Project: Cassandra Issue Type: Bug Components: Core Environment: OSX 10.9.4 / JDK 1.8.0_05 Reporter: Ben Hood Assignee: Yuki Morishita An integration test suite that drops and creates the same column family 3 times causes the following error in the server log: INFO 15:40:34 Initializing gocql_test.wiki_page ERROR 15:40:34 Attempted to write commit log entry for unrecognized column family: b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempting to mutate non-existant column family b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempted to write commit log entry for unrecognized column family: b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempting to mutate non-existant column family b0e167e0-0dc8-11e4-9cbb-29a4872887f2 The test that reproduces this issue is here: https://github.com/gocql/gocql/blob/master/wiki_test.go Interestingly this issue only occurs after the common table is dropped/created for the 3rd time. If only one of the tests is run on its own, this issue does not arise. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7566) DROP/CREATE TABLE cycle causes unrecognized column family
[ https://issues.apache.org/jira/browse/CASSANDRA-7566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14065075#comment-14065075 ] Ben Hood commented on CASSANDRA-7566: - CASSANDRA-5202 appears to have been fixed in 2.1 beta1, but the version I'm using is 2.1-rc3. Is 2.1 beta 1 a newer release than 2.1-rc3? DROP/CREATE TABLE cycle causes unrecognized column family - Key: CASSANDRA-7566 URL: https://issues.apache.org/jira/browse/CASSANDRA-7566 Project: Cassandra Issue Type: Bug Components: Core Environment: OSX 10.9.4 / JDK 1.8.0_05 Reporter: Ben Hood Assignee: Yuki Morishita An integration test suite that drops and creates the same column family 3 times causes the following error in the server log: INFO 15:40:34 Initializing gocql_test.wiki_page ERROR 15:40:34 Attempted to write commit log entry for unrecognized column family: b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempting to mutate non-existant column family b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempted to write commit log entry for unrecognized column family: b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempting to mutate non-existant column family b0e167e0-0dc8-11e4-9cbb-29a4872887f2 The test that reproduces this issue is here: https://github.com/gocql/gocql/blob/master/wiki_test.go Interestingly this issue only occurs after the common table is dropped/created for the 3rd time. If only one of the tests is run on its own, this issue does not arise. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7566) DROP/CREATE TABLE cycle causes unrecognized column family
[ https://issues.apache.org/jira/browse/CASSANDRA-7566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14065081#comment-14065081 ] Yuki Morishita commented on CASSANDRA-7566: --- CommitLog just writes log in ERROR when it detects dropped CF(https://github.com/apache/cassandra/blob/cassandra-2.1.0-rc3/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java#L439). Should it be changed to WARN or INFO? DROP/CREATE TABLE cycle causes unrecognized column family - Key: CASSANDRA-7566 URL: https://issues.apache.org/jira/browse/CASSANDRA-7566 Project: Cassandra Issue Type: Bug Components: Core Environment: OSX 10.9.4 / JDK 1.8.0_05 Reporter: Ben Hood Assignee: Yuki Morishita An integration test suite that drops and creates the same column family 3 times causes the following error in the server log: INFO 15:40:34 Initializing gocql_test.wiki_page ERROR 15:40:34 Attempted to write commit log entry for unrecognized column family: b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempting to mutate non-existant column family b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempted to write commit log entry for unrecognized column family: b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempting to mutate non-existant column family b0e167e0-0dc8-11e4-9cbb-29a4872887f2 The test that reproduces this issue is here: https://github.com/gocql/gocql/blob/master/wiki_test.go Interestingly this issue only occurs after the common table is dropped/created for the 3rd time. If only one of the tests is run on its own, this issue does not arise. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7566) DROP/CREATE TABLE cycle causes unrecognized column family
[ https://issues.apache.org/jira/browse/CASSANDRA-7566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14065089#comment-14065089 ] Brandon Williams commented on CASSANDRA-7566: - bq. CASSANDRA-5202 appears to have been fixed in 2.1 beta1, but the version I'm using is 2.1-rc3. Is 2.1 beta 1 a newer release than 2.1-rc3? No; my mistake. Sorry. DROP/CREATE TABLE cycle causes unrecognized column family - Key: CASSANDRA-7566 URL: https://issues.apache.org/jira/browse/CASSANDRA-7566 Project: Cassandra Issue Type: Bug Components: Core Environment: OSX 10.9.4 / JDK 1.8.0_05 Reporter: Ben Hood Assignee: Yuki Morishita An integration test suite that drops and creates the same column family 3 times causes the following error in the server log: INFO 15:40:34 Initializing gocql_test.wiki_page ERROR 15:40:34 Attempted to write commit log entry for unrecognized column family: b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempting to mutate non-existant column family b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempted to write commit log entry for unrecognized column family: b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempting to mutate non-existant column family b0e167e0-0dc8-11e4-9cbb-29a4872887f2 The test that reproduces this issue is here: https://github.com/gocql/gocql/blob/master/wiki_test.go Interestingly this issue only occurs after the common table is dropped/created for the 3rd time. If only one of the tests is run on its own, this issue does not arise. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7566) DROP/CREATE TABLE cycle causes unrecognized column family
[ https://issues.apache.org/jira/browse/CASSANDRA-7566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14065090#comment-14065090 ] Ben Hood commented on CASSANDRA-7566: - The CQL that is submitted in this test is: DROP TABLE IF EXISTS wiki_page; followed by CREATE TABLE wiki_page (...); So I'm not seeing why this should result in a server error. Also, this is not just an entry in the server log file, it causes a test to fail that passes on our Travis run for the 2.0.6 and 2.0.7 releases. DROP/CREATE TABLE cycle causes unrecognized column family - Key: CASSANDRA-7566 URL: https://issues.apache.org/jira/browse/CASSANDRA-7566 Project: Cassandra Issue Type: Bug Components: Core Environment: OSX 10.9.4 / JDK 1.8.0_05 Reporter: Ben Hood Assignee: Yuki Morishita An integration test suite that drops and creates the same column family 3 times causes the following error in the server log: INFO 15:40:34 Initializing gocql_test.wiki_page ERROR 15:40:34 Attempted to write commit log entry for unrecognized column family: b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempting to mutate non-existant column family b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempted to write commit log entry for unrecognized column family: b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempting to mutate non-existant column family b0e167e0-0dc8-11e4-9cbb-29a4872887f2 The test that reproduces this issue is here: https://github.com/gocql/gocql/blob/master/wiki_test.go Interestingly this issue only occurs after the common table is dropped/created for the 3rd time. If only one of the tests is run on its own, this issue does not arise. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7565) Extend diskFailurePolicy to die instantly on failure
[ https://issues.apache.org/jira/browse/CASSANDRA-7565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14065113#comment-14065113 ] Jonathan Ellis commented on CASSANDRA-7565: --- Are you proposing a new policy, or changing the behavior of the stop policy? Extend diskFailurePolicy to die instantly on failure Key: CASSANDRA-7565 URL: https://issues.apache.org/jira/browse/CASSANDRA-7565 Project: Cassandra Issue Type: Improvement Reporter: T Jake Luciani Priority: Minor Fix For: 2.1.1 Somewhat related to CASSANDRA-7507 we should extend the diskFailurePolicy to be set to kill. Currently stop only shuts down the transports. This isn't enough since compaction keeps running. In a JBOD setup the dead disk may contain important data like the system tables. In the case that leveled compaction keeps running it will mess up the levels so suddenly the data becomes overlapped if the disk is only temporarily broken (bad firmware). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7565) Extend diskFailurePolicy to die instantly on failure
[ https://issues.apache.org/jira/browse/CASSANDRA-7565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14065131#comment-14065131 ] T Jake Luciani commented on CASSANDRA-7565: --- I think new would be best to avoid any confusion. Extend diskFailurePolicy to die instantly on failure Key: CASSANDRA-7565 URL: https://issues.apache.org/jira/browse/CASSANDRA-7565 Project: Cassandra Issue Type: Improvement Reporter: T Jake Luciani Priority: Minor Fix For: 2.1.1 Somewhat related to CASSANDRA-7507 we should extend the diskFailurePolicy to be set to kill. Currently stop only shuts down the transports. This isn't enough since compaction keeps running. In a JBOD setup the dead disk may contain important data like the system tables. In the case that leveled compaction keeps running it will mess up the levels so suddenly the data becomes overlapped if the disk is only temporarily broken (bad firmware). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7566) DROP/CREATE TABLE cycle causes unrecognized column family
[ https://issues.apache.org/jira/browse/CASSANDRA-7566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14065136#comment-14065136 ] Yuki Morishita commented on CASSANDRA-7566: --- [~0x6e6562], does gocql use prepared statement? I'm guessing we need to drop prepared statement too when dropping columnfamily. DROP/CREATE TABLE cycle causes unrecognized column family - Key: CASSANDRA-7566 URL: https://issues.apache.org/jira/browse/CASSANDRA-7566 Project: Cassandra Issue Type: Bug Components: Core Environment: OSX 10.9.4 / JDK 1.8.0_05 Reporter: Ben Hood Assignee: Yuki Morishita An integration test suite that drops and creates the same column family 3 times causes the following error in the server log: INFO 15:40:34 Initializing gocql_test.wiki_page ERROR 15:40:34 Attempted to write commit log entry for unrecognized column family: b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempting to mutate non-existant column family b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempted to write commit log entry for unrecognized column family: b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempting to mutate non-existant column family b0e167e0-0dc8-11e4-9cbb-29a4872887f2 The test that reproduces this issue is here: https://github.com/gocql/gocql/blob/master/wiki_test.go Interestingly this issue only occurs after the common table is dropped/created for the 3rd time. If only one of the tests is run on its own, this issue does not arise. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-2356) make the debian package never start by default
[ https://issues.apache.org/jira/browse/CASSANDRA-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2356: -- Fix Version/s: 3.0 I'm fine with just documenting the new behavior for 3.0 and not trying to preserve old behavior when upgrading. make the debian package never start by default -- Key: CASSANDRA-2356 URL: https://issues.apache.org/jira/browse/CASSANDRA-2356 Project: Cassandra Issue Type: Improvement Components: Packaging Reporter: Jeremy Hanna Assignee: Michael Shuler Priority: Minor Labels: debian, packaging Fix For: 3.0 Attachments: 2356.txt Currently the debian package that installs cassandra starts cassandra by default. It sounds like that is a standard debian packaging convention. However, if you want to bootstrap a new node and want to configure it before it creates any sort of state information, it's a pain. I would think that the common use case would be to have it install all of the init scripts and such but *not* have it start up by default. That way an admin can configure cassandra with seed, token, host, etc. information and then start it. That makes it easier to programmatically do this as well - have chef/puppet install cassandra, do some configuration, then do the service start. With the current setup, it sounds like cassandra creates state on startup that has to be cleaned before a new configuration can take effect. So the process of installing turns into: * install debian package * shutdown cassandra * clean out state (data/log dirs) * configure cassandra * start cassandra That seems suboptimal for the default case, especially when trying to automate new nodes being bootstrapped. Another case might be when a downed node comes back up and starts by default and tries to claim a token that has already been claimed by another newly bootstrapped node. Rob is more familiar with that case so I'll let him explain it in the comments. -- This message was sent by Atlassian JIRA (v6.2#6252)
[1/3] git commit: add support for arbitrary -D options to .ps1 script patch by Joshua McKenzie; reviewed by Philip Thompson for CASSANDRA-7435
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.1 57ec7b735 - 22f811e3b
refs/heads/trunk ca60eacad - 41a91e9a1
add support for arbitrary -D options to .ps1 script
patch by Joshua McKenzie; reviewed by Philip Thompson for CASSANDRA-7435
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/22f811e3
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/22f811e3
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/22f811e3
Branch: refs/heads/cassandra-2.1
Commit: 22f811e3b56e2d968d4724fcf99d11b4e0a7d037
Parents: 57ec7b7
Author: Jonathan Ellis jbel...@apache.org
Authored: Thu Jul 17 12:04:53 2014 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Thu Jul 17 12:05:00 2014 -0500
--
bin/cassandra.ps1 | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/22f811e3/bin/cassandra.ps1
--
diff --git a/bin/cassandra.ps1 b/bin/cassandra.ps1
index 53b0032..4417c0c 100644
--- a/bin/cassandra.ps1
+++ b/bin/cassandra.ps1
@@ -43,12 +43,13 @@ Function ValidateArguments
Function PrintUsage
{
echo @
-usage: cassandra.ps1 [-f] [-h] [-p pidfile] [-H dumpfile] [-E errorfile]
[-install | -uninstall] [-help]
+usage: cassandra.ps1 [-f] [-h] [-p pidfile] [-H dumpfile] [-D arg] [-E
errorfile] [-install | -uninstall] [-help]
-f Run cassandra in foreground
-installinstall cassandra as a service
-uninstall remove cassandra service
-p pidfile tracked by server and removed on close (defaults
to pid.txt)
-H change JVM HeapDumpPath
+-D items to append to JVM_OPTS
-E change JVM ErrorFile
-help print this message
-verboseShow detailed command-line parameters for cassandra run
@@ -103,6 +104,16 @@ Function Main
$env:CASSANDRA_PARAMS = $env:CASSANDRA_PARAMS + '
-Dcassandra-pidfile=' + $pidfile + ''
}
+# Parse -D JVM_OPTS
+for ($i = 0; $i -lt $script:args.Length; ++$i)
+{
+if ($script:args[$i].Substring(0,2) -eq -D)
+{
+$param = $script:args[$i].Substring(2)
+$env:JVM_OPTS = $env:JVM_OPTS -D$param
+}
+}
+
if ($install -or $uninstall)
{
HandleInstallation
@@ -191,8 +202,8 @@ Function RunCassandra([string]$foreground)
$cmd = @
$env:JAVA_BIN
@
-$arg1 = $env:JVM_OPTS
-$arg2 = $env:CASSANDRA_PARAMS
+$arg1 = $env:CASSANDRA_PARAMS
+$arg2 = $env:JVM_OPTS
$arg3 = -cp $env:CLASSPATH
$arg4 = @
$env:CASSANDRA_MAIN
[3/3] git commit: Merge branch 'cassandra-2.1' into trunk
Merge branch 'cassandra-2.1' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/41a91e9a Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/41a91e9a Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/41a91e9a Branch: refs/heads/trunk Commit: 41a91e9a10b474392fcdb1f870d1509afde2b903 Parents: ca60eac 22f811e Author: Jonathan Ellis jbel...@apache.org Authored: Thu Jul 17 12:05:05 2014 -0500 Committer: Jonathan Ellis jbel...@apache.org Committed: Thu Jul 17 12:05:05 2014 -0500 -- bin/cassandra.ps1 | 17 ++--- 1 file changed, 14 insertions(+), 3 deletions(-) --
[2/3] git commit: add support for arbitrary -D options to .ps1 script patch by Joshua McKenzie; reviewed by Philip Thompson for CASSANDRA-7435
add support for arbitrary -D options to .ps1 script
patch by Joshua McKenzie; reviewed by Philip Thompson for CASSANDRA-7435
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/22f811e3
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/22f811e3
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/22f811e3
Branch: refs/heads/trunk
Commit: 22f811e3b56e2d968d4724fcf99d11b4e0a7d037
Parents: 57ec7b7
Author: Jonathan Ellis jbel...@apache.org
Authored: Thu Jul 17 12:04:53 2014 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Thu Jul 17 12:05:00 2014 -0500
--
bin/cassandra.ps1 | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/22f811e3/bin/cassandra.ps1
--
diff --git a/bin/cassandra.ps1 b/bin/cassandra.ps1
index 53b0032..4417c0c 100644
--- a/bin/cassandra.ps1
+++ b/bin/cassandra.ps1
@@ -43,12 +43,13 @@ Function ValidateArguments
Function PrintUsage
{
echo @
-usage: cassandra.ps1 [-f] [-h] [-p pidfile] [-H dumpfile] [-E errorfile]
[-install | -uninstall] [-help]
+usage: cassandra.ps1 [-f] [-h] [-p pidfile] [-H dumpfile] [-D arg] [-E
errorfile] [-install | -uninstall] [-help]
-f Run cassandra in foreground
-installinstall cassandra as a service
-uninstall remove cassandra service
-p pidfile tracked by server and removed on close (defaults
to pid.txt)
-H change JVM HeapDumpPath
+-D items to append to JVM_OPTS
-E change JVM ErrorFile
-help print this message
-verboseShow detailed command-line parameters for cassandra run
@@ -103,6 +104,16 @@ Function Main
$env:CASSANDRA_PARAMS = $env:CASSANDRA_PARAMS + '
-Dcassandra-pidfile=' + $pidfile + ''
}
+# Parse -D JVM_OPTS
+for ($i = 0; $i -lt $script:args.Length; ++$i)
+{
+if ($script:args[$i].Substring(0,2) -eq -D)
+{
+$param = $script:args[$i].Substring(2)
+$env:JVM_OPTS = $env:JVM_OPTS -D$param
+}
+}
+
if ($install -or $uninstall)
{
HandleInstallation
@@ -191,8 +202,8 @@ Function RunCassandra([string]$foreground)
$cmd = @
$env:JAVA_BIN
@
-$arg1 = $env:JVM_OPTS
-$arg2 = $env:CASSANDRA_PARAMS
+$arg1 = $env:CASSANDRA_PARAMS
+$arg2 = $env:JVM_OPTS
$arg3 = -cp $env:CLASSPATH
$arg4 = @
$env:CASSANDRA_MAIN
[jira] [Updated] (CASSANDRA-6910) Better table structure display in cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-6910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Stupp updated CASSANDRA-6910: Attachment: 6910.txt LGTM - although the patch could not apply the 1st hunk - corrected patch added as 6910.txt Better table structure display in cqlsh --- Key: CASSANDRA-6910 URL: https://issues.apache.org/jira/browse/CASSANDRA-6910 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Tupshin Harper Assignee: Mihai Suteu Priority: Minor Labels: lhf Attachments: 6910.txt, cassandra6910.patch, screenshot-mihai.jpg It should be possible to make it more immediately obvious what the structure of your CQL table is from cqlsh. Two minor enhancements could go a long way: 1) If there are no results display the column headers anyway. Right now, if you are trying to do a query and get no results, it's common to need to display the table schema to figure out what you did wrong. Having the columns displayed whenever you do a query wouldn't get in the way, and would provide a more visual way than by describing the table. 2) Along with the first one, if we could highlight the partition/clustering columns in different colors, it would be much more intuitively understandable what the underlying partition structure is. tl;dr: the forms below should each have distinct visual representation when displaying the column headers, and the column headers should always be shown. CREATE TABLE usertest ( userid text, email text, name text, PRIMARY KEY (userid) ) CREATE TABLE usertest2 ( userid text, email text, name text, PRIMARY KEY (userid, email) ) CREATE TABLE usertest3 ( userid text, email text, name text, PRIMARY KEY ((userid, email)) ) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-6910) Better table structure display in cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-6910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14065162#comment-14065162 ] Robert Stupp commented on CASSANDRA-6910: - note: the colors are ok - they work on dark and bright terminal background colors Better table structure display in cqlsh --- Key: CASSANDRA-6910 URL: https://issues.apache.org/jira/browse/CASSANDRA-6910 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Tupshin Harper Assignee: Mihai Suteu Priority: Minor Labels: lhf Attachments: 6910.txt, cassandra6910.patch, screenshot-mihai.jpg It should be possible to make it more immediately obvious what the structure of your CQL table is from cqlsh. Two minor enhancements could go a long way: 1) If there are no results display the column headers anyway. Right now, if you are trying to do a query and get no results, it's common to need to display the table schema to figure out what you did wrong. Having the columns displayed whenever you do a query wouldn't get in the way, and would provide a more visual way than by describing the table. 2) Along with the first one, if we could highlight the partition/clustering columns in different colors, it would be much more intuitively understandable what the underlying partition structure is. tl;dr: the forms below should each have distinct visual representation when displaying the column headers, and the column headers should always be shown. CREATE TABLE usertest ( userid text, email text, name text, PRIMARY KEY (userid) ) CREATE TABLE usertest2 ( userid text, email text, name text, PRIMARY KEY (userid, email) ) CREATE TABLE usertest3 ( userid text, email text, name text, PRIMARY KEY ((userid, email)) ) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CASSANDRA-7395) Support for pure user-defined functions (UDF)
[ https://issues.apache.org/jira/browse/CASSANDRA-7395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Stupp reassigned CASSANDRA-7395: --- Assignee: Robert Stupp Support for pure user-defined functions (UDF) - Key: CASSANDRA-7395 URL: https://issues.apache.org/jira/browse/CASSANDRA-7395 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Jonathan Ellis Assignee: Robert Stupp Labels: cql Fix For: 3.0 Attachments: 7395.txt We have some tickets for various aspects of UDF (CASSANDRA-4914, CASSANDRA-5970, CASSANDRA-4998) but they all suffer from various degrees of ocean-boiling. Let's start with something simple: allowing pure user-defined functions in the SELECT clause of a CQL query. That's it. By pure I mean, must depend only on the input parameters. No side effects. No exposure to C* internals. Column values in, result out. http://en.wikipedia.org/wiki/Pure_function -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CASSANDRA-7567) when the commit_log disk for a single node is overwhelmed the entire cluster slows down
David O'Dell created CASSANDRA-7567: --- Summary: when the commit_log disk for a single node is overwhelmed the entire cluster slows down Key: CASSANDRA-7567 URL: https://issues.apache.org/jira/browse/CASSANDRA-7567 Project: Cassandra Issue Type: Bug Components: Core Environment: debian 7.5, bare metal, 14 nodes, 64CPUs, 64GB RAM, commit_log disk sata, data disk SSD, vnodes, leveled compaction strategy Reporter: David O'Dell Attachments: write_request_latency.png We've run into a situation where a single node out of 14 is experiencing high disk io. This can happen when a node is being decommissioned or after it joins the ring and runs into the bug cassandra-6621. When this occurs the write latency for the entire cluster spikes. From 0.3ms to 170ms. To simulate this simply run dd on the commit_log disk (dd if=/dev/zero of=/tmp/foo bs=1024) and you will see that instantly all nodes in the cluster have slowed down. BTW overwhelming the data disk does not have this same effect. Also I've tried this where the overwhelmed node isn't being connected directly from the client and it still has the same effect. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CASSANDRA-7568) Replacing a dead node using replace_address fails
Ala' Alkhaldi created CASSANDRA-7568:
Summary: Replacing a dead node using replace_address fails
Key: CASSANDRA-7568
URL: https://issues.apache.org/jira/browse/CASSANDRA-7568
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Ala' Alkhaldi
Priority: Minor
Failed assertion
{code}
ERROR [main] 2014-07-15 14:21:32,083 CassandraDaemon.java:474 - Exception
encountered during startup
java.lang.AssertionError: Expected 1 endpoint but found 0
at
org.apache.cassandra.dht.RangeStreamer.getAllRangesWithStrictSourcesFor(RangeStreamer.java:216)
~[main/:na]
at
org.apache.cassandra.dht.RangeStreamer.addRanges(RangeStreamer.java:131)
~[main/:na]
at
org.apache.cassandra.dht.BootStrapper.bootstrap(BootStrapper.java:72)
~[main/:na]
at
org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1049)
~[main/:na]
at
org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:811)
~[main/:na]
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:626)
~[main/:na]
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:511)
~[main/:na]
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:338)
[main/:na]
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:457)
[main/:na]
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:546)
[main/:na]
{code}
To replicate the bug run the replace_address_test.replace_stopped_node_test
dtest
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CASSANDRA-7568) Replacing a dead node using replace_address fails
[
https://issues.apache.org/jira/browse/CASSANDRA-7568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ala' Alkhaldi updated CASSANDRA-7568:
-
Description:
Failed assertion
{code}
ERROR [main] 2014-07-17 10:24:21,171 CassandraDaemon.java:474 - Exception
encountered during startup
java.lang.AssertionError: Expected 1 endpoint but found 0
at
org.apache.cassandra.dht.RangeStreamer.getAllRangesWithStrictSourcesFor(RangeStreamer.java:222)
~[main/:na]
at
org.apache.cassandra.dht.RangeStreamer.addRanges(RangeStreamer.java:131)
~[main/:na]
at
org.apache.cassandra.dht.BootStrapper.bootstrap(BootStrapper.java:72)
~[main/:na]
at
org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1049)
~[main/:na]
at
org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:811)
~[main/:na]
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:626)
~[main/:na]
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:511)
~[main/:na]
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:338)
[main/:na]
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:457)
[main/:na]
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:546)
[main/:na]
{code}
To replicate the bug run the replace_address_test.replace_stopped_node_test
dtest
was:
Failed assertion
{code}
ERROR [main] 2014-07-15 14:21:32,083 CassandraDaemon.java:474 - Exception
encountered during startup
java.lang.AssertionError: Expected 1 endpoint but found 0
at
org.apache.cassandra.dht.RangeStreamer.getAllRangesWithStrictSourcesFor(RangeStreamer.java:216)
~[main/:na]
at
org.apache.cassandra.dht.RangeStreamer.addRanges(RangeStreamer.java:131)
~[main/:na]
at
org.apache.cassandra.dht.BootStrapper.bootstrap(BootStrapper.java:72)
~[main/:na]
at
org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1049)
~[main/:na]
at
org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:811)
~[main/:na]
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:626)
~[main/:na]
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:511)
~[main/:na]
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:338)
[main/:na]
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:457)
[main/:na]
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:546)
[main/:na]
{code}
To replicate the bug run the replace_address_test.replace_stopped_node_test
dtest
Replacing a dead node using replace_address fails
-
Key: CASSANDRA-7568
URL: https://issues.apache.org/jira/browse/CASSANDRA-7568
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Ala' Alkhaldi
Priority: Minor
Failed assertion
{code}
ERROR [main] 2014-07-17 10:24:21,171 CassandraDaemon.java:474 - Exception
encountered during startup
java.lang.AssertionError: Expected 1 endpoint but found 0
at
org.apache.cassandra.dht.RangeStreamer.getAllRangesWithStrictSourcesFor(RangeStreamer.java:222)
~[main/:na]
at
org.apache.cassandra.dht.RangeStreamer.addRanges(RangeStreamer.java:131)
~[main/:na]
at
org.apache.cassandra.dht.BootStrapper.bootstrap(BootStrapper.java:72)
~[main/:na]
at
org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1049)
~[main/:na]
at
org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:811)
~[main/:na]
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:626)
~[main/:na]
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:511)
~[main/:na]
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:338)
[main/:na]
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:457)
[main/:na]
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:546)
[main/:na]
{code}
To replicate the bug run the replace_address_test.replace_stopped_node_test
dtest
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CASSANDRA-7567) when the commit_log disk for a single node is overwhelmed the entire cluster slows down
[ https://issues.apache.org/jira/browse/CASSANDRA-7567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McGuire updated CASSANDRA-7567: Tester: Ryan McGuire when the commit_log disk for a single node is overwhelmed the entire cluster slows down --- Key: CASSANDRA-7567 URL: https://issues.apache.org/jira/browse/CASSANDRA-7567 Project: Cassandra Issue Type: Bug Components: Core Environment: debian 7.5, bare metal, 14 nodes, 64CPUs, 64GB RAM, commit_log disk sata, data disk SSD, vnodes, leveled compaction strategy Reporter: David O'Dell Attachments: write_request_latency.png We've run into a situation where a single node out of 14 is experiencing high disk io. This can happen when a node is being decommissioned or after it joins the ring and runs into the bug cassandra-6621. When this occurs the write latency for the entire cluster spikes. From 0.3ms to 170ms. To simulate this simply run dd on the commit_log disk (dd if=/dev/zero of=/tmp/foo bs=1024) and you will see that instantly all nodes in the cluster have slowed down. BTW overwhelming the data disk does not have this same effect. Also I've tried this where the overwhelmed node isn't being connected directly from the client and it still has the same effect. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7567) when the commit_log disk for a single node is overwhelmed the entire cluster slows down
[ https://issues.apache.org/jira/browse/CASSANDRA-7567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14065263#comment-14065263 ] David O'Dell commented on CASSANDRA-7567: - BTW the replication_factor = 3 and the consistency level = ONE. when the commit_log disk for a single node is overwhelmed the entire cluster slows down --- Key: CASSANDRA-7567 URL: https://issues.apache.org/jira/browse/CASSANDRA-7567 Project: Cassandra Issue Type: Bug Components: Core Environment: debian 7.5, bare metal, 14 nodes, 64CPUs, 64GB RAM, commit_log disk sata, data disk SSD, vnodes, leveled compaction strategy Reporter: David O'Dell Attachments: write_request_latency.png We've run into a situation where a single node out of 14 is experiencing high disk io. This can happen when a node is being decommissioned or after it joins the ring and runs into the bug cassandra-6621. When this occurs the write latency for the entire cluster spikes. From 0.3ms to 170ms. To simulate this simply run dd on the commit_log disk (dd if=/dev/zero of=/tmp/foo bs=1024) and you will see that instantly all nodes in the cluster have slowed down. BTW overwhelming the data disk does not have this same effect. Also I've tried this where the overwhelmed node isn't being connected directly from the client and it still has the same effect. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7566) DROP/CREATE TABLE cycle causes unrecognized column family
[ https://issues.apache.org/jira/browse/CASSANDRA-7566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14065343#comment-14065343 ] Ben Hood commented on CASSANDRA-7566: - [~yukim] Yes, gocql does prepare all statements by default. I could see if I can disable this behavior in the gocql driver and see if that has an effect. DROP/CREATE TABLE cycle causes unrecognized column family - Key: CASSANDRA-7566 URL: https://issues.apache.org/jira/browse/CASSANDRA-7566 Project: Cassandra Issue Type: Bug Components: Core Environment: OSX 10.9.4 / JDK 1.8.0_05 Reporter: Ben Hood Assignee: Yuki Morishita An integration test suite that drops and creates the same column family 3 times causes the following error in the server log: INFO 15:40:34 Initializing gocql_test.wiki_page ERROR 15:40:34 Attempted to write commit log entry for unrecognized column family: b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempting to mutate non-existant column family b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempted to write commit log entry for unrecognized column family: b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempting to mutate non-existant column family b0e167e0-0dc8-11e4-9cbb-29a4872887f2 The test that reproduces this issue is here: https://github.com/gocql/gocql/blob/master/wiki_test.go Interestingly this issue only occurs after the common table is dropped/created for the 3rd time. If only one of the tests is run on its own, this issue does not arise. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7566) DROP/CREATE TABLE cycle causes unrecognized column family
[
https://issues.apache.org/jira/browse/CASSANDRA-7566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14065376#comment-14065376
]
Ben Hood commented on CASSANDRA-7566:
-
OK, so the plot thickens.
By disabling statement preparation in the driver, I was able to workaround this
issue (see this patch for a workaround for this particular test case).
That said, I have noticed that another test fails for a different reason. Now
the test called TestReprepareStatement
(https://github.com/gocql/gocql/blob/master/cassandra_test.go#L582) which tests
the handling of statement re-preparation now fails with this server error:
{noformat}
INFO 18:56:03 Initializing gocql_test.test_reprepare_statement
ERROR 18:56:03 Unexpected exception during request
java.lang.NullPointerException: null
at
org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:105)
~[apache-cassandra-2.1.0-rc3.jar:2.1.0-rc3]
at
org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:421)
[apache-cassandra-2.1.0-rc3.jar:2.1.0-rc3]
at
org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:318)
[apache-cassandra-2.1.0-rc3.jar:2.1.0-rc3]
at
io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:103)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:31)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:323)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[na:1.8.0_05]
at
org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:162)
[apache-cassandra-2.1.0-rc3.jar:2.1.0-rc3]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:103)
[apache-cassandra-2.1.0-rc3.jar:2.1.0-rc3]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_05]
{noformat}
This looks like two different bugs and potentially should be handled by two
separate bug reports?
DROP/CREATE TABLE cycle causes unrecognized column family
-
Key: CASSANDRA-7566
URL: https://issues.apache.org/jira/browse/CASSANDRA-7566
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: OSX 10.9.4 / JDK 1.8.0_05
Reporter: Ben Hood
Assignee: Yuki Morishita
An integration test suite that drops and creates the same column family 3
times causes the following error in the server log:
INFO 15:40:34 Initializing gocql_test.wiki_page
ERROR 15:40:34 Attempted to write commit log entry for unrecognized column
family: b0e167e0-0dc8-11e4-9cbb-29a4872887f2
ERROR 15:40:34 Attempting to mutate non-existant column family
b0e167e0-0dc8-11e4-9cbb-29a4872887f2
ERROR 15:40:34 Attempted to write commit log entry for unrecognized column
family: b0e167e0-0dc8-11e4-9cbb-29a4872887f2
ERROR 15:40:34 Attempting to mutate non-existant column family
b0e167e0-0dc8-11e4-9cbb-29a4872887f2
The test that reproduces this issue is here:
https://github.com/gocql/gocql/blob/master/wiki_test.go
Interestingly this issue only occurs after the common table is
dropped/created for the 3rd time. If only one of the tests is run on its own,
this issue does not arise.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7566) DROP/CREATE TABLE cycle causes unrecognized column family
[ https://issues.apache.org/jira/browse/CASSANDRA-7566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14065383#comment-14065383 ] Ben Hood commented on CASSANDRA-7566: - For anybody coming across this issue via Google, the original pull request to gocql that provokes this error is here: https://github.com/gocql/gocql/pull/198 DROP/CREATE TABLE cycle causes unrecognized column family - Key: CASSANDRA-7566 URL: https://issues.apache.org/jira/browse/CASSANDRA-7566 Project: Cassandra Issue Type: Bug Components: Core Environment: OSX 10.9.4 / JDK 1.8.0_05 Reporter: Ben Hood Assignee: Yuki Morishita An integration test suite that drops and creates the same column family 3 times causes the following error in the server log: INFO 15:40:34 Initializing gocql_test.wiki_page ERROR 15:40:34 Attempted to write commit log entry for unrecognized column family: b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempting to mutate non-existant column family b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempted to write commit log entry for unrecognized column family: b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempting to mutate non-existant column family b0e167e0-0dc8-11e4-9cbb-29a4872887f2 The test that reproduces this issue is here: https://github.com/gocql/gocql/blob/master/wiki_test.go Interestingly this issue only occurs after the common table is dropped/created for the 3rd time. If only one of the tests is run on its own, this issue does not arise. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7395) Support for pure user-defined functions (UDF)
[ https://issues.apache.org/jira/browse/CASSANDRA-7395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14065427#comment-14065427 ] Tyler Hobbs commented on CASSANDRA-7395: bq. Just thought a bit of UDTs, TupleType and collections for UDFs. There are too many things to take care of regarding such complex types. So I'm pretty sure that it's better to only allow primitive types in this ticket and use CASSANDRA-7563 to support complex types. +1 Support for pure user-defined functions (UDF) - Key: CASSANDRA-7395 URL: https://issues.apache.org/jira/browse/CASSANDRA-7395 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Jonathan Ellis Assignee: Robert Stupp Labels: cql Fix For: 3.0 Attachments: 7395.txt We have some tickets for various aspects of UDF (CASSANDRA-4914, CASSANDRA-5970, CASSANDRA-4998) but they all suffer from various degrees of ocean-boiling. Let's start with something simple: allowing pure user-defined functions in the SELECT clause of a CQL query. That's it. By pure I mean, must depend only on the input parameters. No side effects. No exposure to C* internals. Column values in, result out. http://en.wikipedia.org/wiki/Pure_function -- This message was sent by Atlassian JIRA (v6.2#6252)
git commit: Fix cqlsh authentication with 2.1 python driver
Repository: cassandra Updated Branches: refs/heads/cassandra-2.1.0 2a661195f - e4b40c75c Fix cqlsh authentication with 2.1 python driver Patch by Mike Adamson; reviewed by Tyler Hobbs for CASSANDRA-7564 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e4b40c75 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e4b40c75 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e4b40c75 Branch: refs/heads/cassandra-2.1.0 Commit: e4b40c75c050914a5f2bdc88271e1ab518f8aaac Parents: 2a66119 Author: Tyler Hobbs ty...@datastax.com Authored: Thu Jul 17 14:43:47 2014 -0500 Committer: Tyler Hobbs ty...@datastax.com Committed: Thu Jul 17 14:43:47 2014 -0500 -- CHANGES.txt | 1 + bin/cqlsh | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/e4b40c75/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 8864cb1..81a35cd 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -8,6 +8,7 @@ * Fix configuration error message when running nodetool ring (CASSANDRA-7508) * Support conditional updates, tuple type, and the v3 protocol in cqlsh (CASSANDRA-7509) * Handle queries on multiple secondary index types (CASSANDRA-7525) + * Fix cqlsh authentication with v3 native protocol (CASSANDRA-7564) Merged from 2.0: * (Windows) force range-based repair to non-sequential mode (CASSANDRA-7541) * Fix range merging when DES scores are zero (CASSANDRA-7535) http://git-wip-us.apache.org/repos/asf/cassandra/blob/e4b40c75/bin/cqlsh -- diff --git a/bin/cqlsh b/bin/cqlsh index 76ff590..1798d3f 100755 --- a/bin/cqlsh +++ b/bin/cqlsh @@ -110,6 +110,7 @@ from cassandra.cluster import Cluster from cassandra.query import SimpleStatement from cassandra.policies import WhiteListRoundRobinPolicy from cassandra.metadata import protect_name, protect_names, protect_value +from cassandra.auth import PlainTextAuthProvider # cqlsh should run correctly when run out of a Cassandra source tree, # out of an unpacked Cassandra tarball, and after a proper package install. @@ -499,7 +500,7 @@ class Shell(cmd.Cmd): if username: if not password: password = getpass.getpass() -self.auth_provider = lambda host: dict(username=username, password=password) +self.auth_provider = PlainTextAuthProvider(username=username, password=password) self.keyspace = keyspace self.tracing_enabled = tracing_enabled self.expand_enabled = expand_enabled
[2/2] git commit: Merge branch 'cassandra-2.1.0' into cassandra-2.1
Merge branch 'cassandra-2.1.0' into cassandra-2.1 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e64c301d Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e64c301d Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e64c301d Branch: refs/heads/cassandra-2.1 Commit: e64c301dd37d36d543545b7ee44c00d71a3bfd18 Parents: 22f811e e4b40c7 Author: Tyler Hobbs ty...@datastax.com Authored: Thu Jul 17 14:45:07 2014 -0500 Committer: Tyler Hobbs ty...@datastax.com Committed: Thu Jul 17 14:45:07 2014 -0500 -- CHANGES.txt | 1 + bin/cqlsh | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/e64c301d/CHANGES.txt -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/e64c301d/bin/cqlsh --
[1/2] git commit: Fix cqlsh authentication with 2.1 python driver
Repository: cassandra Updated Branches: refs/heads/cassandra-2.1 22f811e3b - e64c301dd Fix cqlsh authentication with 2.1 python driver Patch by Mike Adamson; reviewed by Tyler Hobbs for CASSANDRA-7564 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e4b40c75 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e4b40c75 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e4b40c75 Branch: refs/heads/cassandra-2.1 Commit: e4b40c75c050914a5f2bdc88271e1ab518f8aaac Parents: 2a66119 Author: Tyler Hobbs ty...@datastax.com Authored: Thu Jul 17 14:43:47 2014 -0500 Committer: Tyler Hobbs ty...@datastax.com Committed: Thu Jul 17 14:43:47 2014 -0500 -- CHANGES.txt | 1 + bin/cqlsh | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/e4b40c75/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 8864cb1..81a35cd 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -8,6 +8,7 @@ * Fix configuration error message when running nodetool ring (CASSANDRA-7508) * Support conditional updates, tuple type, and the v3 protocol in cqlsh (CASSANDRA-7509) * Handle queries on multiple secondary index types (CASSANDRA-7525) + * Fix cqlsh authentication with v3 native protocol (CASSANDRA-7564) Merged from 2.0: * (Windows) force range-based repair to non-sequential mode (CASSANDRA-7541) * Fix range merging when DES scores are zero (CASSANDRA-7535) http://git-wip-us.apache.org/repos/asf/cassandra/blob/e4b40c75/bin/cqlsh -- diff --git a/bin/cqlsh b/bin/cqlsh index 76ff590..1798d3f 100755 --- a/bin/cqlsh +++ b/bin/cqlsh @@ -110,6 +110,7 @@ from cassandra.cluster import Cluster from cassandra.query import SimpleStatement from cassandra.policies import WhiteListRoundRobinPolicy from cassandra.metadata import protect_name, protect_names, protect_value +from cassandra.auth import PlainTextAuthProvider # cqlsh should run correctly when run out of a Cassandra source tree, # out of an unpacked Cassandra tarball, and after a proper package install. @@ -499,7 +500,7 @@ class Shell(cmd.Cmd): if username: if not password: password = getpass.getpass() -self.auth_provider = lambda host: dict(username=username, password=password) +self.auth_provider = PlainTextAuthProvider(username=username, password=password) self.keyspace = keyspace self.tracing_enabled = tracing_enabled self.expand_enabled = expand_enabled
[3/3] git commit: Merge branch 'cassandra-2.1' into trunk
Merge branch 'cassandra-2.1' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/1a58ecc2 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/1a58ecc2 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/1a58ecc2 Branch: refs/heads/trunk Commit: 1a58ecc266260fae9f734681449511b01ad3e97a Parents: 41a91e9 e64c301 Author: Tyler Hobbs ty...@datastax.com Authored: Thu Jul 17 14:45:31 2014 -0500 Committer: Tyler Hobbs ty...@datastax.com Committed: Thu Jul 17 14:45:31 2014 -0500 -- CHANGES.txt | 1 + bin/cqlsh | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/1a58ecc2/CHANGES.txt --
[1/3] git commit: Fix cqlsh authentication with 2.1 python driver
Repository: cassandra Updated Branches: refs/heads/trunk 41a91e9a1 - 1a58ecc26 Fix cqlsh authentication with 2.1 python driver Patch by Mike Adamson; reviewed by Tyler Hobbs for CASSANDRA-7564 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e4b40c75 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e4b40c75 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e4b40c75 Branch: refs/heads/trunk Commit: e4b40c75c050914a5f2bdc88271e1ab518f8aaac Parents: 2a66119 Author: Tyler Hobbs ty...@datastax.com Authored: Thu Jul 17 14:43:47 2014 -0500 Committer: Tyler Hobbs ty...@datastax.com Committed: Thu Jul 17 14:43:47 2014 -0500 -- CHANGES.txt | 1 + bin/cqlsh | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/e4b40c75/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 8864cb1..81a35cd 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -8,6 +8,7 @@ * Fix configuration error message when running nodetool ring (CASSANDRA-7508) * Support conditional updates, tuple type, and the v3 protocol in cqlsh (CASSANDRA-7509) * Handle queries on multiple secondary index types (CASSANDRA-7525) + * Fix cqlsh authentication with v3 native protocol (CASSANDRA-7564) Merged from 2.0: * (Windows) force range-based repair to non-sequential mode (CASSANDRA-7541) * Fix range merging when DES scores are zero (CASSANDRA-7535) http://git-wip-us.apache.org/repos/asf/cassandra/blob/e4b40c75/bin/cqlsh -- diff --git a/bin/cqlsh b/bin/cqlsh index 76ff590..1798d3f 100755 --- a/bin/cqlsh +++ b/bin/cqlsh @@ -110,6 +110,7 @@ from cassandra.cluster import Cluster from cassandra.query import SimpleStatement from cassandra.policies import WhiteListRoundRobinPolicy from cassandra.metadata import protect_name, protect_names, protect_value +from cassandra.auth import PlainTextAuthProvider # cqlsh should run correctly when run out of a Cassandra source tree, # out of an unpacked Cassandra tarball, and after a proper package install. @@ -499,7 +500,7 @@ class Shell(cmd.Cmd): if username: if not password: password = getpass.getpass() -self.auth_provider = lambda host: dict(username=username, password=password) +self.auth_provider = PlainTextAuthProvider(username=username, password=password) self.keyspace = keyspace self.tracing_enabled = tracing_enabled self.expand_enabled = expand_enabled
[2/3] git commit: Merge branch 'cassandra-2.1.0' into cassandra-2.1
Merge branch 'cassandra-2.1.0' into cassandra-2.1 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e64c301d Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e64c301d Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e64c301d Branch: refs/heads/trunk Commit: e64c301dd37d36d543545b7ee44c00d71a3bfd18 Parents: 22f811e e4b40c7 Author: Tyler Hobbs ty...@datastax.com Authored: Thu Jul 17 14:45:07 2014 -0500 Committer: Tyler Hobbs ty...@datastax.com Committed: Thu Jul 17 14:45:07 2014 -0500 -- CHANGES.txt | 1 + bin/cqlsh | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/e64c301d/CHANGES.txt -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/e64c301d/bin/cqlsh --
[jira] [Commented] (CASSANDRA-7566) DROP/CREATE TABLE cycle causes unrecognized column family
[ https://issues.apache.org/jira/browse/CASSANDRA-7566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14065459#comment-14065459 ] Tyler Hobbs commented on CASSANDRA-7566: The NPE in ExecuteMessage is CASSANDRA-7454. That was supposed to be fixed in rc3, but it looks like it got committed for 2.1.1 instead. I'll commit that to 2.1.0 and update the ticket. DROP/CREATE TABLE cycle causes unrecognized column family - Key: CASSANDRA-7566 URL: https://issues.apache.org/jira/browse/CASSANDRA-7566 Project: Cassandra Issue Type: Bug Components: Core Environment: OSX 10.9.4 / JDK 1.8.0_05 Reporter: Ben Hood Assignee: Yuki Morishita An integration test suite that drops and creates the same column family 3 times causes the following error in the server log: INFO 15:40:34 Initializing gocql_test.wiki_page ERROR 15:40:34 Attempted to write commit log entry for unrecognized column family: b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempting to mutate non-existant column family b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempted to write commit log entry for unrecognized column family: b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempting to mutate non-existant column family b0e167e0-0dc8-11e4-9cbb-29a4872887f2 The test that reproduces this issue is here: https://github.com/gocql/gocql/blob/master/wiki_test.go Interestingly this issue only occurs after the common table is dropped/created for the 3rd time. If only one of the tests is run on its own, this issue does not arise. -- This message was sent by Atlassian JIRA (v6.2#6252)
git commit: Backport CASSANDRA-7454 to 2.1.0
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.1.0 e4b40c75c - 9c1782d39
Backport CASSANDRA-7454 to 2.1.0
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9c1782d3
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9c1782d3
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9c1782d3
Branch: refs/heads/cassandra-2.1.0
Commit: 9c1782d39702b8bf8b8380faedc75048ef8bd9b7
Parents: e4b40c7
Author: Tyler Hobbs ty...@datastax.com
Authored: Fri Jun 27 09:35:53 2014 -0500
Committer: Tyler Hobbs ty...@datastax.com
Committed: Thu Jul 17 14:58:09 2014 -0500
--
CHANGES.txt| 1 +
.../apache/cassandra/transport/messages/ExecuteMessage.java| 6 +++---
2 files changed, 4 insertions(+), 3 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/9c1782d3/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 81a35cd..ff417b1 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -9,6 +9,7 @@
* Support conditional updates, tuple type, and the v3 protocol in cqlsh
(CASSANDRA-7509)
* Handle queries on multiple secondary index types (CASSANDRA-7525)
* Fix cqlsh authentication with v3 native protocol (CASSANDRA-7564)
+ * Fix NPE when unknown prepared statement ID is used (CASSANDRA-7454)
Merged from 2.0:
* (Windows) force range-based repair to non-sequential mode (CASSANDRA-7541)
* Fix range merging when DES scores are zero (CASSANDRA-7535)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/9c1782d3/src/java/org/apache/cassandra/transport/messages/ExecuteMessage.java
--
diff --git
a/src/java/org/apache/cassandra/transport/messages/ExecuteMessage.java
b/src/java/org/apache/cassandra/transport/messages/ExecuteMessage.java
index d618f43..78182b2 100644
--- a/src/java/org/apache/cassandra/transport/messages/ExecuteMessage.java
+++ b/src/java/org/apache/cassandra/transport/messages/ExecuteMessage.java
@@ -102,12 +102,12 @@ public class ExecuteMessage extends Message.Request
{
QueryHandler handler = state.getClientState().getCQLQueryHandler();
ParsedStatement.Prepared prepared =
handler.getPrepared(statementId);
+if (prepared == null)
+throw new PreparedQueryNotFoundException(statementId);
+
options.prepare(prepared.boundNames);
CQLStatement statement = prepared.statement;
-if (statement == null)
-throw new PreparedQueryNotFoundException(statementId);
-
if (options.getPageSize() == 0)
throw new ProtocolException(The page size cannot be 0);
[2/3] git commit: Merge branch 'cassandra-2.1.0' into cassandra-2.1
Merge branch 'cassandra-2.1.0' into cassandra-2.1 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/b9f03c88 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/b9f03c88 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/b9f03c88 Branch: refs/heads/cassandra-2.1 Commit: b9f03c88dbb9a9ee1a865633874b0fb6ac1937ec Parents: e64c301 9c1782d Author: Tyler Hobbs ty...@datastax.com Authored: Thu Jul 17 14:59:17 2014 -0500 Committer: Tyler Hobbs ty...@datastax.com Committed: Thu Jul 17 14:59:17 2014 -0500 -- CHANGES.txt | 1 + 1 file changed, 1 insertion(+) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/b9f03c88/CHANGES.txt --
[1/3] git commit: Backport CASSANDRA-7454 to 2.1.0
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.1 e64c301dd - 3d0e54e14
Backport CASSANDRA-7454 to 2.1.0
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9c1782d3
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9c1782d3
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9c1782d3
Branch: refs/heads/cassandra-2.1
Commit: 9c1782d39702b8bf8b8380faedc75048ef8bd9b7
Parents: e4b40c7
Author: Tyler Hobbs ty...@datastax.com
Authored: Fri Jun 27 09:35:53 2014 -0500
Committer: Tyler Hobbs ty...@datastax.com
Committed: Thu Jul 17 14:58:09 2014 -0500
--
CHANGES.txt| 1 +
.../apache/cassandra/transport/messages/ExecuteMessage.java| 6 +++---
2 files changed, 4 insertions(+), 3 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/9c1782d3/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 81a35cd..ff417b1 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -9,6 +9,7 @@
* Support conditional updates, tuple type, and the v3 protocol in cqlsh
(CASSANDRA-7509)
* Handle queries on multiple secondary index types (CASSANDRA-7525)
* Fix cqlsh authentication with v3 native protocol (CASSANDRA-7564)
+ * Fix NPE when unknown prepared statement ID is used (CASSANDRA-7454)
Merged from 2.0:
* (Windows) force range-based repair to non-sequential mode (CASSANDRA-7541)
* Fix range merging when DES scores are zero (CASSANDRA-7535)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/9c1782d3/src/java/org/apache/cassandra/transport/messages/ExecuteMessage.java
--
diff --git
a/src/java/org/apache/cassandra/transport/messages/ExecuteMessage.java
b/src/java/org/apache/cassandra/transport/messages/ExecuteMessage.java
index d618f43..78182b2 100644
--- a/src/java/org/apache/cassandra/transport/messages/ExecuteMessage.java
+++ b/src/java/org/apache/cassandra/transport/messages/ExecuteMessage.java
@@ -102,12 +102,12 @@ public class ExecuteMessage extends Message.Request
{
QueryHandler handler = state.getClientState().getCQLQueryHandler();
ParsedStatement.Prepared prepared =
handler.getPrepared(statementId);
+if (prepared == null)
+throw new PreparedQueryNotFoundException(statementId);
+
options.prepare(prepared.boundNames);
CQLStatement statement = prepared.statement;
-if (statement == null)
-throw new PreparedQueryNotFoundException(statementId);
-
if (options.getPageSize() == 0)
throw new ProtocolException(The page size cannot be 0);
[3/3] git commit: Ninja: fix CASSANDRA-7454 placement in CHANGES.txt
Ninja: fix CASSANDRA-7454 placement in CHANGES.txt Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3d0e54e1 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3d0e54e1 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3d0e54e1 Branch: refs/heads/cassandra-2.1 Commit: 3d0e54e14ba04420277964186614fc8dc57ccfb0 Parents: b9f03c8 Author: Tyler Hobbs ty...@datastax.com Authored: Thu Jul 17 14:59:36 2014 -0500 Committer: Tyler Hobbs ty...@datastax.com Committed: Thu Jul 17 14:59:36 2014 -0500 -- CHANGES.txt | 1 - 1 file changed, 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/3d0e54e1/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index dbb160d..eb2a1a0 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -2,7 +2,6 @@ * Add listen_interface and rpc_interface options (CASSANDRA-7417) * Fail to start if commit log replay detects a problem (CASSANDRA-7125) * Improve schema merge performance (CASSANDRA-7444) - * Fix NPE when unknown prepared statement ID is used (CASSANDRA-7454) * Adjust MT depth based on # of partition validating (CASSANDRA-5263) * Optimise NativeCell comparisons (CASSANDRA-6755) * Configurable client timeout for cqlsh (CASSANDRA-7516)
[1/4] git commit: Backport CASSANDRA-7454 to 2.1.0
Repository: cassandra
Updated Branches:
refs/heads/trunk 1a58ecc26 - d0871336a
Backport CASSANDRA-7454 to 2.1.0
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9c1782d3
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9c1782d3
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9c1782d3
Branch: refs/heads/trunk
Commit: 9c1782d39702b8bf8b8380faedc75048ef8bd9b7
Parents: e4b40c7
Author: Tyler Hobbs ty...@datastax.com
Authored: Fri Jun 27 09:35:53 2014 -0500
Committer: Tyler Hobbs ty...@datastax.com
Committed: Thu Jul 17 14:58:09 2014 -0500
--
CHANGES.txt| 1 +
.../apache/cassandra/transport/messages/ExecuteMessage.java| 6 +++---
2 files changed, 4 insertions(+), 3 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/9c1782d3/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 81a35cd..ff417b1 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -9,6 +9,7 @@
* Support conditional updates, tuple type, and the v3 protocol in cqlsh
(CASSANDRA-7509)
* Handle queries on multiple secondary index types (CASSANDRA-7525)
* Fix cqlsh authentication with v3 native protocol (CASSANDRA-7564)
+ * Fix NPE when unknown prepared statement ID is used (CASSANDRA-7454)
Merged from 2.0:
* (Windows) force range-based repair to non-sequential mode (CASSANDRA-7541)
* Fix range merging when DES scores are zero (CASSANDRA-7535)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/9c1782d3/src/java/org/apache/cassandra/transport/messages/ExecuteMessage.java
--
diff --git
a/src/java/org/apache/cassandra/transport/messages/ExecuteMessage.java
b/src/java/org/apache/cassandra/transport/messages/ExecuteMessage.java
index d618f43..78182b2 100644
--- a/src/java/org/apache/cassandra/transport/messages/ExecuteMessage.java
+++ b/src/java/org/apache/cassandra/transport/messages/ExecuteMessage.java
@@ -102,12 +102,12 @@ public class ExecuteMessage extends Message.Request
{
QueryHandler handler = state.getClientState().getCQLQueryHandler();
ParsedStatement.Prepared prepared =
handler.getPrepared(statementId);
+if (prepared == null)
+throw new PreparedQueryNotFoundException(statementId);
+
options.prepare(prepared.boundNames);
CQLStatement statement = prepared.statement;
-if (statement == null)
-throw new PreparedQueryNotFoundException(statementId);
-
if (options.getPageSize() == 0)
throw new ProtocolException(The page size cannot be 0);
[3/4] git commit: Ninja: fix CASSANDRA-7454 placement in CHANGES.txt
Ninja: fix CASSANDRA-7454 placement in CHANGES.txt Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3d0e54e1 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3d0e54e1 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3d0e54e1 Branch: refs/heads/trunk Commit: 3d0e54e14ba04420277964186614fc8dc57ccfb0 Parents: b9f03c8 Author: Tyler Hobbs ty...@datastax.com Authored: Thu Jul 17 14:59:36 2014 -0500 Committer: Tyler Hobbs ty...@datastax.com Committed: Thu Jul 17 14:59:36 2014 -0500 -- CHANGES.txt | 1 - 1 file changed, 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/3d0e54e1/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index dbb160d..eb2a1a0 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -2,7 +2,6 @@ * Add listen_interface and rpc_interface options (CASSANDRA-7417) * Fail to start if commit log replay detects a problem (CASSANDRA-7125) * Improve schema merge performance (CASSANDRA-7444) - * Fix NPE when unknown prepared statement ID is used (CASSANDRA-7454) * Adjust MT depth based on # of partition validating (CASSANDRA-5263) * Optimise NativeCell comparisons (CASSANDRA-6755) * Configurable client timeout for cqlsh (CASSANDRA-7516)
[4/4] git commit: Merge branch 'cassandra-2.1' into trunk
Merge branch 'cassandra-2.1' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/d0871336 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/d0871336 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/d0871336 Branch: refs/heads/trunk Commit: d0871336a6d4a546f1e55708f2908b600b48d975 Parents: 1a58ecc 3d0e54e Author: Tyler Hobbs ty...@datastax.com Authored: Thu Jul 17 15:00:35 2014 -0500 Committer: Tyler Hobbs ty...@datastax.com Committed: Thu Jul 17 15:00:35 2014 -0500 -- CHANGES.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/d0871336/CHANGES.txt --
[2/4] git commit: Merge branch 'cassandra-2.1.0' into cassandra-2.1
Merge branch 'cassandra-2.1.0' into cassandra-2.1 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/b9f03c88 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/b9f03c88 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/b9f03c88 Branch: refs/heads/trunk Commit: b9f03c88dbb9a9ee1a865633874b0fb6ac1937ec Parents: e64c301 9c1782d Author: Tyler Hobbs ty...@datastax.com Authored: Thu Jul 17 14:59:17 2014 -0500 Committer: Tyler Hobbs ty...@datastax.com Committed: Thu Jul 17 14:59:17 2014 -0500 -- CHANGES.txt | 1 + 1 file changed, 1 insertion(+) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/b9f03c88/CHANGES.txt --
[jira] [Updated] (CASSANDRA-7454) NPE When Prepared Statement ID is not Found
[
https://issues.apache.org/jira/browse/CASSANDRA-7454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tyler Hobbs updated CASSANDRA-7454:
---
Fix Version/s: (was: 2.1 rc3)
2.1.0
NPE When Prepared Statement ID is not Found
---
Key: CASSANDRA-7454
URL: https://issues.apache.org/jira/browse/CASSANDRA-7454
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Tyler Hobbs
Assignee: Tyler Hobbs
Fix For: 2.1.0
Attachments: 7475.txt
CASSANDRA-6855 introduced a NullPointerException when an unknown prepared
statement ID is used.
You'll see a stack trace like this:
{noformat}
ERROR [SharedPool-Worker-4] 2014-06-26 15:02:04,911 ErrorMessage.java:218 -
Unexpected exception during request
java.lang.NullPointerException: null
at
org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:105)
~[main/:na]
at
org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:412)
[main/:na]
at
org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:309)
[main/:na]
at
io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:103)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:31)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:323)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
[na:1.7.0_40]
at
org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:162)
[main/:na]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:103)
[main/:na]
at java.lang.Thread.run(Thread.java:724) [na:1.7.0_40]
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7507) OOM creates unreliable state - die instantly better
[ https://issues.apache.org/jira/browse/CASSANDRA-7507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14065510#comment-14065510 ] Joshua McKenzie commented on CASSANDRA-7507: It's easy enough to check for a FileNotFoundException w/Too many files inside CassandraDaemon's uncaught exception handler. It looks like we have a few places within the native transport layer that are handling all exceptions locally regardless of exception type rather than bubbling any up as runtime - while we'll likely see errors across the board if we get into this condition, I think it would probably be wise to pass specific errors up out of the transport layer if we see them as they're indicative of these bigger problems to come. What do you think [~benedict]? OOM creates unreliable state - die instantly better --- Key: CASSANDRA-7507 URL: https://issues.apache.org/jira/browse/CASSANDRA-7507 Project: Cassandra Issue Type: New Feature Reporter: Karl Mueller Assignee: Joshua McKenzie Priority: Minor Fix For: 2.1.1 Attachments: 7507_v1.txt I had a cassandra node run OOM. My heap had enough headroom, there was just something which either was a bug or some unfortunate amount of short-term memory utilization. This resulted in the following error: WARN [StorageServiceShutdownHook] 2014-06-30 09:38:38,251 StorageProxy.java (line 1713) Some hints were not written before shutdown. This is not supposed to happen. You should (a) run repair, and (b) file a bug report There are no other messages of relevance besides the OOM error about 90 minutes earlier. My (limited) understanding of the JVM and Cassandra says that when it goes OOM, it will attempt to signal cassandra to shut down cleanly. The problem, in my view, is that with an OOM situation, nothing is guaranteed anymore. I believe it's impossible to reliably cleanly shut down at this point, and therefore it's wrong to even try. Yes, ideally things could be written out, flushed to disk, memory messages written, other nodes notified, etc. but why is there any reason to believe any of those steps could happen? Would happen? Couldn't bad data be written at this point to disk rather than good data? Some network messages delivered, but not others? I think Cassandra should have the option to (and possibly default) to kill itself immediately upon the OOM condition happening in a hard way, and not rely on the java-based clean shutdown process. Cassandra already handles recovery from unclean shutdown, and it's not a big deal. My node, for example, kept in a sort-of alive state for 90 minutes where who knows what it was doing or not doing. I don't know enough about the JVM and options for it to know the best exact implementation of die instantly on OOM, but it should be something that's possible either with some flags or a C library (which doesn't rely on java memory to do something which it may not be able to get!) Short version: a kill -9 of all C* processes in that instance without needing more java memory, when OOM is raised -- This message was sent by Atlassian JIRA (v6.2#6252)
[01/10] git commit: fix setlogginglevel help in nodetool
Repository: cassandra Updated Branches: refs/heads/cassandra-2.0 93c27549a - 062addb4c refs/heads/cassandra-2.1 3d0e54e14 - f873a3278 refs/heads/cassandra-2.1.0 9c1782d39 - 5de9c17dd refs/heads/trunk d0871336a - c996a36d7 fix setlogginglevel help in nodetool Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/062addb4 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/062addb4 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/062addb4 Branch: refs/heads/cassandra-2.0 Commit: 062addb4c5f1131de7f092ff04df12e75880c786 Parents: 93c2754 Author: Brandon Williams bran...@datastax.com Authored: Thu Jul 17 15:49:01 2014 -0500 Committer: Brandon Williams bran...@datastax.com Committed: Thu Jul 17 15:49:01 2014 -0500 -- src/resources/org/apache/cassandra/tools/NodeToolHelp.yaml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/062addb4/src/resources/org/apache/cassandra/tools/NodeToolHelp.yaml -- diff --git a/src/resources/org/apache/cassandra/tools/NodeToolHelp.yaml b/src/resources/org/apache/cassandra/tools/NodeToolHelp.yaml index 8b0185e..6467330 100644 --- a/src/resources/org/apache/cassandra/tools/NodeToolHelp.yaml +++ b/src/resources/org/apache/cassandra/tools/NodeToolHelp.yaml @@ -220,9 +220,9 @@ commands: - name: reloadtriggers help: | reload trigger classes - - name: setLoggingLevel + - name: setlogginglevel class level help: | - Set a log level for a given logger. If both classQualifer and level are empty/null, it will reset to the initial configuration - - name: getLoggingLevels + Set the log level threshold for a given class. If both class and level are empty/null, it will reset to the initial configuration + - name: getlogginglevels help: | Get the runtime logging levels
[03/10] git commit: fix setlogginglevel help in nodetool
fix setlogginglevel help in nodetool Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/062addb4 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/062addb4 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/062addb4 Branch: refs/heads/cassandra-2.1 Commit: 062addb4c5f1131de7f092ff04df12e75880c786 Parents: 93c2754 Author: Brandon Williams bran...@datastax.com Authored: Thu Jul 17 15:49:01 2014 -0500 Committer: Brandon Williams bran...@datastax.com Committed: Thu Jul 17 15:49:01 2014 -0500 -- src/resources/org/apache/cassandra/tools/NodeToolHelp.yaml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/062addb4/src/resources/org/apache/cassandra/tools/NodeToolHelp.yaml -- diff --git a/src/resources/org/apache/cassandra/tools/NodeToolHelp.yaml b/src/resources/org/apache/cassandra/tools/NodeToolHelp.yaml index 8b0185e..6467330 100644 --- a/src/resources/org/apache/cassandra/tools/NodeToolHelp.yaml +++ b/src/resources/org/apache/cassandra/tools/NodeToolHelp.yaml @@ -220,9 +220,9 @@ commands: - name: reloadtriggers help: | reload trigger classes - - name: setLoggingLevel + - name: setlogginglevel class level help: | - Set a log level for a given logger. If both classQualifer and level are empty/null, it will reset to the initial configuration - - name: getLoggingLevels + Set the log level threshold for a given class. If both class and level are empty/null, it will reset to the initial configuration + - name: getlogginglevels help: | Get the runtime logging levels
[04/10] git commit: fix setlogginglevel help in nodetool
fix setlogginglevel help in nodetool Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/062addb4 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/062addb4 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/062addb4 Branch: refs/heads/trunk Commit: 062addb4c5f1131de7f092ff04df12e75880c786 Parents: 93c2754 Author: Brandon Williams bran...@datastax.com Authored: Thu Jul 17 15:49:01 2014 -0500 Committer: Brandon Williams bran...@datastax.com Committed: Thu Jul 17 15:49:01 2014 -0500 -- src/resources/org/apache/cassandra/tools/NodeToolHelp.yaml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/062addb4/src/resources/org/apache/cassandra/tools/NodeToolHelp.yaml -- diff --git a/src/resources/org/apache/cassandra/tools/NodeToolHelp.yaml b/src/resources/org/apache/cassandra/tools/NodeToolHelp.yaml index 8b0185e..6467330 100644 --- a/src/resources/org/apache/cassandra/tools/NodeToolHelp.yaml +++ b/src/resources/org/apache/cassandra/tools/NodeToolHelp.yaml @@ -220,9 +220,9 @@ commands: - name: reloadtriggers help: | reload trigger classes - - name: setLoggingLevel + - name: setlogginglevel class level help: | - Set a log level for a given logger. If both classQualifer and level are empty/null, it will reset to the initial configuration - - name: getLoggingLevels + Set the log level threshold for a given class. If both class and level are empty/null, it will reset to the initial configuration + - name: getlogginglevels help: | Get the runtime logging levels
[07/10] git commit: Merge branch 'cassandra-2.0' into cassandra-2.1.0
Merge branch 'cassandra-2.0' into cassandra-2.1.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/5de9c17d Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/5de9c17d Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/5de9c17d Branch: refs/heads/trunk Commit: 5de9c17dd57dbf2877a9878b0dd13d32868ce629 Parents: 9c1782d 062addb Author: Brandon Williams bran...@datastax.com Authored: Thu Jul 17 15:49:12 2014 -0500 Committer: Brandon Williams bran...@datastax.com Committed: Thu Jul 17 15:49:12 2014 -0500 -- --
[06/10] git commit: Merge branch 'cassandra-2.0' into cassandra-2.1.0
Merge branch 'cassandra-2.0' into cassandra-2.1.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/5de9c17d Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/5de9c17d Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/5de9c17d Branch: refs/heads/cassandra-2.1.0 Commit: 5de9c17dd57dbf2877a9878b0dd13d32868ce629 Parents: 9c1782d 062addb Author: Brandon Williams bran...@datastax.com Authored: Thu Jul 17 15:49:12 2014 -0500 Committer: Brandon Williams bran...@datastax.com Committed: Thu Jul 17 15:49:12 2014 -0500 -- --
[08/10] git commit: Merge branch 'cassandra-2.1.0' into cassandra-2.1
Merge branch 'cassandra-2.1.0' into cassandra-2.1 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/f873a327 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f873a327 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f873a327 Branch: refs/heads/trunk Commit: f873a3278603135c494713136cea4e343b0e765f Parents: 3d0e54e 5de9c17 Author: Brandon Williams bran...@datastax.com Authored: Thu Jul 17 15:49:35 2014 -0500 Committer: Brandon Williams bran...@datastax.com Committed: Thu Jul 17 15:49:35 2014 -0500 -- --
[05/10] git commit: Merge branch 'cassandra-2.0' into cassandra-2.1.0
Merge branch 'cassandra-2.0' into cassandra-2.1.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/5de9c17d Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/5de9c17d Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/5de9c17d Branch: refs/heads/cassandra-2.1 Commit: 5de9c17dd57dbf2877a9878b0dd13d32868ce629 Parents: 9c1782d 062addb Author: Brandon Williams bran...@datastax.com Authored: Thu Jul 17 15:49:12 2014 -0500 Committer: Brandon Williams bran...@datastax.com Committed: Thu Jul 17 15:49:12 2014 -0500 -- --
[10/10] git commit: Merge branch 'cassandra-2.1' into trunk
Merge branch 'cassandra-2.1' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/c996a36d Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/c996a36d Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/c996a36d Branch: refs/heads/trunk Commit: c996a36d7a1528e33c3dd80d9e6af8248dbd4eb9 Parents: d087133 f873a32 Author: Brandon Williams bran...@datastax.com Authored: Thu Jul 17 15:49:44 2014 -0500 Committer: Brandon Williams bran...@datastax.com Committed: Thu Jul 17 15:49:44 2014 -0500 -- --
[02/10] git commit: fix setlogginglevel help in nodetool
fix setlogginglevel help in nodetool Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/062addb4 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/062addb4 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/062addb4 Branch: refs/heads/cassandra-2.1.0 Commit: 062addb4c5f1131de7f092ff04df12e75880c786 Parents: 93c2754 Author: Brandon Williams bran...@datastax.com Authored: Thu Jul 17 15:49:01 2014 -0500 Committer: Brandon Williams bran...@datastax.com Committed: Thu Jul 17 15:49:01 2014 -0500 -- src/resources/org/apache/cassandra/tools/NodeToolHelp.yaml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/062addb4/src/resources/org/apache/cassandra/tools/NodeToolHelp.yaml -- diff --git a/src/resources/org/apache/cassandra/tools/NodeToolHelp.yaml b/src/resources/org/apache/cassandra/tools/NodeToolHelp.yaml index 8b0185e..6467330 100644 --- a/src/resources/org/apache/cassandra/tools/NodeToolHelp.yaml +++ b/src/resources/org/apache/cassandra/tools/NodeToolHelp.yaml @@ -220,9 +220,9 @@ commands: - name: reloadtriggers help: | reload trigger classes - - name: setLoggingLevel + - name: setlogginglevel class level help: | - Set a log level for a given logger. If both classQualifer and level are empty/null, it will reset to the initial configuration - - name: getLoggingLevels + Set the log level threshold for a given class. If both class and level are empty/null, it will reset to the initial configuration + - name: getlogginglevels help: | Get the runtime logging levels
[09/10] git commit: Merge branch 'cassandra-2.1.0' into cassandra-2.1
Merge branch 'cassandra-2.1.0' into cassandra-2.1 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/f873a327 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f873a327 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f873a327 Branch: refs/heads/cassandra-2.1 Commit: f873a3278603135c494713136cea4e343b0e765f Parents: 3d0e54e 5de9c17 Author: Brandon Williams bran...@datastax.com Authored: Thu Jul 17 15:49:35 2014 -0500 Committer: Brandon Williams bran...@datastax.com Committed: Thu Jul 17 15:49:35 2014 -0500 -- --
[5/6] git commit: fix build on os x
fix build on os x
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/5dfee585
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/5dfee585
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/5dfee585
Branch: refs/heads/cassandra-2.1
Commit: 5dfee585dd08c70542a33acdaf55acd5adbc7a05
Parents: 14151a4
Author: Jonathan Ellis jbel...@apache.org
Authored: Fri Jun 27 14:04:55 2014 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Thu Jul 17 15:57:30 2014 -0500
--
build.xml | 12
1 file changed, 8 insertions(+), 4 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/5dfee585/build.xml
--
diff --git a/build.xml b/build.xml
index c1302eb..40dfbf6 100644
--- a/build.xml
+++ b/build.xml
@@ -688,13 +688,17 @@
name=build-project
echo message=${ant.project.name}: ${ant.file}/
!-- Order matters! --
-javac debug=true debuglevel=${debuglevel}
- destdir=${build.classes.thrift} includeantruntime=false
source=${source.version} target=${target.version}
+javac fork=true
+ debug=true debuglevel=${debuglevel}
+ destdir=${build.classes.thrift} includeantruntime=false
source=${source.version} target=${target.version}
+ memorymaximumsize=512M
src path=${interface.thrift.dir}/gen-java/
classpath refid=cassandra.classpath/
/javac
-javac debug=true debuglevel=${debuglevel}
- destdir=${build.classes.main} includeantruntime=false
source=${source.version} target=${target.version}
+javac fork=true
+ debug=true debuglevel=${debuglevel}
+ destdir=${build.classes.main} includeantruntime=false
source=${source.version} target=${target.version}
+ memorymaximumsize=512M
src path=${build.src.java}/
src path=${build.src.gen-java}/
classpath refid=cassandra.classpath/
[3/6] git commit: Merge branch 'cassandra-2.1' into trunk
Merge branch 'cassandra-2.1' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/82d81992 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/82d81992 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/82d81992 Branch: refs/heads/trunk Commit: 82d819920af6d21e68315109f56f0c1a3682838b Parents: c996a36 14151a4 Author: Jonathan Ellis jbel...@apache.org Authored: Thu Jul 17 15:57:08 2014 -0500 Committer: Jonathan Ellis jbel...@apache.org Committed: Thu Jul 17 15:57:08 2014 -0500 -- bin/cqlsh | 46 +- 1 file changed, 33 insertions(+), 13 deletions(-) --
[2/6] git commit: colorize PK + clustering differently patch by Mihai Seteu; reviewed by Robert Stupp for CASSANDRA-6910
colorize PK + clustering differently
patch by Mihai Seteu; reviewed by Robert Stupp for CASSANDRA-6910
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/14151a40
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/14151a40
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/14151a40
Branch: refs/heads/trunk
Commit: 14151a40b110ef59ce2aa8acb991b8f4ae7a1f9a
Parents: f873a32
Author: Jonathan Ellis jbel...@apache.org
Authored: Thu Jul 17 15:56:36 2014 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Thu Jul 17 15:57:01 2014 -0500
--
bin/cqlsh | 46 +-
1 file changed, 33 insertions(+), 13 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/14151a40/bin/cqlsh
--
diff --git a/bin/cqlsh b/bin/cqlsh
index 44756e2..c8ef874 100755
--- a/bin/cqlsh
+++ b/bin/cqlsh
@@ -119,7 +119,7 @@ if os.path.isdir(cqlshlibdir):
sys.path.insert(0, cqlshlibdir)
from cqlshlib import cqlhandling, cql3handling, pylexotron, sslhandling
-from cqlshlib.displaying import (RED, BLUE, ANSI_RESET, COLUMN_NAME_COLORS,
+from cqlshlib.displaying import (RED, BLUE, CYAN, ANSI_RESET,
COLUMN_NAME_COLORS,
FormattedValue, colorme)
from cqlshlib.formatting import format_by_type, formatter_for,
format_value_utype
from cqlshlib.util import trim_if_present
@@ -583,8 +583,14 @@ class Shell(cmd.Cmd):
self.decoding_errors.append(err)
return format_value(err, self.output_codec.name,
addcolor=self.color)
-def myformat_colname(self, name):
-return self.myformat_value(name, colormap=COLUMN_NAME_COLORS)
+def myformat_colname(self, name, cfMetaData):
+column_colors = COLUMN_NAME_COLORS.copy()
+# check column role and color appropriately
+if name in [col.name for col in cfMetaData.partition_key]:
+column_colors.default_factory = lambda : RED
+elif name in [col.name for col in cfMetaData.clustering_key]:
+column_colors.default_factory = lambda : CYAN
+return self.myformat_value(name, colormap=column_colors)
def report_connection(self):
self.show_host()
@@ -910,7 +916,11 @@ class Shell(cmd.Cmd):
return False
if statement.query_string[:6].lower() == 'select' or
statement.query_string.lower().startswith(list):
-self.print_result(rows, with_default_limit)
+parsed = cqlruleset.cql_parse(statement.query_string)[1]
+ks = self.cql_unprotect_name(parsed.get_binding('ksname', None))
+cf = self.cql_unprotect_name(parsed.get_binding('cfname'))
+cfMetaData = self.get_table_meta(ks, cf)
+self.print_result(rows, with_default_limit, cfMetaData)
elif rows:
# CAS INSERT/UPDATE
self.writeresult()
@@ -918,12 +928,12 @@ class Shell(cmd.Cmd):
self.flush_output()
return True
-def print_result(self, rows, with_default_limit):
+def print_result(self, rows, with_default_limit, cfMetaData):
self.decoding_errors = []
self.writeresult()
-if rows :
-self.print_static_result(rows)
+self.print_static_result(rows, cfMetaData)
+
self.writeresult((%d rows) % len(rows))
self.writeresult()
@@ -941,12 +951,16 @@ class Shell(cmd.Cmd):
% DEFAULT_SELECT_LIMIT, color=RED)
self.writeresult()
-
-def print_static_result(self, rows):
+def print_static_result(self, rows, cfMetaData):
if not rows:
+# print header only
+colnames = cfMetaData.columns.keys() # full header
+formatted_names = [self.myformat_colname(name, cfMetaData) for
name in colnames]
+self.print_formatted_result(formatted_names, None)
return
+
colnames = rows[0]._fields
-formatted_names = [self.myformat_colname(name) for name in colnames]
+formatted_names = [self.myformat_colname(name, cfMetaData) for name in
colnames]
formatted_values = [map(self.myformat_value, row) for row in rows]
if self.expand_enabled:
self.print_formatted_result_vertically(formatted_names,
formatted_values)
@@ -956,15 +970,21 @@ class Shell(cmd.Cmd):
def print_formatted_result(self, formatted_names, formatted_values):
# determine column widths
widths = [n.displaywidth for n in formatted_names]
-for fmtrow in formatted_values:
-for num, col in enumerate(fmtrow):
-widths[num] = max(widths[num], col.displaywidth)
+if formatted_values is not None:
+
[1/6] git commit: colorize PK + clustering differently patch by Mihai Seteu; reviewed by Robert Stupp for CASSANDRA-6910
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.1 f873a3278 - 5dfee585d
refs/heads/trunk c996a36d7 - db70f5a3f
colorize PK + clustering differently
patch by Mihai Seteu; reviewed by Robert Stupp for CASSANDRA-6910
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/14151a40
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/14151a40
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/14151a40
Branch: refs/heads/cassandra-2.1
Commit: 14151a40b110ef59ce2aa8acb991b8f4ae7a1f9a
Parents: f873a32
Author: Jonathan Ellis jbel...@apache.org
Authored: Thu Jul 17 15:56:36 2014 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Thu Jul 17 15:57:01 2014 -0500
--
bin/cqlsh | 46 +-
1 file changed, 33 insertions(+), 13 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/14151a40/bin/cqlsh
--
diff --git a/bin/cqlsh b/bin/cqlsh
index 44756e2..c8ef874 100755
--- a/bin/cqlsh
+++ b/bin/cqlsh
@@ -119,7 +119,7 @@ if os.path.isdir(cqlshlibdir):
sys.path.insert(0, cqlshlibdir)
from cqlshlib import cqlhandling, cql3handling, pylexotron, sslhandling
-from cqlshlib.displaying import (RED, BLUE, ANSI_RESET, COLUMN_NAME_COLORS,
+from cqlshlib.displaying import (RED, BLUE, CYAN, ANSI_RESET,
COLUMN_NAME_COLORS,
FormattedValue, colorme)
from cqlshlib.formatting import format_by_type, formatter_for,
format_value_utype
from cqlshlib.util import trim_if_present
@@ -583,8 +583,14 @@ class Shell(cmd.Cmd):
self.decoding_errors.append(err)
return format_value(err, self.output_codec.name,
addcolor=self.color)
-def myformat_colname(self, name):
-return self.myformat_value(name, colormap=COLUMN_NAME_COLORS)
+def myformat_colname(self, name, cfMetaData):
+column_colors = COLUMN_NAME_COLORS.copy()
+# check column role and color appropriately
+if name in [col.name for col in cfMetaData.partition_key]:
+column_colors.default_factory = lambda : RED
+elif name in [col.name for col in cfMetaData.clustering_key]:
+column_colors.default_factory = lambda : CYAN
+return self.myformat_value(name, colormap=column_colors)
def report_connection(self):
self.show_host()
@@ -910,7 +916,11 @@ class Shell(cmd.Cmd):
return False
if statement.query_string[:6].lower() == 'select' or
statement.query_string.lower().startswith(list):
-self.print_result(rows, with_default_limit)
+parsed = cqlruleset.cql_parse(statement.query_string)[1]
+ks = self.cql_unprotect_name(parsed.get_binding('ksname', None))
+cf = self.cql_unprotect_name(parsed.get_binding('cfname'))
+cfMetaData = self.get_table_meta(ks, cf)
+self.print_result(rows, with_default_limit, cfMetaData)
elif rows:
# CAS INSERT/UPDATE
self.writeresult()
@@ -918,12 +928,12 @@ class Shell(cmd.Cmd):
self.flush_output()
return True
-def print_result(self, rows, with_default_limit):
+def print_result(self, rows, with_default_limit, cfMetaData):
self.decoding_errors = []
self.writeresult()
-if rows :
-self.print_static_result(rows)
+self.print_static_result(rows, cfMetaData)
+
self.writeresult((%d rows) % len(rows))
self.writeresult()
@@ -941,12 +951,16 @@ class Shell(cmd.Cmd):
% DEFAULT_SELECT_LIMIT, color=RED)
self.writeresult()
-
-def print_static_result(self, rows):
+def print_static_result(self, rows, cfMetaData):
if not rows:
+# print header only
+colnames = cfMetaData.columns.keys() # full header
+formatted_names = [self.myformat_colname(name, cfMetaData) for
name in colnames]
+self.print_formatted_result(formatted_names, None)
return
+
colnames = rows[0]._fields
-formatted_names = [self.myformat_colname(name) for name in colnames]
+formatted_names = [self.myformat_colname(name, cfMetaData) for name in
colnames]
formatted_values = [map(self.myformat_value, row) for row in rows]
if self.expand_enabled:
self.print_formatted_result_vertically(formatted_names,
formatted_values)
@@ -956,15 +970,21 @@ class Shell(cmd.Cmd):
def print_formatted_result(self, formatted_names, formatted_values):
# determine column widths
widths = [n.displaywidth for n in formatted_names]
-for fmtrow in formatted_values:
-for num, col
[4/6] git commit: fix build on os x
fix build on os x
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/5dfee585
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/5dfee585
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/5dfee585
Branch: refs/heads/trunk
Commit: 5dfee585dd08c70542a33acdaf55acd5adbc7a05
Parents: 14151a4
Author: Jonathan Ellis jbel...@apache.org
Authored: Fri Jun 27 14:04:55 2014 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Thu Jul 17 15:57:30 2014 -0500
--
build.xml | 12
1 file changed, 8 insertions(+), 4 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/5dfee585/build.xml
--
diff --git a/build.xml b/build.xml
index c1302eb..40dfbf6 100644
--- a/build.xml
+++ b/build.xml
@@ -688,13 +688,17 @@
name=build-project
echo message=${ant.project.name}: ${ant.file}/
!-- Order matters! --
-javac debug=true debuglevel=${debuglevel}
- destdir=${build.classes.thrift} includeantruntime=false
source=${source.version} target=${target.version}
+javac fork=true
+ debug=true debuglevel=${debuglevel}
+ destdir=${build.classes.thrift} includeantruntime=false
source=${source.version} target=${target.version}
+ memorymaximumsize=512M
src path=${interface.thrift.dir}/gen-java/
classpath refid=cassandra.classpath/
/javac
-javac debug=true debuglevel=${debuglevel}
- destdir=${build.classes.main} includeantruntime=false
source=${source.version} target=${target.version}
+javac fork=true
+ debug=true debuglevel=${debuglevel}
+ destdir=${build.classes.main} includeantruntime=false
source=${source.version} target=${target.version}
+ memorymaximumsize=512M
src path=${build.src.java}/
src path=${build.src.gen-java}/
classpath refid=cassandra.classpath/
[6/6] git commit: Merge branch 'cassandra-2.1' into trunk
Merge branch 'cassandra-2.1' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/db70f5a3 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/db70f5a3 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/db70f5a3 Branch: refs/heads/trunk Commit: db70f5a3fb81f662ac81f36612589d8b42632953 Parents: 82d8199 5dfee58 Author: Jonathan Ellis jbel...@apache.org Authored: Thu Jul 17 15:57:43 2014 -0500 Committer: Jonathan Ellis jbel...@apache.org Committed: Thu Jul 17 15:57:43 2014 -0500 -- --
git commit: fix setlogginglevel help in nodetool
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.1.0 5de9c17dd - 43c2c169b
fix setlogginglevel help in nodetool
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/43c2c169
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/43c2c169
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/43c2c169
Branch: refs/heads/cassandra-2.1.0
Commit: 43c2c169b7bd8f6d5ec16557532c34f3ebcc995a
Parents: 5de9c17
Author: Brandon Williams bran...@datastax.com
Authored: Thu Jul 17 15:59:05 2014 -0500
Committer: Brandon Williams bran...@datastax.com
Committed: Thu Jul 17 15:59:05 2014 -0500
--
src/java/org/apache/cassandra/tools/NodeTool.java | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/43c2c169/src/java/org/apache/cassandra/tools/NodeTool.java
--
diff --git a/src/java/org/apache/cassandra/tools/NodeTool.java
b/src/java/org/apache/cassandra/tools/NodeTool.java
index 20f2032..3ec0df3 100644
--- a/src/java/org/apache/cassandra/tools/NodeTool.java
+++ b/src/java/org/apache/cassandra/tools/NodeTool.java
@@ -2299,10 +2299,10 @@ public class NodeTool
}
}
-@Command(name = setlogginglevel, description = Set a log level for a
given logger. If both classQualifer and level are empty/null, it will reset
based on the initial configuration)
+@Command(name = setlogginglevel, description = Set the log level
threshold for a given class. If both class and level are empty/null, it will
reset to the initial configuration)
public static class SetLoggingLevel extends NodeToolCmd
{
-@Arguments(usage = classQualifer level, description = The
logger classQualifer and the logger level (can be empty))
+@Arguments(usage = class level, description = The class to
change the level for and the log level threshold to set (can be empty))
private ListString args = new ArrayList();
@Override
[5/7] git commit: Merge branch 'cassandra-2.1' into trunk
Merge branch 'cassandra-2.1' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/4831bf41 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/4831bf41 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/4831bf41 Branch: refs/heads/trunk Commit: 4831bf41e011c419328a9dd7d7809512e819983a Parents: c996a36 7a1edab Author: Brandon Williams bran...@datastax.com Authored: Thu Jul 17 15:59:21 2014 -0500 Committer: Brandon Williams bran...@datastax.com Committed: Thu Jul 17 15:59:21 2014 -0500 -- src/java/org/apache/cassandra/tools/NodeTool.java | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/4831bf41/src/java/org/apache/cassandra/tools/NodeTool.java --
[2/7] git commit: fix setlogginglevel help in nodetool
fix setlogginglevel help in nodetool
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/43c2c169
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/43c2c169
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/43c2c169
Branch: refs/heads/trunk
Commit: 43c2c169b7bd8f6d5ec16557532c34f3ebcc995a
Parents: 5de9c17
Author: Brandon Williams bran...@datastax.com
Authored: Thu Jul 17 15:59:05 2014 -0500
Committer: Brandon Williams bran...@datastax.com
Committed: Thu Jul 17 15:59:05 2014 -0500
--
src/java/org/apache/cassandra/tools/NodeTool.java | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/43c2c169/src/java/org/apache/cassandra/tools/NodeTool.java
--
diff --git a/src/java/org/apache/cassandra/tools/NodeTool.java
b/src/java/org/apache/cassandra/tools/NodeTool.java
index 20f2032..3ec0df3 100644
--- a/src/java/org/apache/cassandra/tools/NodeTool.java
+++ b/src/java/org/apache/cassandra/tools/NodeTool.java
@@ -2299,10 +2299,10 @@ public class NodeTool
}
}
-@Command(name = setlogginglevel, description = Set a log level for a
given logger. If both classQualifer and level are empty/null, it will reset
based on the initial configuration)
+@Command(name = setlogginglevel, description = Set the log level
threshold for a given class. If both class and level are empty/null, it will
reset to the initial configuration)
public static class SetLoggingLevel extends NodeToolCmd
{
-@Arguments(usage = classQualifer level, description = The
logger classQualifer and the logger level (can be empty))
+@Arguments(usage = class level, description = The class to
change the level for and the log level threshold to set (can be empty))
private ListString args = new ArrayList();
@Override
[7/7] git commit: Merge branch 'trunk'
Merge branch 'trunk' Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ddc0f66d Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ddc0f66d Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ddc0f66d Branch: refs/heads/trunk Commit: ddc0f66d97afc263918f70601b77d82301679e36 Parents: 4831bf4 db70f5a Author: Brandon Williams bran...@datastax.com Authored: Thu Jul 17 16:00:12 2014 -0500 Committer: Brandon Williams bran...@datastax.com Committed: Thu Jul 17 16:00:12 2014 -0500 -- bin/cqlsh | 46 +- 1 file changed, 33 insertions(+), 13 deletions(-) --
[1/7] git commit: fix setlogginglevel help in nodetool
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.1 5dfee585d - e5625fcad
refs/heads/trunk db70f5a3f - ddc0f66d9
fix setlogginglevel help in nodetool
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/43c2c169
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/43c2c169
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/43c2c169
Branch: refs/heads/cassandra-2.1
Commit: 43c2c169b7bd8f6d5ec16557532c34f3ebcc995a
Parents: 5de9c17
Author: Brandon Williams bran...@datastax.com
Authored: Thu Jul 17 15:59:05 2014 -0500
Committer: Brandon Williams bran...@datastax.com
Committed: Thu Jul 17 15:59:05 2014 -0500
--
src/java/org/apache/cassandra/tools/NodeTool.java | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/43c2c169/src/java/org/apache/cassandra/tools/NodeTool.java
--
diff --git a/src/java/org/apache/cassandra/tools/NodeTool.java
b/src/java/org/apache/cassandra/tools/NodeTool.java
index 20f2032..3ec0df3 100644
--- a/src/java/org/apache/cassandra/tools/NodeTool.java
+++ b/src/java/org/apache/cassandra/tools/NodeTool.java
@@ -2299,10 +2299,10 @@ public class NodeTool
}
}
-@Command(name = setlogginglevel, description = Set a log level for a
given logger. If both classQualifer and level are empty/null, it will reset
based on the initial configuration)
+@Command(name = setlogginglevel, description = Set the log level
threshold for a given class. If both class and level are empty/null, it will
reset to the initial configuration)
public static class SetLoggingLevel extends NodeToolCmd
{
-@Arguments(usage = classQualifer level, description = The
logger classQualifer and the logger level (can be empty))
+@Arguments(usage = class level, description = The class to
change the level for and the log level threshold to set (can be empty))
private ListString args = new ArrayList();
@Override
[3/7] git commit: Merge branch 'cassandra-2.1.0' into cassandra-2.1
Merge branch 'cassandra-2.1.0' into cassandra-2.1 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/7a1edabd Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/7a1edabd Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/7a1edabd Branch: refs/heads/trunk Commit: 7a1edabd927e960ce4b2add88cc2ade2ba45d08e Parents: f873a32 43c2c16 Author: Brandon Williams bran...@datastax.com Authored: Thu Jul 17 15:59:13 2014 -0500 Committer: Brandon Williams bran...@datastax.com Committed: Thu Jul 17 15:59:13 2014 -0500 -- src/java/org/apache/cassandra/tools/NodeTool.java | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --
[4/7] git commit: Merge branch 'cassandra-2.1.0' into cassandra-2.1
Merge branch 'cassandra-2.1.0' into cassandra-2.1 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/7a1edabd Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/7a1edabd Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/7a1edabd Branch: refs/heads/cassandra-2.1 Commit: 7a1edabd927e960ce4b2add88cc2ade2ba45d08e Parents: f873a32 43c2c16 Author: Brandon Williams bran...@datastax.com Authored: Thu Jul 17 15:59:13 2014 -0500 Committer: Brandon Williams bran...@datastax.com Committed: Thu Jul 17 15:59:13 2014 -0500 -- src/java/org/apache/cassandra/tools/NodeTool.java | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --
[6/7] git commit: Merge branch 'cassandra-2.1'
Merge branch 'cassandra-2.1' Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e5625fca Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e5625fca Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e5625fca Branch: refs/heads/cassandra-2.1 Commit: e5625fcad96fa9decef927937e70c2ec39dc96d7 Parents: 7a1edab 5dfee58 Author: Brandon Williams bran...@datastax.com Authored: Thu Jul 17 15:59:49 2014 -0500 Committer: Brandon Williams bran...@datastax.com Committed: Thu Jul 17 15:59:49 2014 -0500 -- bin/cqlsh | 46 +- build.xml | 12 2 files changed, 41 insertions(+), 17 deletions(-) --
[jira] [Commented] (CASSANDRA-7443) SSTable Pluggability v2
[ https://issues.apache.org/jira/browse/CASSANDRA-7443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14065591#comment-14065591 ] T Jake Luciani commented on CASSANDRA-7443: --- I've posted my work so far here https://github.com/tjake/cassandra/tree/7443-plugsstable In general it is still pretty rough and I need to clean up more but, the idea is formats would still require BloomFilter, Index and Data components. Beyond that the data can be laid out however you want. The readers now provide the OnDiskAtomIterator along with the ICompactionScanner so a format writer has total control over those. But the rest of the APIs are left intact. I don't want to go too deep in this ticket since we should get this kind of change into the codebase then iterate more vs a big bang, but this should be enough to get started writing the new format. The approach I took was the following: * There is a system level setting to pick the default format the system will use to write files. * Added a format component to the file Descriptor class. If missing it will use the existing legact format by default. * Added a SSTableFormat class that defines the SSTableReader and SSTableWriter implementations as well as the features of the format (like hasNewStatsFile etc that used to be contained in the Descriptor class directly). We can extend to toggle on different code paths while keeping the old logic intact. * There is a pre-defined list of formats we support (currently only the existing format, I'm calling it BIG since its Big literally and BigTable) * Re-wired the Reader and Writer creators so the classes are constructed based on the SSTableFormat information in the Descriptor * Abstracted the Writer api (See SSTableWriter) * Abstracted the Reader api (See SSTableReader) * Moved the current Format files to be prefixed with Big under the o.a.c.db.sstable.format.big namespace * Moved the iterators and scanners to be fetched only from the SStablereader API. All the test pass and I added code around the Streaming so it will Error if you try to stream a non legacy sstable to an old version node. As for next steps, I want to build a very differently implemented TEST format to make sure all the paths are covered and all the tests still pass. SSTable Pluggability v2 --- Key: CASSANDRA-7443 URL: https://issues.apache.org/jira/browse/CASSANDRA-7443 Project: Cassandra Issue Type: Improvement Components: Core Reporter: T Jake Luciani Assignee: T Jake Luciani Fix For: 3.0 As part of a wider effort to improve the performance of our storage engine we will need to support basic pluggability of the SSTable reader/writer. We primarily need this to support the current SSTable format and new SSTable format in the same version. This will also let us encapsulate the changes in a single layer vs forcing the whole engine to change at once. We previously discussed how to accomplish this in CASSANDRA-3067 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7566) DROP TABLE should also drop prepared statements associated to
[ https://issues.apache.org/jira/browse/CASSANDRA-7566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-7566: -- Labels: cql3 (was: ) Summary: DROP TABLE should also drop prepared statements associated to (was: DROP/CREATE TABLE cycle causes unrecognized column family) Updated summary to reflect the problem. DROP TABLE should also drop prepared statements associated to - Key: CASSANDRA-7566 URL: https://issues.apache.org/jira/browse/CASSANDRA-7566 Project: Cassandra Issue Type: Bug Components: Core Environment: OSX 10.9.4 / JDK 1.8.0_05 Reporter: Ben Hood Assignee: Yuki Morishita Labels: cql3 An integration test suite that drops and creates the same column family 3 times causes the following error in the server log: INFO 15:40:34 Initializing gocql_test.wiki_page ERROR 15:40:34 Attempted to write commit log entry for unrecognized column family: b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempting to mutate non-existant column family b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempted to write commit log entry for unrecognized column family: b0e167e0-0dc8-11e4-9cbb-29a4872887f2 ERROR 15:40:34 Attempting to mutate non-existant column family b0e167e0-0dc8-11e4-9cbb-29a4872887f2 The test that reproduces this issue is here: https://github.com/gocql/gocql/blob/master/wiki_test.go Interestingly this issue only occurs after the common table is dropped/created for the 3rd time. If only one of the tests is run on its own, this issue does not arise. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-6910) Better table structure display in cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-6910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14065636#comment-14065636 ] Jonathan Ellis commented on CASSANDRA-6910: --- committed. thanks, Mihai and Robert! Better table structure display in cqlsh --- Key: CASSANDRA-6910 URL: https://issues.apache.org/jira/browse/CASSANDRA-6910 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Tupshin Harper Assignee: Mihai Suteu Priority: Minor Labels: lhf Fix For: 2.1.1 Attachments: 6910.txt, cassandra6910.patch, screenshot-mihai.jpg It should be possible to make it more immediately obvious what the structure of your CQL table is from cqlsh. Two minor enhancements could go a long way: 1) If there are no results display the column headers anyway. Right now, if you are trying to do a query and get no results, it's common to need to display the table schema to figure out what you did wrong. Having the columns displayed whenever you do a query wouldn't get in the way, and would provide a more visual way than by describing the table. 2) Along with the first one, if we could highlight the partition/clustering columns in different colors, it would be much more intuitively understandable what the underlying partition structure is. tl;dr: the forms below should each have distinct visual representation when displaying the column headers, and the column headers should always be shown. CREATE TABLE usertest ( userid text, email text, name text, PRIMARY KEY (userid) ) CREATE TABLE usertest2 ( userid text, email text, name text, PRIMARY KEY (userid, email) ) CREATE TABLE usertest3 ( userid text, email text, name text, PRIMARY KEY ((userid, email)) ) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-5345) Potential problem with GarbageCollectorMXBean
[
https://issues.apache.org/jira/browse/CASSANDRA-5345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-5345:
--
Priority: Minor (was: Major)
Fix Version/s: 2.0.10
Potential problem with GarbageCollectorMXBean
-
Key: CASSANDRA-5345
URL: https://issues.apache.org/jira/browse/CASSANDRA-5345
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.7
Environment: JVM:JVM vendor/version: Java HotSpot(TM) 64-Bit Server
VM/1.6.0_30 typical 6 node 2 availability zone Mutli DC cluster on linux vms
with
and mx4j-tools.jar and jna.jar both on path. Default configuration bar token
setup(equispaced), sensible cassandra-topology.properties file and use of
said snitch.
Reporter: Matt Byrd
Assignee: Joshua McKenzie
Priority: Minor
Fix For: 2.0.10
Attachments: 5345_v1.txt
I am not certain this is definitely a bug, but I thought it might be worth
posting to see if someone with more JVM//JMX knowledge could disprove my
reasoning. Apologies if I've failed to understand something.
We've seen an intermittent problem where there is an uncaught exception in
the scheduled task of logging gc results in GcInspector.java:
{code}
...
ERROR [ScheduledTasks:1] 2013-03-08 01:09:06,335
AbstractCassandraDaemon.java (line 139) Fatal exception in thread
Thread[ScheduledTasks:1,5,main]
java.lang.reflect.UndeclaredThrowableException
at $Proxy0.getName(Unknown Source)
at
org.apache.cassandra.service.GCInspector.logGCResults(GCInspector.java:95)
at
org.apache.cassandra.service.GCInspector.access$000(GCInspector.java:41)
at org.apache.cassandra.service.GCInspector$1.run(GCInspector.java:85)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at
java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.management.InstanceNotFoundException:
java.lang:name=ParNew,type=GarbageCollector
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1094)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:662)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:638)
at
com.sun.jmx.mbeanserver.MXBeanProxy$GetHandler.invoke(MXBeanProxy.java:106)
at com.sun.jmx.mbeanserver.MXBeanProxy.invoke(MXBeanProxy.java:148)
at
javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:248)
... 13 more
...
{code}
I think the problem, may be caused by the following reasoning:
In GcInspector we populate a list of mxbeans when the GcInspector instance is
instantiated:
{code}
...
ListGarbageCollectorMXBean beans = new ArrayListGarbageCollectorMXBean();
MBeanServer server = ManagementFactory.getPlatformMBeanServer();
try
{
ObjectName gcName = new
ObjectName(ManagementFactory.GARBAGE_COLLECTOR_MXBEAN_DOMAIN_TYPE + ,*);
for (ObjectName name : server.queryNames(gcName, null))
{
GarbageCollectorMXBean gc =
ManagementFactory.newPlatformMXBeanProxy(server, name.getCanonicalName(),
GarbageCollectorMXBean.class);
beans.add(gc);
}
}
catch (Exception e)
{
throw new RuntimeException(e);
}
...
{code}
Cassandra then periodically calls:
{code}
...
private void logGCResults()
{
for (GarbageCollectorMXBean gc : beans)
{
Long previousTotal = gctimes.get(gc.getName());
...
{code}
In the oracle javadocs, they seem to suggest that these beans could disappear
at any time.(I'm not sure why when or how this might happen)
http://docs.oracle.com/javase/6/docs/api/
See: getGarbageCollectorMXBeans
{code}
...
public static ListGarbageCollectorMXBean getGarbageCollectorMXBeans()
Returns a list of
[jira] [Commented] (CASSANDRA-5345) Potential problem with GarbageCollectorMXBean
[
https://issues.apache.org/jira/browse/CASSANDRA-5345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14065643#comment-14065643
]
Jonathan Ellis commented on CASSANDRA-5345:
---
I couldn't get this to apply to the repo as of Jun 26. Can you rebase against
current 2.0 branch?
Potential problem with GarbageCollectorMXBean
-
Key: CASSANDRA-5345
URL: https://issues.apache.org/jira/browse/CASSANDRA-5345
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.7
Environment: JVM:JVM vendor/version: Java HotSpot(TM) 64-Bit Server
VM/1.6.0_30 typical 6 node 2 availability zone Mutli DC cluster on linux vms
with
and mx4j-tools.jar and jna.jar both on path. Default configuration bar token
setup(equispaced), sensible cassandra-topology.properties file and use of
said snitch.
Reporter: Matt Byrd
Assignee: Joshua McKenzie
Priority: Minor
Fix For: 2.0.10
Attachments: 5345_v1.txt
I am not certain this is definitely a bug, but I thought it might be worth
posting to see if someone with more JVM//JMX knowledge could disprove my
reasoning. Apologies if I've failed to understand something.
We've seen an intermittent problem where there is an uncaught exception in
the scheduled task of logging gc results in GcInspector.java:
{code}
...
ERROR [ScheduledTasks:1] 2013-03-08 01:09:06,335
AbstractCassandraDaemon.java (line 139) Fatal exception in thread
Thread[ScheduledTasks:1,5,main]
java.lang.reflect.UndeclaredThrowableException
at $Proxy0.getName(Unknown Source)
at
org.apache.cassandra.service.GCInspector.logGCResults(GCInspector.java:95)
at
org.apache.cassandra.service.GCInspector.access$000(GCInspector.java:41)
at org.apache.cassandra.service.GCInspector$1.run(GCInspector.java:85)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at
java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.management.InstanceNotFoundException:
java.lang:name=ParNew,type=GarbageCollector
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1094)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:662)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:638)
at
com.sun.jmx.mbeanserver.MXBeanProxy$GetHandler.invoke(MXBeanProxy.java:106)
at com.sun.jmx.mbeanserver.MXBeanProxy.invoke(MXBeanProxy.java:148)
at
javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:248)
... 13 more
...
{code}
I think the problem, may be caused by the following reasoning:
In GcInspector we populate a list of mxbeans when the GcInspector instance is
instantiated:
{code}
...
ListGarbageCollectorMXBean beans = new ArrayListGarbageCollectorMXBean();
MBeanServer server = ManagementFactory.getPlatformMBeanServer();
try
{
ObjectName gcName = new
ObjectName(ManagementFactory.GARBAGE_COLLECTOR_MXBEAN_DOMAIN_TYPE + ,*);
for (ObjectName name : server.queryNames(gcName, null))
{
GarbageCollectorMXBean gc =
ManagementFactory.newPlatformMXBeanProxy(server, name.getCanonicalName(),
GarbageCollectorMXBean.class);
beans.add(gc);
}
}
catch (Exception e)
{
throw new RuntimeException(e);
}
...
{code}
Cassandra then periodically calls:
{code}
...
private void logGCResults()
{
for (GarbageCollectorMXBean gc : beans)
{
Long previousTotal = gctimes.get(gc.getName());
...
{code}
In the oracle javadocs, they seem to suggest that these beans could disappear
at any time.(I'm not sure why when or how this might happen)
http://docs.oracle.com/javase/6/docs/api/
See: getGarbageCollectorMXBeans
{code}
...
public
[jira] [Updated] (CASSANDRA-6513) CqlPaging for hadoop fails when writetime(column_name) is set as one of the input columns
[ https://issues.apache.org/jira/browse/CASSANDRA-6513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-6513: -- Attachment: 6513-v2.txt I don't think we should be trying to guess what quoting is appropriate at all. v2 to remove the quote() function entirely; let the user quote explicitly instead. CqlPaging for hadoop fails when writetime(column_name) is set as one of the input columns - Key: CASSANDRA-6513 URL: https://issues.apache.org/jira/browse/CASSANDRA-6513 Project: Cassandra Issue Type: Bug Components: Hadoop Environment: ubuntu 12.04, hadoop 1.0.3, cassandra-1.2.13 Reporter: Sheetal Gosrani Assignee: Ala' Alkhaldi Labels: CqlPaging, Hadoop Fix For: 2.0.10 Attachments: 6513-v2.txt, 6513_v1.txt InvalidRequestException thrown when running a hadoop job with CqlPaging with writetime(column_name) set as one of the input columns. java.lang.RuntimeException at org.apache.cassandra.hadoop.cql3.CqlPagingRecordReader$RowIterator.executeQuery(CqlPagingRecordReader.java:665) at org.apache.cassandra.hadoop.cql3.CqlPagingRecordReader$RowIterator.init(CqlPagingRecordReader.java:301) at org.apache.cassandra.hadoop.cql3.CqlPagingRecordReader.initialize(CqlPagingRecordReader.java:167) at org.apache.hadoop.mapred.MapTask$NewTrackingRecordReader.initialize(MapTask.java:522) at org.apache.hadoop.mapred.MapTask.runNewMapper(MapTask.java:763) at org.apache.hadoop.mapred.MapTask.run(MapTask.java:370) at org.apache.hadoop.mapred.Child$4.run(Child.java:255) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:415) at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1121) at org.apache.hadoop.mapred.Child.main(Child.java:249) Caused by: InvalidRequestException(why:Undefined name WRITETIME(foo) in selection clause) at org.apache.cassandra.thrift.Cassandra$prepare_cql3_query_result.read(Cassandra.java:40395) at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:78) at org.apache.cassandra.thrift.Cassandra$Client.recv_prepare_cql3_query(Cassandra.java:1660) at org.apache.cassandra.thrift.Cassandra$Client.prepare_cql3_query(Cassandra.java:1646) at org.apache.cassandra.hadoop.cql3.CqlPagingRecordReader$RowIterator.prepareQuery(CqlPagingRecordReader.java:605) at org.apache.cassandra.hadoop.cql3.CqlPagingRecordReader$RowIterator.executeQuery(CqlPagingRecordReader.java:635) ... 10 more The hadoop config lines look as such: //read input from cassandra column family using CQL Input Format job.setInputFormatClass(CqlPagingInputFormat.class); ConfigHelper.setInputColumnFamily(job.getConfiguration(), KEYSPACE, INPUT_COLUMN_FAMILY); ConfigHelper.setInputRpcPort(job.getConfiguration(), 9160); ConfigHelper.setInputInitialAddress(job.getConfiguration(), HOST); ConfigHelper.setInputPartitioner(job.getConfiguration(), RandomPartitioner); CqlConfigHelper.setInputColumns(job.getConfiguration(), foo,WRITETIME(foo)); job.getConfiguration().set(cassandra.consistencylevel.read, READ_CONSISTENCY); CqlConfigHelper.setInputCQLPageRowSize(job.getConfiguration(), 3000); -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (CASSANDRA-7498) sstable2json exports keys in a wrong format
[ https://issues.apache.org/jira/browse/CASSANDRA-7498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reopened CASSANDRA-7498: --- Reproduced In: 2.1 rc2, 1.2.19 (was: 1.2.19, 2.1 rc2) Sounds reasonable. [~blerer] to review. sstable2json exports keys in a wrong format --- Key: CASSANDRA-7498 URL: https://issues.apache.org/jira/browse/CASSANDRA-7498 Project: Cassandra Issue Type: Bug Components: Tools Reporter: Alexey Zotov Assignee: Alexey Zotov Labels: tools Fix For: 2.1.1 Attachments: CASSANDRA-2.1-7498.txt I examined code of _SSTableImport_ and _SSTableExport_ classes and found one thing that looks strange to me. Currently processing (encoding/decoding) of columns' names and values is performed based on CF Comparator and Value Validator correspondingly. But row keys are processed using _#bytesToHex_ and _#hexToBytes_ methods despite of there is Key Validator. Such approach works properly for bytes keys only. For other types it exports keys in a wrong format (i.e. they are exported in unreadable form). In the scope of this ticket we need to consider backward compatibility (import of previously exported sstables). For bytes keys it will work as previously since _#bytesToHex_ and _#hexToBytes_ methods are used in internals of _BytesType_ class. For other types we need to allow an ability to import data using bytes despite of configured validator. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7498) sstable2json exports keys in a wrong format
[ https://issues.apache.org/jira/browse/CASSANDRA-7498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-7498: -- Reviewer: Benjamin Lerer Component/s: (was: Core) Tools Reproduced In: 2.1 rc2, 1.2.19 (was: 1.2.19, 2.1 rc2) Priority: Minor (was: Major) Fix Version/s: 2.1.1 sstable2json exports keys in a wrong format --- Key: CASSANDRA-7498 URL: https://issues.apache.org/jira/browse/CASSANDRA-7498 Project: Cassandra Issue Type: Bug Components: Tools Reporter: Alexey Zotov Assignee: Alexey Zotov Priority: Minor Labels: tools Fix For: 2.1.1 Attachments: CASSANDRA-2.1-7498.txt I examined code of _SSTableImport_ and _SSTableExport_ classes and found one thing that looks strange to me. Currently processing (encoding/decoding) of columns' names and values is performed based on CF Comparator and Value Validator correspondingly. But row keys are processed using _#bytesToHex_ and _#hexToBytes_ methods despite of there is Key Validator. Such approach works properly for bytes keys only. For other types it exports keys in a wrong format (i.e. they are exported in unreadable form). In the scope of this ticket we need to consider backward compatibility (import of previously exported sstables). For bytes keys it will work as previously since _#bytesToHex_ and _#hexToBytes_ methods are used in internals of _BytesType_ class. For other types we need to allow an ability to import data using bytes despite of configured validator. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7398) Missing flexibility to have file://server/etc vs. file:/// when loading config file cassandra.yaml
[ https://issues.apache.org/jira/browse/CASSANDRA-7398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joshua McKenzie updated CASSANDRA-7398: --- Attachment: 7398_v9.txt Attaching a simple v9 that checks the provided cassandra.config value and gives a more informative error based on whether or not the user has provided a string that conforms to the URI spec. As I've stated previously, I feel pretty strongly that this isn't a place where we need to add a lot of complexity (logic + unit tests) around trying to figure out what the user actually intended to provide. Far simpler (and cleaner) to just educate them on the fact that they need to provide a URI as that param and exit. Missing flexibility to have file://server/etc vs. file:/// when loading config file cassandra.yaml -- Key: CASSANDRA-7398 URL: https://issues.apache.org/jira/browse/CASSANDRA-7398 Project: Cassandra Issue Type: Bug Components: Core Environment: Cassandra 2.1.0-rc1-SNAPSHOT, Win 7 Reporter: Marco Tulio Avila Cerón Assignee: Marco Tulio Avila Cerón Priority: Minor Labels: lhf, patch Fix For: 2.1.1 Attachments: 7398_v9.txt, CASSANDRA-7398_prefix_v2.patch, CASSANDRA-7398_prefix_v3.patch, CASSANDRA-7398_prefix_v4.patch, trunk-7398_v5.txt, trunk-7398_v6.txt, trunk-7398_v7.txt, trunk-7398_v8.txt, trunk-7398_v8_impl.txt, trunk-7398_v8_test.txt Original Estimate: 2h Remaining Estimate: 2h The parameter in the VM options -Dcassandra.config= needs file:/// Allow the user to have optional file:/// when loading the config file from the filesystem -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7567) when the commit_log disk for a single node is overwhelmed the entire cluster slows down
[ https://issues.apache.org/jira/browse/CASSANDRA-7567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14065819#comment-14065819 ] Ryan McGuire commented on CASSANDRA-7567: - I have reproduced this on a 10 node m3.xlarge cluster on EC2. * Run stress against nodes 1-5 * On node 9, run the dd command. * Watch stress completely time out. when the commit_log disk for a single node is overwhelmed the entire cluster slows down --- Key: CASSANDRA-7567 URL: https://issues.apache.org/jira/browse/CASSANDRA-7567 Project: Cassandra Issue Type: Bug Components: Core Environment: debian 7.5, bare metal, 14 nodes, 64CPUs, 64GB RAM, commit_log disk sata, data disk SSD, vnodes, leveled compaction strategy Reporter: David O'Dell Attachments: write_request_latency.png We've run into a situation where a single node out of 14 is experiencing high disk io. This can happen when a node is being decommissioned or after it joins the ring and runs into the bug cassandra-6621. When this occurs the write latency for the entire cluster spikes. From 0.3ms to 170ms. To simulate this simply run dd on the commit_log disk (dd if=/dev/zero of=/tmp/foo bs=1024) and you will see that instantly all nodes in the cluster have slowed down. BTW overwhelming the data disk does not have this same effect. Also I've tried this where the overwhelmed node isn't being connected directly from the client and it still has the same effect. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CASSANDRA-7567) when the commit_log disk for a single node is overwhelmed the entire cluster slows down
[ https://issues.apache.org/jira/browse/CASSANDRA-7567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14065819#comment-14065819 ] Ryan McGuire edited comment on CASSANDRA-7567 at 7/18/14 12:37 AM: --- I have reproduced this on a 10 node m3.xlarge cluster on EC2. * Run stress against nodes 1-5 * On node 9, run the dd command. With RF=1: * Watch stress completely time out. With RF=3: * Observe intermittent 12s latency However, the intermittent latency subsides, which leads me to believe that the cluster is polling that node and backing off progressively as it sees that it's unavailable. was (Author: enigmacurry): I have reproduced this on a 10 node m3.xlarge cluster on EC2. * Run stress against nodes 1-5 * On node 9, run the dd command. * Watch stress completely time out. when the commit_log disk for a single node is overwhelmed the entire cluster slows down --- Key: CASSANDRA-7567 URL: https://issues.apache.org/jira/browse/CASSANDRA-7567 Project: Cassandra Issue Type: Bug Components: Core Environment: debian 7.5, bare metal, 14 nodes, 64CPUs, 64GB RAM, commit_log disk sata, data disk SSD, vnodes, leveled compaction strategy Reporter: David O'Dell Attachments: write_request_latency.png We've run into a situation where a single node out of 14 is experiencing high disk io. This can happen when a node is being decommissioned or after it joins the ring and runs into the bug cassandra-6621. When this occurs the write latency for the entire cluster spikes. From 0.3ms to 170ms. To simulate this simply run dd on the commit_log disk (dd if=/dev/zero of=/tmp/foo bs=1024) and you will see that instantly all nodes in the cluster have slowed down. BTW overwhelming the data disk does not have this same effect. Also I've tried this where the overwhelmed node isn't being connected directly from the client and it still has the same effect. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CASSANDRA-7567) when the commit_log disk for a single node is overwhelmed the entire cluster slows down
[ https://issues.apache.org/jira/browse/CASSANDRA-7567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14065819#comment-14065819 ] Ryan McGuire edited comment on CASSANDRA-7567 at 7/18/14 12:50 AM: --- I have reproduced this on a 10 node m3.xlarge cluster on EC2. * Run stress against nodes 1-5 * On node 9, run the dd command. With RF=1: * Watch stress completely time out. With RF=3: * Observe intermittent 12s latency -However, the intermittent latency subsides, which leads me to believe that the cluster is polling that node and backing off progressively as it sees that it's unavailable.- was (Author: enigmacurry): I have reproduced this on a 10 node m3.xlarge cluster on EC2. * Run stress against nodes 1-5 * On node 9, run the dd command. With RF=1: * Watch stress completely time out. With RF=3: * Observe intermittent 12s latency However, the intermittent latency subsides, which leads me to believe that the cluster is polling that node and backing off progressively as it sees that it's unavailable. when the commit_log disk for a single node is overwhelmed the entire cluster slows down --- Key: CASSANDRA-7567 URL: https://issues.apache.org/jira/browse/CASSANDRA-7567 Project: Cassandra Issue Type: Bug Components: Core Environment: debian 7.5, bare metal, 14 nodes, 64CPUs, 64GB RAM, commit_log disk sata, data disk SSD, vnodes, leveled compaction strategy Reporter: David O'Dell Attachments: 7567.logs.bz2, write_request_latency.png We've run into a situation where a single node out of 14 is experiencing high disk io. This can happen when a node is being decommissioned or after it joins the ring and runs into the bug cassandra-6621. When this occurs the write latency for the entire cluster spikes. From 0.3ms to 170ms. To simulate this simply run dd on the commit_log disk (dd if=/dev/zero of=/tmp/foo bs=1024) and you will see that instantly all nodes in the cluster have slowed down. BTW overwhelming the data disk does not have this same effect. Also I've tried this where the overwhelmed node isn't being connected directly from the client and it still has the same effect. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7567) when the commit_log disk for a single node is overwhelmed the entire cluster slows down
[ https://issues.apache.org/jira/browse/CASSANDRA-7567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McGuire updated CASSANDRA-7567: Attachment: 7567.logs.bz2 when the commit_log disk for a single node is overwhelmed the entire cluster slows down --- Key: CASSANDRA-7567 URL: https://issues.apache.org/jira/browse/CASSANDRA-7567 Project: Cassandra Issue Type: Bug Components: Core Environment: debian 7.5, bare metal, 14 nodes, 64CPUs, 64GB RAM, commit_log disk sata, data disk SSD, vnodes, leveled compaction strategy Reporter: David O'Dell Attachments: 7567.logs.bz2, write_request_latency.png We've run into a situation where a single node out of 14 is experiencing high disk io. This can happen when a node is being decommissioned or after it joins the ring and runs into the bug cassandra-6621. When this occurs the write latency for the entire cluster spikes. From 0.3ms to 170ms. To simulate this simply run dd on the commit_log disk (dd if=/dev/zero of=/tmp/foo bs=1024) and you will see that instantly all nodes in the cluster have slowed down. BTW overwhelming the data disk does not have this same effect. Also I've tried this where the overwhelmed node isn't being connected directly from the client and it still has the same effect. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7567) when the commit_log disk for a single node is overwhelmed the entire cluster slows down
[ https://issues.apache.org/jira/browse/CASSANDRA-7567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14065844#comment-14065844 ] Ryan McGuire commented on CASSANDRA-7567: - Forgive my previous armchair reasoning. It's actually getting progressively worse as it goes along. I'm attaching the logs so other's can analyze this. I introduced the dd command at 60s into the write. when the commit_log disk for a single node is overwhelmed the entire cluster slows down --- Key: CASSANDRA-7567 URL: https://issues.apache.org/jira/browse/CASSANDRA-7567 Project: Cassandra Issue Type: Bug Components: Core Environment: debian 7.5, bare metal, 14 nodes, 64CPUs, 64GB RAM, commit_log disk sata, data disk SSD, vnodes, leveled compaction strategy Reporter: David O'Dell Attachments: 7567.logs.bz2, write_request_latency.png We've run into a situation where a single node out of 14 is experiencing high disk io. This can happen when a node is being decommissioned or after it joins the ring and runs into the bug cassandra-6621. When this occurs the write latency for the entire cluster spikes. From 0.3ms to 170ms. To simulate this simply run dd on the commit_log disk (dd if=/dev/zero of=/tmp/foo bs=1024) and you will see that instantly all nodes in the cluster have slowed down. BTW overwhelming the data disk does not have this same effect. Also I've tried this where the overwhelmed node isn't being connected directly from the client and it still has the same effect. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-7567) when the commit_log disk for a single node is overwhelmed the entire cluster slows down
[ https://issues.apache.org/jira/browse/CASSANDRA-7567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McGuire updated CASSANDRA-7567: Reproduced In: 2.1 rc3 when the commit_log disk for a single node is overwhelmed the entire cluster slows down --- Key: CASSANDRA-7567 URL: https://issues.apache.org/jira/browse/CASSANDRA-7567 Project: Cassandra Issue Type: Bug Components: Core Environment: debian 7.5, bare metal, 14 nodes, 64CPUs, 64GB RAM, commit_log disk sata, data disk SSD, vnodes, leveled compaction strategy Reporter: David O'Dell Attachments: 7567.logs.bz2, write_request_latency.png We've run into a situation where a single node out of 14 is experiencing high disk io. This can happen when a node is being decommissioned or after it joins the ring and runs into the bug cassandra-6621. When this occurs the write latency for the entire cluster spikes. From 0.3ms to 170ms. To simulate this simply run dd on the commit_log disk (dd if=/dev/zero of=/tmp/foo bs=1024) and you will see that instantly all nodes in the cluster have slowed down. BTW overwhelming the data disk does not have this same effect. Also I've tried this where the overwhelmed node isn't being connected directly from the client and it still has the same effect. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CASSANDRA-7567) when the commit_log disk for a single node is overwhelmed the entire cluster slows down
[ https://issues.apache.org/jira/browse/CASSANDRA-7567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McGuire reassigned CASSANDRA-7567: --- Assignee: Ryan McGuire when the commit_log disk for a single node is overwhelmed the entire cluster slows down --- Key: CASSANDRA-7567 URL: https://issues.apache.org/jira/browse/CASSANDRA-7567 Project: Cassandra Issue Type: Bug Components: Core Environment: debian 7.5, bare metal, 14 nodes, 64CPUs, 64GB RAM, commit_log disk sata, data disk SSD, vnodes, leveled compaction strategy Reporter: David O'Dell Assignee: Ryan McGuire Attachments: 7567.logs.bz2, write_request_latency.png We've run into a situation where a single node out of 14 is experiencing high disk io. This can happen when a node is being decommissioned or after it joins the ring and runs into the bug cassandra-6621. When this occurs the write latency for the entire cluster spikes. From 0.3ms to 170ms. To simulate this simply run dd on the commit_log disk (dd if=/dev/zero of=/tmp/foo bs=1024) and you will see that instantly all nodes in the cluster have slowed down. BTW overwhelming the data disk does not have this same effect. Also I've tried this where the overwhelmed node isn't being connected directly from the client and it still has the same effect. -- This message was sent by Atlassian JIRA (v6.2#6252)
