[jira] [Commented] (CASSANDRA-2538) CQL: NPE running SELECT with an IN clause
[
https://issues.apache.org/jira/browse/CASSANDRA-2538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023493#comment-13023493
]
Eric Evans commented on CASSANDRA-2538:
---
{quote}
Totally didn't know we support IN for DELETE.
Would prefer to fix by offering IN for for the other statements as well. The
Antlr doesn't look too daunting w/ DELETE as an example (knock on wood). Can
take a stab at that tomorrow.
{quote}
This is {{multiget_slice()}} / {{multiget_count()}} and was intentionally
omitted (remember?). Not saying this is decision that can't be revisited, just
reminding.
Oh, and if we do move forward, it's post-0.8, we're in a feature-freeze. :)
> CQL: NPE running SELECT with an IN clause
> -
>
> Key: CASSANDRA-2538
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2538
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 0.8 beta 1
>Reporter: Cathy Daw
>Assignee: Eric Evans
>Priority: Minor
> Labels: cql
> Fix For: 0.8.0
>
> Attachments:
> v1-0001-CASSANDRA-2538-NPE-running-SELECT-with-an-IN-clause.txt
>
>
> *Test Case to Run*
> {noformat}
> cqlsh> select * from users where key in ('user2', 'user3');
> Internal application error
> {noformat}
> *Test Setup*
> {noformat}
> CREATE COLUMNFAMILY users (
> KEY varchar PRIMARY KEY,
> password varchar);
> INSERT INTO users (KEY, password) VALUES ('user1', 'ch@ngem3a');
> {noformat}
> *Log Files*
> {noformat}
> ERROR [RequestResponseStage:17] 2011-04-21 23:36:41,600
> AbstractCassandraDaemon.java (line 112) Fatal exception in thread
> Thread[RequestResponseStage:17,5,main]
> java.lang.AssertionError
> at
> org.apache.cassandra.service.ReadCallback.response(ReadCallback.java:127)
> at
> org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:49)
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:72)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:636)
> ERROR [RequestResponseStage:17] 2011-04-21 23:36:41,600
> AbstractCassandraDaemon.java (line 112) Fatal exception in thread
> Thread[RequestResponseStage:17,5,main]
> java.lang.AssertionError
> at
> org.apache.cassandra.service.ReadCallback.response(ReadCallback.java:127)
> at
> org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:49)
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:72)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:636)
> ERROR [pool-2-thread-5] 2011-04-21 23:37:12,026 Cassandra.java (line 4082)
> Internal error processing execute_cql_query
> java.lang.NullPointerException
> at org.apache.cassandra.cql.WhereClause.and(WhereClause.java:59)
> at org.apache.cassandra.cql.WhereClause.(WhereClause.java:44)
> at org.apache.cassandra.cql.CqlParser.whereClause(CqlParser.java:816)
> at
> org.apache.cassandra.cql.CqlParser.selectStatement(CqlParser.java:502)
> at org.apache.cassandra.cql.CqlParser.query(CqlParser.java:191)
> at
> org.apache.cassandra.cql.QueryProcessor.getStatement(QueryProcessor.java:834)
> at
> org.apache.cassandra.cql.QueryProcessor.process(QueryProcessor.java:463)
> at
> org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1134)
> at
> org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.process(Cassandra.java:4072)
> at
> org.apache.cassandra.thrift.Cassandra$Processor.process(Cassandra.java:2889)
> at
> org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:187)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:636)
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2545) CQL: Syntax error performing batch updates
[
https://issues.apache.org/jira/browse/CASSANDRA-2545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023491#comment-13023491
]
Eric Evans commented on CASSANDRA-2545:
---
bq. i don't think "cqlsh requires commands to end with semicolon" is a bug
It's not; That's not the bug.
What's buggy is the way that a multi-line statement is parsed from the input.
The attached patch should take care of it. It does not require the semi-colon
for the individual UPDATE statements (APPLY BATCH is the terminator here), but
using them won't hurt anything.
> CQL: Syntax error performing batch updates
> --
>
> Key: CASSANDRA-2545
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2545
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 0.8 beta 1
>Reporter: Cathy Daw
> Attachments:
> v2-0001-CASSANDRA-2545-also-consider-APPLY-BATCH-for-terminati.txt
>
>
> *CQL Test Case*
> {code}
> //TEST CASE #1
> BEGIN BATCH
> UPDATE users SET gender = 'm', birth_year = '1981' WHERE KEY = 'user1';
> UPDATE users SET gender = 'm', birth_year = '1982' WHERE KEY = 'user2';
> UPDATE users SET gender = 'm', birth_year = '1983' WHERE KEY = 'user3';
> APPLY BATCH
> //TEST CASE #2
> BEGIN BATCH USING CONSISTENCY ZERO
> UPDATE users SET state = 'TX' WHERE KEY = 'user1';
> UPDATE users SET state = 'TX' WHERE KEY = 'user2';
> UPDATE users SET state = 'TX' WHERE KEY = 'user3';
> APPLY BATCH
> //ERROR
> Bad Request: line 0:-1 mismatched input '' expecting K_APPLY
> {code}
> *Test Setup*
> {code}
> CREATE COLUMNFAMILY users (
> KEY varchar PRIMARY KEY,
> password varchar,
> gender varchar,
> session_token varchar,
> state varchar,
> birth_year bigint);
> INSERT INTO users (KEY, password, gender, state, birth_year) VALUES ('user1',
> 'ch@ngem3', 'f', 'CA', '1971');
> INSERT INTO users (KEY, password, gender, state, birth_year) VALUES ('user2',
> 'ch@ngem3', 'f', 'CA', '1972');
> INSERT INTO users (KEY, password, gender, state, birth_year) VALUES ('user3',
> 'ch@ngem3', 'f', 'CA', '1973');
> {code}
> *Documented Syntax*
> {panel}
> BEGIN BATCH [USING ]
> UPDATE CF1 SET name1 = value1, name2 = value2 WHERE KEY = keyname1;
> UPDATE CF1 SET name3 = value3 WHERE KEY = keyname2;
> UPDATE CF2 SET name4 = value4, name5 = value5 WHERE KEY = keyname3;
> APPLY BATCH
> {panel}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2545) CQL: Syntax error performing batch updates
[
https://issues.apache.org/jira/browse/CASSANDRA-2545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Evans updated CASSANDRA-2545:
--
Attachment:
v2-0001-CASSANDRA-2545-also-consider-APPLY-BATCH-for-terminati.txt
> CQL: Syntax error performing batch updates
> --
>
> Key: CASSANDRA-2545
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2545
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 0.8 beta 1
>Reporter: Cathy Daw
> Attachments:
> v2-0001-CASSANDRA-2545-also-consider-APPLY-BATCH-for-terminati.txt
>
>
> *CQL Test Case*
> {code}
> //TEST CASE #1
> BEGIN BATCH
> UPDATE users SET gender = 'm', birth_year = '1981' WHERE KEY = 'user1';
> UPDATE users SET gender = 'm', birth_year = '1982' WHERE KEY = 'user2';
> UPDATE users SET gender = 'm', birth_year = '1983' WHERE KEY = 'user3';
> APPLY BATCH
> //TEST CASE #2
> BEGIN BATCH USING CONSISTENCY ZERO
> UPDATE users SET state = 'TX' WHERE KEY = 'user1';
> UPDATE users SET state = 'TX' WHERE KEY = 'user2';
> UPDATE users SET state = 'TX' WHERE KEY = 'user3';
> APPLY BATCH
> //ERROR
> Bad Request: line 0:-1 mismatched input '' expecting K_APPLY
> {code}
> *Test Setup*
> {code}
> CREATE COLUMNFAMILY users (
> KEY varchar PRIMARY KEY,
> password varchar,
> gender varchar,
> session_token varchar,
> state varchar,
> birth_year bigint);
> INSERT INTO users (KEY, password, gender, state, birth_year) VALUES ('user1',
> 'ch@ngem3', 'f', 'CA', '1971');
> INSERT INTO users (KEY, password, gender, state, birth_year) VALUES ('user2',
> 'ch@ngem3', 'f', 'CA', '1972');
> INSERT INTO users (KEY, password, gender, state, birth_year) VALUES ('user3',
> 'ch@ngem3', 'f', 'CA', '1973');
> {code}
> *Documented Syntax*
> {panel}
> BEGIN BATCH [USING ]
> UPDATE CF1 SET name1 = value1, name2 = value2 WHERE KEY = keyname1;
> UPDATE CF1 SET name3 = value3 WHERE KEY = keyname2;
> UPDATE CF2 SET name4 = value4, name5 = value5 WHERE KEY = keyname3;
> APPLY BATCH
> {panel}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2545) CQL: Syntax error performing batch updates
[
https://issues.apache.org/jira/browse/CASSANDRA-2545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Evans updated CASSANDRA-2545:
--
Attachment: (was:
v1-0001-CASSANDRA-2545-also-consider-APPLY-BATCH-for-terminati.txt)
> CQL: Syntax error performing batch updates
> --
>
> Key: CASSANDRA-2545
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2545
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 0.8 beta 1
>Reporter: Cathy Daw
> Attachments:
> v2-0001-CASSANDRA-2545-also-consider-APPLY-BATCH-for-terminati.txt
>
>
> *CQL Test Case*
> {code}
> //TEST CASE #1
> BEGIN BATCH
> UPDATE users SET gender = 'm', birth_year = '1981' WHERE KEY = 'user1';
> UPDATE users SET gender = 'm', birth_year = '1982' WHERE KEY = 'user2';
> UPDATE users SET gender = 'm', birth_year = '1983' WHERE KEY = 'user3';
> APPLY BATCH
> //TEST CASE #2
> BEGIN BATCH USING CONSISTENCY ZERO
> UPDATE users SET state = 'TX' WHERE KEY = 'user1';
> UPDATE users SET state = 'TX' WHERE KEY = 'user2';
> UPDATE users SET state = 'TX' WHERE KEY = 'user3';
> APPLY BATCH
> //ERROR
> Bad Request: line 0:-1 mismatched input '' expecting K_APPLY
> {code}
> *Test Setup*
> {code}
> CREATE COLUMNFAMILY users (
> KEY varchar PRIMARY KEY,
> password varchar,
> gender varchar,
> session_token varchar,
> state varchar,
> birth_year bigint);
> INSERT INTO users (KEY, password, gender, state, birth_year) VALUES ('user1',
> 'ch@ngem3', 'f', 'CA', '1971');
> INSERT INTO users (KEY, password, gender, state, birth_year) VALUES ('user2',
> 'ch@ngem3', 'f', 'CA', '1972');
> INSERT INTO users (KEY, password, gender, state, birth_year) VALUES ('user3',
> 'ch@ngem3', 'f', 'CA', '1973');
> {code}
> *Documented Syntax*
> {panel}
> BEGIN BATCH [USING ]
> UPDATE CF1 SET name1 = value1, name2 = value2 WHERE KEY = keyname1;
> UPDATE CF1 SET name3 = value3 WHERE KEY = keyname2;
> UPDATE CF2 SET name4 = value4, name5 = value5 WHERE KEY = keyname3;
> APPLY BATCH
> {panel}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2545) CQL: Syntax error performing batch updates
[
https://issues.apache.org/jira/browse/CASSANDRA-2545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023490#comment-13023490
]
Jonathan Ellis commented on CASSANDRA-2545:
---
i don't think "cqlsh requires commands to end with semicolon" is a bug
> CQL: Syntax error performing batch updates
> --
>
> Key: CASSANDRA-2545
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2545
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 0.8 beta 1
>Reporter: Cathy Daw
> Attachments:
> v1-0001-CASSANDRA-2545-also-consider-APPLY-BATCH-for-terminati.txt
>
>
> *CQL Test Case*
> {code}
> //TEST CASE #1
> BEGIN BATCH
> UPDATE users SET gender = 'm', birth_year = '1981' WHERE KEY = 'user1';
> UPDATE users SET gender = 'm', birth_year = '1982' WHERE KEY = 'user2';
> UPDATE users SET gender = 'm', birth_year = '1983' WHERE KEY = 'user3';
> APPLY BATCH
> //TEST CASE #2
> BEGIN BATCH USING CONSISTENCY ZERO
> UPDATE users SET state = 'TX' WHERE KEY = 'user1';
> UPDATE users SET state = 'TX' WHERE KEY = 'user2';
> UPDATE users SET state = 'TX' WHERE KEY = 'user3';
> APPLY BATCH
> //ERROR
> Bad Request: line 0:-1 mismatched input '' expecting K_APPLY
> {code}
> *Test Setup*
> {code}
> CREATE COLUMNFAMILY users (
> KEY varchar PRIMARY KEY,
> password varchar,
> gender varchar,
> session_token varchar,
> state varchar,
> birth_year bigint);
> INSERT INTO users (KEY, password, gender, state, birth_year) VALUES ('user1',
> 'ch@ngem3', 'f', 'CA', '1971');
> INSERT INTO users (KEY, password, gender, state, birth_year) VALUES ('user2',
> 'ch@ngem3', 'f', 'CA', '1972');
> INSERT INTO users (KEY, password, gender, state, birth_year) VALUES ('user3',
> 'ch@ngem3', 'f', 'CA', '1973');
> {code}
> *Documented Syntax*
> {panel}
> BEGIN BATCH [USING ]
> UPDATE CF1 SET name1 = value1, name2 = value2 WHERE KEY = keyname1;
> UPDATE CF1 SET name3 = value3 WHERE KEY = keyname2;
> UPDATE CF2 SET name4 = value4, name5 = value5 WHERE KEY = keyname3;
> APPLY BATCH
> {panel}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2545) CQL: Syntax error performing batch updates
[
https://issues.apache.org/jira/browse/CASSANDRA-2545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023488#comment-13023488
]
Eric Evans commented on CASSANDRA-2545:
---
This is a cqlsh bug. The attached patch is an improvement, but could probably
be improved upon.
> CQL: Syntax error performing batch updates
> --
>
> Key: CASSANDRA-2545
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2545
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 0.8 beta 1
>Reporter: Cathy Daw
> Attachments:
> v1-0001-CASSANDRA-2545-also-consider-APPLY-BATCH-for-terminati.txt
>
>
> *CQL Test Case*
> {code}
> //TEST CASE #1
> BEGIN BATCH
> UPDATE users SET gender = 'm', birth_year = '1981' WHERE KEY = 'user1';
> UPDATE users SET gender = 'm', birth_year = '1982' WHERE KEY = 'user2';
> UPDATE users SET gender = 'm', birth_year = '1983' WHERE KEY = 'user3';
> APPLY BATCH
> //TEST CASE #2
> BEGIN BATCH USING CONSISTENCY ZERO
> UPDATE users SET state = 'TX' WHERE KEY = 'user1';
> UPDATE users SET state = 'TX' WHERE KEY = 'user2';
> UPDATE users SET state = 'TX' WHERE KEY = 'user3';
> APPLY BATCH
> //ERROR
> Bad Request: line 0:-1 mismatched input '' expecting K_APPLY
> {code}
> *Test Setup*
> {code}
> CREATE COLUMNFAMILY users (
> KEY varchar PRIMARY KEY,
> password varchar,
> gender varchar,
> session_token varchar,
> state varchar,
> birth_year bigint);
> INSERT INTO users (KEY, password, gender, state, birth_year) VALUES ('user1',
> 'ch@ngem3', 'f', 'CA', '1971');
> INSERT INTO users (KEY, password, gender, state, birth_year) VALUES ('user2',
> 'ch@ngem3', 'f', 'CA', '1972');
> INSERT INTO users (KEY, password, gender, state, birth_year) VALUES ('user3',
> 'ch@ngem3', 'f', 'CA', '1973');
> {code}
> *Documented Syntax*
> {panel}
> BEGIN BATCH [USING ]
> UPDATE CF1 SET name1 = value1, name2 = value2 WHERE KEY = keyname1;
> UPDATE CF1 SET name3 = value3 WHERE KEY = keyname2;
> UPDATE CF2 SET name4 = value4, name5 = value5 WHERE KEY = keyname3;
> APPLY BATCH
> {panel}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2545) CQL: Syntax error performing batch updates
[
https://issues.apache.org/jira/browse/CASSANDRA-2545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Evans updated CASSANDRA-2545:
--
Attachment:
v1-0001-CASSANDRA-2545-also-consider-APPLY-BATCH-for-terminati.txt
> CQL: Syntax error performing batch updates
> --
>
> Key: CASSANDRA-2545
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2545
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 0.8 beta 1
>Reporter: Cathy Daw
> Attachments:
> v1-0001-CASSANDRA-2545-also-consider-APPLY-BATCH-for-terminati.txt
>
>
> *CQL Test Case*
> {code}
> //TEST CASE #1
> BEGIN BATCH
> UPDATE users SET gender = 'm', birth_year = '1981' WHERE KEY = 'user1';
> UPDATE users SET gender = 'm', birth_year = '1982' WHERE KEY = 'user2';
> UPDATE users SET gender = 'm', birth_year = '1983' WHERE KEY = 'user3';
> APPLY BATCH
> //TEST CASE #2
> BEGIN BATCH USING CONSISTENCY ZERO
> UPDATE users SET state = 'TX' WHERE KEY = 'user1';
> UPDATE users SET state = 'TX' WHERE KEY = 'user2';
> UPDATE users SET state = 'TX' WHERE KEY = 'user3';
> APPLY BATCH
> //ERROR
> Bad Request: line 0:-1 mismatched input '' expecting K_APPLY
> {code}
> *Test Setup*
> {code}
> CREATE COLUMNFAMILY users (
> KEY varchar PRIMARY KEY,
> password varchar,
> gender varchar,
> session_token varchar,
> state varchar,
> birth_year bigint);
> INSERT INTO users (KEY, password, gender, state, birth_year) VALUES ('user1',
> 'ch@ngem3', 'f', 'CA', '1971');
> INSERT INTO users (KEY, password, gender, state, birth_year) VALUES ('user2',
> 'ch@ngem3', 'f', 'CA', '1972');
> INSERT INTO users (KEY, password, gender, state, birth_year) VALUES ('user3',
> 'ch@ngem3', 'f', 'CA', '1973');
> {code}
> *Documented Syntax*
> {panel}
> BEGIN BATCH [USING ]
> UPDATE CF1 SET name1 = value1, name2 = value2 WHERE KEY = keyname1;
> UPDATE CF1 SET name3 = value3 WHERE KEY = keyname2;
> UPDATE CF2 SET name4 = value4, name5 = value5 WHERE KEY = keyname3;
> APPLY BATCH
> {panel}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-2534) CQL: CREATE CF, DROP CF, CREATE CF caused my cluster to crash
[
https://issues.apache.org/jira/browse/CASSANDRA-2534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cathy Daw resolved CASSANDRA-2534.
--
Resolution: Cannot Reproduce
Not sure what the issue was here but could not reproduce on build from 4/22.
> CQL: CREATE CF, DROP CF, CREATE CF caused my cluster to crash
> -
>
> Key: CASSANDRA-2534
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2534
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 0.8.0
>Reporter: Cathy Daw
>Priority: Critical
> Labels: cql
>
> The following test case of CREATE CF, DROP CF, CREATE CF caused my cluster to
> crash.
> *CREATE/DROP/CREATE CF users*
> {code}
> cqlsh> CREATE COLUMNFAMILY users (
>... KEY varchar PRIMARY KEY,
>... password varchar);
> cqlsh> drop columnfamily users;
> cqlsh> CREATE COLUMNFAMILY users (
>... userkey varchar PRIMARY KEY,
>... password varchar);
> Exception: TSocket read 0 bytes
> {code}
> *Cassandra CLI - session broken*
> {code}
> [default@clidb] describe keyspace cqldb;
> java.net.SocketException: Broken pipe
> {code}
> *Nodetool - server down*
> {code}
> [cassandra@cdaw-qa1 bin]$ ./nodetool -h cdaw-qa1 -p 7199 ring
> Error connection to remote JMX agent!
> java.io.IOException: Failed to retrieve RMIServer stub:
> javax.naming.ServiceUnavailableException [Root exception is
> java.rmi.ConnectException: Connection refused to host: cdaw-qa1; nested
> exception is:
> java.net.ConnectException: Connection refused]
> at
> javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:342)
> at
> javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:267)
> at org.apache.cassandra.tools.NodeProbe.connect(NodeProbe.java:139)
> at org.apache.cassandra.tools.NodeProbe.(NodeProbe.java:109)
> at org.apache.cassandra.tools.NodeCmd.main(NodeCmd.java:525)
> Caused by: javax.naming.ServiceUnavailableException [Root exception is
> java.rmi.ConnectException: Connection refused to host: cdaw-qa1; nested
> exception is:
> java.net.ConnectException: Connection refused]
> at
> com.sun.jndi.rmi.registry.RegistryContext.lookup(RegistryContext.java:118)
> at
> com.sun.jndi.toolkit.url.GenericURLContext.lookup(GenericURLContext.java:203)
> at javax.naming.InitialContext.lookup(InitialContext.java:409)
> at
> javax.management.remote.rmi.RMIConnector.findRMIServerJNDI(RMIConnector.java:1902)
> at
> javax.management.remote.rmi.RMIConnector.findRMIServer(RMIConnector.java:1871)
> at
> javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:276)
> ... 4 more
> Caused by: java.rmi.ConnectException: Connection refused to host: cdaw-qa1;
> nested exception is:
> java.net.ConnectException: Connection refused
> at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619)
> at
> sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216)
> at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
> at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:340)
> at sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source)
> at
> com.sun.jndi.rmi.registry.RegistryContext.lookup(RegistryContext.java:114)
> ... 9 more
> Caused by: java.net.ConnectException: Connection refused
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:310)
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:176)
> at
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:163)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)
> at java.net.Socket.connect(Socket.java:546)
> at java.net.Socket.connect(Socket.java:495)
> at java.net.Socket.(Socket.java:392)
> at java.net.Socket.(Socket.java:206)
> at
> sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:40)
> at
> sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:146)
> at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:613)
> ... 14 more
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2548) CQL: After running DELETE without specifying columns, the key is still returned in queries
CQL: After running DELETE without specifying columns, the key is still returned
in queries
--
Key: CASSANDRA-2548
URL: https://issues.apache.org/jira/browse/CASSANDRA-2548
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.8 beta 1
Reporter: Cathy Daw
Priority: Minor
I am not sure if this is expected because of how cassandra-cli works, but
coming from SQL I would expect that if I delete a row it doesn't show up in a
subsequent select statement.
*Test Case*
{code}
cqlsh> DELETE FROM users where KEY = 'user2';
cqlsh> select * from users where KEY='user2';
u'user2'
{code}
*Cassandra CLI shows no rows returned*
{code}
[default@cqldb] get users['user2'];
Returned 0 results.
[default@cqldb] list users;
RowKey: user2
[default@cqldb] del users ['user2'];
row removed.
[default@cqldb] list users;
RowKey: user2
{code}
*Test Setup*
{code}
CREATE COLUMNFAMILY users (
KEY varchar PRIMARY KEY,
password varchar,
gender varchar,
session_token varchar,
state varchar,
birth_year bigint);
INSERT INTO users (KEY, password, gender, state, birth_year) VALUES ('user2',
'ch@ngem3', 'f', 'CA', '1972');
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2549) Start up of 0.8-beta1 on Ubuntu
Start up of 0.8-beta1 on Ubuntu Key: CASSANDRA-2549 URL: https://issues.apache.org/jira/browse/CASSANDRA-2549 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8 beta 1 Environment: Linux home.broadley.org.nz 2.6.32-29-generic-pae #58-Ubuntu SMP Fri Feb 11 19:15:25 UTC 2011 i686 GNU/Linux Reporter: Drew Broadley root@home:/home/drew# cassandra -f INFO 14:06:03,261 Logging initialized INFO 14:06:03,323 Heap size: 1543831552/1543831552 INFO 14:06:03,332 JNA not found. Native methods will be disabled. INFO 14:06:03,379 Loading settings from file:/etc/cassandra/cassandra.yaml INFO 14:06:03,899 DiskAccessMode 'auto' determined to be standard, indexAccessMode is standard ERROR 14:06:04,028 Exception encountered during startup. java.lang.NoClassDefFoundError: org/apache/cassandra/thrift/UnavailableException at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2444) at java.lang.Class.privateGetPublicMethods(Class.java:2564) at java.lang.Class.getMethods(Class.java:1427) at com.sun.jmx.mbeanserver.MBeanAnalyzer.initMaps(MBeanAnalyzer.java:126) at com.sun.jmx.mbeanserver.MBeanAnalyzer.(MBeanAnalyzer.java:116) at com.sun.jmx.mbeanserver.MBeanAnalyzer.analyzer(MBeanAnalyzer.java:104) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.getAnalyzer(StandardMBeanIntrospector.java:66) at com.sun.jmx.mbeanserver.MBeanIntrospector.getPerInterface(MBeanIntrospector.java:181) at com.sun.jmx.mbeanserver.MBeanSupport.(MBeanSupport.java:136) at com.sun.jmx.mbeanserver.StandardMBeanSupport.(StandardMBeanSupport.java:64) at com.sun.jmx.mbeanserver.Introspector.makeDynamicMBean(Introspector.java:174) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:936) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:330) at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:516) at org.apache.cassandra.service.StorageService.(StorageService.java:231) at org.apache.cassandra.service.StorageService.(StorageService.java:171) at org.apache.cassandra.locator.DynamicEndpointSnitch.(DynamicEndpointSnitch.java:78) at org.apache.cassandra.config.DatabaseDescriptor.createEndpointSnitch(DatabaseDescriptor.java:429) at org.apache.cassandra.config.DatabaseDescriptor.(DatabaseDescriptor.java:294) at org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:98) at org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:314) at org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:80) Caused by: java.lang.ClassNotFoundException: org.apache.cassandra.thrift.UnavailableException at java.net.URLClassLoader$1.run(URLClassLoader.java:217) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:205) at java.lang.ClassLoader.loadClass(ClassLoader.java:321) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294) at java.lang.ClassLoader.loadClass(ClassLoader.java:266) ... 23 more Exception encountered during startup. java.lang.NoClassDefFoundError: org/apache/cassandra/thrift/UnavailableException at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2444) at java.lang.Class.privateGetPublicMethods(Class.java:2564) at java.lang.Class.getMethods(Class.java:1427) at com.sun.jmx.mbeanserver.MBeanAnalyzer.initMaps(MBeanAnalyzer.java:126) at com.sun.jmx.mbeanserver.MBeanAnalyzer.(MBeanAnalyzer.java:116) at com.sun.jmx.mbeanserver.MBeanAnalyzer.analyzer(MBeanAnalyzer.java:104) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.getAnalyzer(StandardMBeanIntrospector.java:66) at com.sun.jmx.mbeanserver.MBeanIntrospector.getPerInterface(MBeanIntrospector.java:181) at com.sun.jmx.mbeanserver.MBeanSupport.(MBeanSupport.java:136) at com.sun.jmx.mbeanserver.StandardMBeanSupport.(StandardMBeanSupport.java:64) at com.sun.jmx.mbeanserver.Introspector.makeDynamicMBean(Introspector.java:174) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:936) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:330) at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:516) at org.apache.cassandra.service.StorageService.(StorageSe
[jira] [Commented] (CASSANDRA-2525) CQL: create keyspace does not the replication factor argument and allows invalid sql to pass thru
[
https://issues.apache.org/jira/browse/CASSANDRA-2525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023479#comment-13023479
]
Hudson commented on CASSANDRA-2525:
---
Integrated in Cassandra-0.8 #36 (See
[https://builds.apache.org/hudson/job/Cassandra-0.8/36/])
validate CQL create keyspace options
patch by jbellis; reviewed by eevans for CASSANDRA-2525
> CQL: create keyspace does not the replication factor argument and allows
> invalid sql to pass thru
> -
>
> Key: CASSANDRA-2525
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2525
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 0.8 beta 1
> Environment: Cluster: 3 node Rackspace cluster running Centos 5.5.
> Build:
> https://builds.apache.org/hudson/job/Cassandra/859/artifact/cassandra/build/apache-cassandra-2011-04-20_10-01-29-bin.tar.gz
>Reporter: Cathy Daw
>Assignee: Jonathan Ellis
>Priority: Critical
> Labels: cql
> Fix For: 0.8.0
>
> Attachments: 2525.txt
>
>
> I ran the following SQL in cqlsh and immediately received a socket closed
> error. After that point, I couldn't run nodetool, and then got an exception
> starting up the cluster.
> Please Note: The following syntax is valid in 0.74 but invalid in 0.8.
> The 0.8 cassandra-cli errors on the following statement, so the resolution of
> the bug is to have cqlsh block this incorrect syntax.
> {code}
> create keyspace testcli with replication_factor=1
> and placement_strategy = 'org.apache.cassandra.locator.SimpleStrategy';
> {code}
> {code}
> CREATE KEYSPACE testcql with replication_factor = 1 and strategy_class =
> 'org.apache.cassandra.locator.SimpleStrategy';
> {code}
> {code}
> ERROR 01:29:26,989 Exception encountered during startup.
> java.lang.RuntimeException:
> org.apache.cassandra.config.ConfigurationException: SimpleStrategy requires a
> replication_factor strategy option.
> at org.apache.cassandra.db.Table.(Table.java:278)
> at org.apache.cassandra.db.Table.open(Table.java:110)
> at
> org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:160)
> at
> org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:314)
> at
> org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:80)
> Caused by: org.apache.cassandra.config.ConfigurationException: SimpleStrategy
> requires a replication_factor strategy option.
> at
> org.apache.cassandra.locator.SimpleStrategy.validateOptions(SimpleStrategy.java:79)
> at
> org.apache.cassandra.locator.AbstractReplicationStrategy.createReplicationStrategy(AbstractReplicationStrategy.java:262)
> at
> org.apache.cassandra.db.Table.createReplicationStrategy(Table.java:328)
> at org.apache.cassandra.db.Table.(Table.java:274)
> ... 4 more
> Exception encountered during startup.
> java.lang.RuntimeException:
> org.apache.cassandra.config.ConfigurationException: SimpleStrategy requires a
> replication_factor strategy option.
> at org.apache.cassandra.db.Table.(Table.java:278)
> at org.apache.cassandra.db.Table.open(Table.java:110)
> at
> org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:160)
> at
> org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:314)
> at
> org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:80)
> Caused by: org.apache.cassandra.config.ConfigurationException: SimpleStrategy
> requires a replication_factor strategy option.
> at
> org.apache.cassandra.locator.SimpleStrategy.validateOptions(SimpleStrategy.java:79)
> at
> org.apache.cassandra.locator.AbstractReplicationStrategy.createReplicationStrategy(AbstractReplicationStrategy.java:262)
> at
> org.apache.cassandra.db.Table.createReplicationStrategy(Table.java:328)
> at org.apache.cassandra.db.Table.(Table.java:274)
> ... 4 more
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2539) CQL: cqlsh does shows Exception, but not error message when running truncate while a node is down.
[
https://issues.apache.org/jira/browse/CASSANDRA-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023480#comment-13023480
]
Hudson commented on CASSANDRA-2539:
---
Integrated in Cassandra-0.8 #36 (See
[https://builds.apache.org/hudson/job/Cassandra-0.8/36/])
more user-friendly messages for UE/TOE in cqlsh
patch by eevans and jbellis for CASSANDRA-2539
> CQL: cqlsh does shows Exception, but not error message when running truncate
> while a node is down.
> ---
>
> Key: CASSANDRA-2539
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2539
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 0.8.0
>Reporter: Cathy Daw
>Assignee: Eric Evans
>Priority: Trivial
> Labels: cql
> Fix For: 0.8.0
>
> Attachments: 2539-v3.txt,
> v2-0001-CASSANDRA-2539-print-friendlier-message-for-Unavailabl.txt
>
>
> This is really just a usability bug, but it would nice to bubble the error
> message that is printed in the log file up to the interface.
> *cqlsh output*
> {noformat}
> cqlsh> truncate users;
> Exception: UnavailableException()
> {noformat}
> *log file error*
> {noformat}
> INFO [pool-2-thread-5] 2011-04-21 23:53:30,466 StorageProxy.java (line 1021)
> Cannot perform truncate, some hosts are down
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2547) CQL: support for "create columnfamily" option 'row_cache_provider'
CQL: support for "create columnfamily" option 'row_cache_provider' -- Key: CASSANDRA-2547 URL: https://issues.apache.org/jira/browse/CASSANDRA-2547 Project: Cassandra Issue Type: Improvement Affects Versions: 0.8 beta 1 Reporter: Cathy Daw Priority: Minor -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2546) CQL: there is currently no mechanism to specify TTL with insert, update or delete
CQL: there is currently no mechanism to specify TTL with insert, update or delete - Key: CASSANDRA-2546 URL: https://issues.apache.org/jira/browse/CASSANDRA-2546 Project: Cassandra Issue Type: Bug Affects Versions: 0.8 beta 1 Reporter: Cathy Daw -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2545) CQL: Syntax error performing batch updates
CQL: Syntax error performing batch updates
--
Key: CASSANDRA-2545
URL: https://issues.apache.org/jira/browse/CASSANDRA-2545
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.8 beta 1
Reporter: Cathy Daw
*CQL Test Case*
{code}
//TEST CASE #1
BEGIN BATCH
UPDATE users SET gender = 'm', birth_year = '1981' WHERE KEY = 'user1';
UPDATE users SET gender = 'm', birth_year = '1982' WHERE KEY = 'user2';
UPDATE users SET gender = 'm', birth_year = '1983' WHERE KEY = 'user3';
APPLY BATCH
//TEST CASE #2
BEGIN BATCH USING CONSISTENCY ZERO
UPDATE users SET state = 'TX' WHERE KEY = 'user1';
UPDATE users SET state = 'TX' WHERE KEY = 'user2';
UPDATE users SET state = 'TX' WHERE KEY = 'user3';
//ERROR
Bad Request: line 0:-1 mismatched input '' expecting K_APPLY
APPLY BATCH
{code}
*Test Setup*
{code}
CREATE COLUMNFAMILY users (
KEY varchar PRIMARY KEY,
password varchar,
gender varchar,
session_token varchar,
state varchar,
birth_year bigint);
INSERT INTO users (KEY, password, gender, state, birth_year) VALUES ('user1',
'ch@ngem3', 'f', 'CA', '1971');
INSERT INTO users (KEY, password, gender, state, birth_year) VALUES ('user2',
'ch@ngem3', 'f', 'CA', '1972');
INSERT INTO users (KEY, password, gender, state, birth_year) VALUES ('user3',
'ch@ngem3', 'f', 'CA', '1973');
{code}
*Documented Syntax*
{panel}
BEGIN BATCH [USING ]
UPDATE CF1 SET name1 = value1, name2 = value2 WHERE KEY = keyname1;
UPDATE CF1 SET name3 = value3 WHERE KEY = keyname2;
UPDATE CF2 SET name4 = value4, name5 = value5 WHERE KEY = keyname3;
APPLY BATCH
{panel}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2545) CQL: Syntax error performing batch updates
[
https://issues.apache.org/jira/browse/CASSANDRA-2545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cathy Daw updated CASSANDRA-2545:
-
Description:
*CQL Test Case*
{code}
//TEST CASE #1
BEGIN BATCH
UPDATE users SET gender = 'm', birth_year = '1981' WHERE KEY = 'user1';
UPDATE users SET gender = 'm', birth_year = '1982' WHERE KEY = 'user2';
UPDATE users SET gender = 'm', birth_year = '1983' WHERE KEY = 'user3';
APPLY BATCH
//TEST CASE #2
BEGIN BATCH USING CONSISTENCY ZERO
UPDATE users SET state = 'TX' WHERE KEY = 'user1';
UPDATE users SET state = 'TX' WHERE KEY = 'user2';
UPDATE users SET state = 'TX' WHERE KEY = 'user3';
APPLY BATCH
//ERROR
Bad Request: line 0:-1 mismatched input '' expecting K_APPLY
{code}
*Test Setup*
{code}
CREATE COLUMNFAMILY users (
KEY varchar PRIMARY KEY,
password varchar,
gender varchar,
session_token varchar,
state varchar,
birth_year bigint);
INSERT INTO users (KEY, password, gender, state, birth_year) VALUES ('user1',
'ch@ngem3', 'f', 'CA', '1971');
INSERT INTO users (KEY, password, gender, state, birth_year) VALUES ('user2',
'ch@ngem3', 'f', 'CA', '1972');
INSERT INTO users (KEY, password, gender, state, birth_year) VALUES ('user3',
'ch@ngem3', 'f', 'CA', '1973');
{code}
*Documented Syntax*
{panel}
BEGIN BATCH [USING ]
UPDATE CF1 SET name1 = value1, name2 = value2 WHERE KEY = keyname1;
UPDATE CF1 SET name3 = value3 WHERE KEY = keyname2;
UPDATE CF2 SET name4 = value4, name5 = value5 WHERE KEY = keyname3;
APPLY BATCH
{panel}
was:
*CQL Test Case*
{code}
//TEST CASE #1
BEGIN BATCH
UPDATE users SET gender = 'm', birth_year = '1981' WHERE KEY = 'user1';
UPDATE users SET gender = 'm', birth_year = '1982' WHERE KEY = 'user2';
UPDATE users SET gender = 'm', birth_year = '1983' WHERE KEY = 'user3';
APPLY BATCH
//TEST CASE #2
BEGIN BATCH USING CONSISTENCY ZERO
UPDATE users SET state = 'TX' WHERE KEY = 'user1';
UPDATE users SET state = 'TX' WHERE KEY = 'user2';
UPDATE users SET state = 'TX' WHERE KEY = 'user3';
//ERROR
Bad Request: line 0:-1 mismatched input '' expecting K_APPLY
APPLY BATCH
{code}
*Test Setup*
{code}
CREATE COLUMNFAMILY users (
KEY varchar PRIMARY KEY,
password varchar,
gender varchar,
session_token varchar,
state varchar,
birth_year bigint);
INSERT INTO users (KEY, password, gender, state, birth_year) VALUES ('user1',
'ch@ngem3', 'f', 'CA', '1971');
INSERT INTO users (KEY, password, gender, state, birth_year) VALUES ('user2',
'ch@ngem3', 'f', 'CA', '1972');
INSERT INTO users (KEY, password, gender, state, birth_year) VALUES ('user3',
'ch@ngem3', 'f', 'CA', '1973');
{code}
*Documented Syntax*
{panel}
BEGIN BATCH [USING ]
UPDATE CF1 SET name1 = value1, name2 = value2 WHERE KEY = keyname1;
UPDATE CF1 SET name3 = value3 WHERE KEY = keyname2;
UPDATE CF2 SET name4 = value4, name5 = value5 WHERE KEY = keyname3;
APPLY BATCH
{panel}
> CQL: Syntax error performing batch updates
> --
>
> Key: CASSANDRA-2545
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2545
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 0.8 beta 1
>Reporter: Cathy Daw
>
> *CQL Test Case*
> {code}
> //TEST CASE #1
> BEGIN BATCH
> UPDATE users SET gender = 'm', birth_year = '1981' WHERE KEY = 'user1';
> UPDATE users SET gender = 'm', birth_year = '1982' WHERE KEY = 'user2';
> UPDATE users SET gender = 'm', birth_year = '1983' WHERE KEY = 'user3';
> APPLY BATCH
> //TEST CASE #2
> BEGIN BATCH USING CONSISTENCY ZERO
> UPDATE users SET state = 'TX' WHERE KEY = 'user1';
> UPDATE users SET state = 'TX' WHERE KEY = 'user2';
> UPDATE users SET state = 'TX' WHERE KEY = 'user3';
> APPLY BATCH
> //ERROR
> Bad Request: line 0:-1 mismatched input '' expecting K_APPLY
> {code}
> *Test Setup*
> {code}
> CREATE COLUMNFAMILY users (
> KEY varchar PRIMARY KEY,
> password varchar,
> gender varchar,
> session_token varchar,
> state varchar,
> birth_year bigint);
> INSERT INTO users (KEY, password, gender, state, birth_year) VALUES ('user1',
> 'ch@ngem3', 'f', 'CA', '1971');
> INSERT INTO users (KEY, password, gender, state, birth_year) VALUES ('user2',
> 'ch@ngem3', 'f', 'CA', '1972');
> INSERT INTO users (KEY, password, gender, state, birth_year) VALUES ('user3',
> 'ch@ngem3', 'f', 'CA', '1973');
> {code}
> *Documented Syntax*
> {panel}
> BEGIN BATCH [USING ]
> UPDATE CF1 SET name1 = value1, name2 = value2 WHERE KEY = keyname1;
> UPDATE CF1 SET name3 = value3 WHERE KEY = keyname2;
> UPDATE CF2 SET name4 = value4, name5 = value5 WHERE KEY = keyname3;
> APPLY BATCH
> {panel}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1096095 - /cassandra/branches/cassandra-0.8/drivers/py/cql/cursor.py
Author: jbellis
Date: Sat Apr 23 00:18:47 2011
New Revision: 1096095
URL: http://svn.apache.org/viewvc?rev=1096095&view=rev
Log:
more user-friendly messages for UE/TOE in cqlsh
patch by eevans and jbellis for CASSANDRA-2539
Modified:
cassandra/branches/cassandra-0.8/drivers/py/cql/cursor.py
Modified: cassandra/branches/cassandra-0.8/drivers/py/cql/cursor.py
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/drivers/py/cql/cursor.py?rev=1096095&r1=1096094&r2=1096095&view=diff
==
--- cassandra/branches/cassandra-0.8/drivers/py/cql/cursor.py (original)
+++ cassandra/branches/cassandra-0.8/drivers/py/cql/cursor.py Sat Apr 23
00:18:47 2011
@@ -26,6 +26,8 @@ from cql.cassandra.ttypes import (
Compression,
CqlResultType,
InvalidRequestException,
+UnavailableException,
+TimedOutException,
TApplicationException,
SchemaDisagreementException)
@@ -131,6 +133,11 @@ class Cursor:
raise cql.ProgrammingError("Bad Request: %s" % ire.why)
except SchemaDisagreementException, sde:
raise cql.IntegrityError("Schema versions disagree, (try again
later).")
+except UnavailableException:
+raise cql.OperationalError("Unable to complete request: one or "
+ "more nodes were unavailable.")
+except TimedOutException::
+raise cql.OperationalError("Request did not complete within
rpc_timeout.")
except TApplicationException, tapp:
raise cql.InternalError("Internal application error")
[jira] [Commented] (CASSANDRA-2538) CQL: NPE running SELECT with an IN clause
[
https://issues.apache.org/jira/browse/CASSANDRA-2538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023469#comment-13023469
]
Jonathan Ellis commented on CASSANDRA-2538:
---
Totally didn't know we support IN for DELETE. :)
Would prefer to fix by offering IN for for the other statements as well. The
Antlr doesn't look too daunting w/ DELETE as an example (knock on wood). Can
take a stab at that tomorrow.
> CQL: NPE running SELECT with an IN clause
> -
>
> Key: CASSANDRA-2538
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2538
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 0.8 beta 1
>Reporter: Cathy Daw
>Assignee: Eric Evans
>Priority: Minor
> Labels: cql
> Fix For: 0.8.0
>
> Attachments:
> v1-0001-CASSANDRA-2538-NPE-running-SELECT-with-an-IN-clause.txt
>
>
> *Test Case to Run*
> {noformat}
> cqlsh> select * from users where key in ('user2', 'user3');
> Internal application error
> {noformat}
> *Test Setup*
> {noformat}
> CREATE COLUMNFAMILY users (
> KEY varchar PRIMARY KEY,
> password varchar);
> INSERT INTO users (KEY, password) VALUES ('user1', 'ch@ngem3a');
> {noformat}
> *Log Files*
> {noformat}
> ERROR [RequestResponseStage:17] 2011-04-21 23:36:41,600
> AbstractCassandraDaemon.java (line 112) Fatal exception in thread
> Thread[RequestResponseStage:17,5,main]
> java.lang.AssertionError
> at
> org.apache.cassandra.service.ReadCallback.response(ReadCallback.java:127)
> at
> org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:49)
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:72)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:636)
> ERROR [RequestResponseStage:17] 2011-04-21 23:36:41,600
> AbstractCassandraDaemon.java (line 112) Fatal exception in thread
> Thread[RequestResponseStage:17,5,main]
> java.lang.AssertionError
> at
> org.apache.cassandra.service.ReadCallback.response(ReadCallback.java:127)
> at
> org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:49)
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:72)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:636)
> ERROR [pool-2-thread-5] 2011-04-21 23:37:12,026 Cassandra.java (line 4082)
> Internal error processing execute_cql_query
> java.lang.NullPointerException
> at org.apache.cassandra.cql.WhereClause.and(WhereClause.java:59)
> at org.apache.cassandra.cql.WhereClause.(WhereClause.java:44)
> at org.apache.cassandra.cql.CqlParser.whereClause(CqlParser.java:816)
> at
> org.apache.cassandra.cql.CqlParser.selectStatement(CqlParser.java:502)
> at org.apache.cassandra.cql.CqlParser.query(CqlParser.java:191)
> at
> org.apache.cassandra.cql.QueryProcessor.getStatement(QueryProcessor.java:834)
> at
> org.apache.cassandra.cql.QueryProcessor.process(QueryProcessor.java:463)
> at
> org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1134)
> at
> org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.process(Cassandra.java:4072)
> at
> org.apache.cassandra.thrift.Cassandra$Processor.process(Cassandra.java:2889)
> at
> org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:187)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:636)
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1096094 - in /cassandra/branches/cassandra-0.8: CHANGES.txt doc/cql/CQL.textile src/java/org/apache/cassandra/cql/CreateKeyspaceStatement.java
Author: jbellis
Date: Sat Apr 23 00:13:25 2011
New Revision: 1096094
URL: http://svn.apache.org/viewvc?rev=1096094&view=rev
Log:
validate CQL create keyspace options
patch by jbellis; reviewed by eevans for CASSANDRA-2525
Modified:
cassandra/branches/cassandra-0.8/CHANGES.txt
cassandra/branches/cassandra-0.8/doc/cql/CQL.textile
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/cql/CreateKeyspaceStatement.java
Modified: cassandra/branches/cassandra-0.8/CHANGES.txt
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/CHANGES.txt?rev=1096094&r1=1096093&r2=1096094&view=diff
==
--- cassandra/branches/cassandra-0.8/CHANGES.txt (original)
+++ cassandra/branches/cassandra-0.8/CHANGES.txt Sat Apr 23 00:13:25 2011
@@ -1,6 +1,8 @@
0.8.0-?
* fix NPE compacting index CFs (CASSANDRA-2528)
* Remove checking all column families on startup for compaction candidates
(CASSANDRA-2444)
+ * validate CQL create keyspace options (CASSANDRA-2525)
+
0.8.0-beta1
* remove Avro RPC support (CASSANDRA-926)
Modified: cassandra/branches/cassandra-0.8/doc/cql/CQL.textile
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/doc/cql/CQL.textile?rev=1096094&r1=1096093&r2=1096094&view=diff
==
--- cassandra/branches/cassandra-0.8/doc/cql/CQL.textile (original)
+++ cassandra/branches/cassandra-0.8/doc/cql/CQL.textile Sat Apr 23 00:13:25
2011
@@ -165,15 +165,13 @@ h2. CREATE KEYSPACE
_Synopsis:_
bc.
-CREATE KEYSPACE WITH replication_factor = AND strategy_class =
-[AND strategy_options. = [AND strategy_options. =
]];
+CREATE KEYSPACE WITH AND strategy_class =
+AND strategy_options. = [AND strategy_options. =
];
The @CREATE KEYSPACE@ statement creates a new top-level namespace (aka
"keyspace"). Valid names are any string constructed of alphanumeric characters
and underscores, but must begin with a letter. Properties such as replication
strategy and count are specified during creation using the following accepted
keyword arguments:
|_. keyword|_. required|_. description|
-|replication_factor|yes|Numeric argument that specifies the number of replicas
for this keyspace.|
-|strategy_class|yes|Class name to use for managing replica placement. Any of
the shipped strategies can be used by specifying the class name relative to
org.apache.cassandra.locator, others will need to be fully-qualified and
located on the classpath.|
-|strategy_options|no|Some strategies require additional arguments which can be
supplied by appending the option name to the @strategy_options@ keyword,
separated by a colon (@:@). For example, a strategy option of "DC1" with a
value of "1" would be specified as @strategy_options:DC1 = 1@.|
+|strategy_options|no|Most strategies require additional arguments which can be
supplied by appending the option name to the @strategy_options@ keyword,
separated by a colon (@:@). For example, a strategy option of "DC1" with a
value of "1" would be specified as @strategy_options:DC1 = 1@;
replication_factor for SimpleStrategy could be
@strategy_options:replication_factor=3@.|
h2. CREATE COLUMNFAMILY
Modified:
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/cql/CreateKeyspaceStatement.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/cql/CreateKeyspaceStatement.java?rev=1096094&r1=1096093&r2=1096094&view=diff
==
---
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/cql/CreateKeyspaceStatement.java
(original)
+++
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/cql/CreateKeyspaceStatement.java
Sat Apr 23 00:13:25 2011
@@ -23,6 +23,13 @@ package org.apache.cassandra.cql;
import java.util.HashMap;
import java.util.Map;
+
+import org.apache.cassandra.config.ConfigurationException;
+import org.apache.cassandra.config.DatabaseDescriptor;
+import org.apache.cassandra.locator.AbstractReplicationStrategy;
+import org.apache.cassandra.locator.IEndpointSnitch;
+import org.apache.cassandra.locator.TokenMetadata;
+import org.apache.cassandra.service.StorageService;
import org.apache.cassandra.thrift.InvalidRequestException;
/** A CREATE KEYSPACE statement parsed from a CQL query. */
@@ -68,6 +75,20 @@ public class CreateKeyspaceStatement
for (String key : attrs.keySet())
if ((key.contains(":")) && (key.startsWith("strategy_options")))
strategyOptions.put(key.split(":")[1], attrs.get(key));
+
+// trial run to let ARS validate class + per-class options
+try
+{
+AbstractReplicationStrategy.createReplicationStrategy(name,
+
AbstractReplicationStrategy.getClass(strategyClas
[jira] [Commented] (CASSANDRA-2444) Remove checkAllColumnFamilies on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-2444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023459#comment-13023459 ] Hudson commented on CASSANDRA-2444: --- Integrated in Cassandra-0.8 #35 (See [https://builds.apache.org/hudson/job/Cassandra-0.8/35/]) Remove checking all column families on startup for compaction candidates patch by goffinet; reviewed by stuhood for CASSANDRA-2444 > Remove checkAllColumnFamilies on startup > > > Key: CASSANDRA-2444 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2444 > Project: Cassandra > Issue Type: Bug >Reporter: Chris Goffinet >Assignee: Chris Goffinet >Priority: Minor > Labels: compaction > Fix For: 0.8.0, 0.8.1 > > Attachments: > 0001-CASSANDRA-2444-Remove-checking-all-column-families-o.patch > > > We've ran into many times where we do not want compaction to run right away > against CFs when booting up a node. If the node needs to compact, it will do > so at the first flush -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2538) CQL: NPE running SELECT with an IN clause
[
https://issues.apache.org/jira/browse/CASSANDRA-2538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023432#comment-13023432
]
Cathy Daw commented on CASSANDRA-2538:
--
This is just a consistency thing, but the documentation is misleading.
The DELETE documentation shows you can use an 'IN' clause:
DELETE [COLUMNS] FROM [USING ] WHERE KEY IN
(keyname1, keyname2);
The example for DELETE uses UPDATE, so I assumed 'IN' would work for
DELETE/UPDATE/SELECT.
UPDATE ... WHERE KEY IN (keyname1, keyname2)
> CQL: NPE running SELECT with an IN clause
> -
>
> Key: CASSANDRA-2538
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2538
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 0.8 beta 1
>Reporter: Cathy Daw
>Assignee: Eric Evans
>Priority: Minor
> Labels: cql
> Fix For: 0.8.0
>
> Attachments:
> v1-0001-CASSANDRA-2538-NPE-running-SELECT-with-an-IN-clause.txt
>
>
> *Test Case to Run*
> {noformat}
> cqlsh> select * from users where key in ('user2', 'user3');
> Internal application error
> {noformat}
> *Test Setup*
> {noformat}
> CREATE COLUMNFAMILY users (
> KEY varchar PRIMARY KEY,
> password varchar);
> INSERT INTO users (KEY, password) VALUES ('user1', 'ch@ngem3a');
> {noformat}
> *Log Files*
> {noformat}
> ERROR [RequestResponseStage:17] 2011-04-21 23:36:41,600
> AbstractCassandraDaemon.java (line 112) Fatal exception in thread
> Thread[RequestResponseStage:17,5,main]
> java.lang.AssertionError
> at
> org.apache.cassandra.service.ReadCallback.response(ReadCallback.java:127)
> at
> org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:49)
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:72)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:636)
> ERROR [RequestResponseStage:17] 2011-04-21 23:36:41,600
> AbstractCassandraDaemon.java (line 112) Fatal exception in thread
> Thread[RequestResponseStage:17,5,main]
> java.lang.AssertionError
> at
> org.apache.cassandra.service.ReadCallback.response(ReadCallback.java:127)
> at
> org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:49)
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:72)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:636)
> ERROR [pool-2-thread-5] 2011-04-21 23:37:12,026 Cassandra.java (line 4082)
> Internal error processing execute_cql_query
> java.lang.NullPointerException
> at org.apache.cassandra.cql.WhereClause.and(WhereClause.java:59)
> at org.apache.cassandra.cql.WhereClause.(WhereClause.java:44)
> at org.apache.cassandra.cql.CqlParser.whereClause(CqlParser.java:816)
> at
> org.apache.cassandra.cql.CqlParser.selectStatement(CqlParser.java:502)
> at org.apache.cassandra.cql.CqlParser.query(CqlParser.java:191)
> at
> org.apache.cassandra.cql.QueryProcessor.getStatement(QueryProcessor.java:834)
> at
> org.apache.cassandra.cql.QueryProcessor.process(QueryProcessor.java:463)
> at
> org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1134)
> at
> org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.process(Cassandra.java:4072)
> at
> org.apache.cassandra.thrift.Cassandra$Processor.process(Cassandra.java:2889)
> at
> org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:187)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:636)
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1096065 - in /cassandra/trunk: ./ contrib/ doc/cql/ interface/thrift/gen-java/org/apache/cassandra/thrift/ src/java/org/apache/cassandra/db/ src/java/org/apache/cassandra/service/ src/jav
Author: goffinet Date: Fri Apr 22 22:20:39 2011 New Revision: 1096065 URL: http://svn.apache.org/viewvc?rev=1096065&view=rev Log: Merge from 0.8 Modified: cassandra/trunk/ (props changed) cassandra/trunk/CHANGES.txt cassandra/trunk/contrib/ (props changed) cassandra/trunk/doc/cql/CQL.textile cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/NotFoundException.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/SuperColumn.java (props changed) cassandra/trunk/src/java/org/apache/cassandra/db/ColumnFamily.java cassandra/trunk/src/java/org/apache/cassandra/service/AbstractCassandraDaemon.java cassandra/trunk/src/java/org/apache/cassandra/tools/SSTableImport.java Propchange: cassandra/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Fri Apr 22 22:20:39 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1081914,1083000 /cassandra/branches/cassandra-0.7:1026516-1095767,1095916 /cassandra/branches/cassandra-0.7.0:1053690-1055654 -/cassandra/branches/cassandra-0.8:1090935-1095769,1095917 +/cassandra/branches/cassandra-0.8:1090935-1096064 /cassandra/tags/cassandra-0.7.0-rc3:1051699-1053689 /incubator/cassandra/branches/cassandra-0.3:774578-796573 /incubator/cassandra/branches/cassandra-0.4:810145-834239,834349-834350 Modified: cassandra/trunk/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/trunk/CHANGES.txt?rev=1096065&r1=1096064&r2=1096065&view=diff == --- cassandra/trunk/CHANGES.txt (original) +++ cassandra/trunk/CHANGES.txt Fri Apr 22 22:20:39 2011 @@ -1,3 +1,7 @@ +0.8.0-? + * fix NPE compacting index CFs (CASSANDRA-2528) + * Remove checking all column families on startup for compaction candidates (CASSANDRA-2444) + 0.8.0-beta1 * remove Avro RPC support (CASSANDRA-926) * adds support for columns that act as incr/decr counters Propchange: cassandra/trunk/contrib/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Fri Apr 22 22:20:39 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6/contrib:922689-1052356,1052358-1053452,1053454,1053456-1068009 /cassandra/branches/cassandra-0.7/contrib:1026516-1095767,1095916 /cassandra/branches/cassandra-0.7.0/contrib:1053690-1055654 -/cassandra/branches/cassandra-0.8/contrib:1090935-1095769,1095917 +/cassandra/branches/cassandra-0.8/contrib:1090935-1096064 /cassandra/tags/cassandra-0.7.0-rc3/contrib:1051699-1053689 /incubator/cassandra/branches/cassandra-0.3/contrib:774578-796573 /incubator/cassandra/branches/cassandra-0.4/contrib:810145-810987,810994-834239,834349-834350 Modified: cassandra/trunk/doc/cql/CQL.textile URL: http://svn.apache.org/viewvc/cassandra/trunk/doc/cql/CQL.textile?rev=1096065&r1=1096064&r2=1096065&view=diff == --- cassandra/trunk/doc/cql/CQL.textile (original) +++ cassandra/trunk/doc/cql/CQL.textile Fri Apr 22 22:20:39 2011 @@ -73,7 +73,7 @@ h2. UPDATE _Synopsis:_ bc. -UPDATE [USING CONSISTENCY ] +UPDATE [USING ] SET name1 = value1, name2 = value2 WHERE KEY = keyname; An @UPDATE@ is used to write one or more columns to a record in a Cassandra column family. No results are returned. Propchange: cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Fri Apr 22 22:20:39 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:922689-1052356,1052358-1053452,1053454,1053456-1081914,1083000 /cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1095767,1095916 /cassandra/branches/cassandra-0.7.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1053690-1055654 -/cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1090935-1095769,1095917 +/cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1090935-1096064 /cassandra/tags/cassandra-0.7.0-rc3/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1051699-1053689 /incubator/cassandra/branches/cassandra-0.3/interface/gen-java/org/apache/ca
svn commit: r1096064 - /cassandra/branches/cassandra-0.8/CHANGES.txt
Author: goffinet Date: Fri Apr 22 22:18:46 2011 New Revision: 1096064 URL: http://svn.apache.org/viewvc?rev=1096064&view=rev Log: Updated CHANGES.txt Modified: cassandra/branches/cassandra-0.8/CHANGES.txt Modified: cassandra/branches/cassandra-0.8/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/CHANGES.txt?rev=1096064&r1=1096063&r2=1096064&view=diff == --- cassandra/branches/cassandra-0.8/CHANGES.txt (original) +++ cassandra/branches/cassandra-0.8/CHANGES.txt Fri Apr 22 22:18:46 2011 @@ -1,6 +1,6 @@ 0.8.0-? * fix NPE compacting index CFs (CASSANDRA-2528) - + * Remove checking all column families on startup for compaction candidates (CASSANDRA-2444) 0.8.0-beta1 * remove Avro RPC support (CASSANDRA-926)
svn commit: r1096063 - /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/AbstractCassandraDaemon.java
Author: goffinet
Date: Fri Apr 22 22:18:04 2011
New Revision: 1096063
URL: http://svn.apache.org/viewvc?rev=1096063&view=rev
Log:
Remove checking all column families on startup for compaction candidates
patch by goffinet; reviewed by stuhood for CASSANDRA-2444
Modified:
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/AbstractCassandraDaemon.java
Modified:
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/AbstractCassandraDaemon.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/AbstractCassandraDaemon.java?rev=1096063&r1=1096062&r2=1096063&view=diff
==
---
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/AbstractCassandraDaemon.java
(original)
+++
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/AbstractCassandraDaemon.java
Fri Apr 22 22:18:04 2011
@@ -169,10 +169,9 @@ public abstract class AbstractCassandraD
logger.warn("Unable to start GCInspector (currently only supported
on the Sun JVM)");
}
-// replay the log if necessary and check for compaction candidates
+// replay the log if necessary
CommitLog.recover();
-CompactionManager.instance.checkAllColumnFamilies();
-
+
// check to see if CL.recovery modified the lastMigrationId. if it
did, we need to re apply migrations. this isn't
// the same as merely reloading the schema (which wouldn't perform
file deletion after a DROP). The solution
// is to read those migrations from disk and apply them.
[jira] [Updated] (CASSANDRA-2444) Remove checkAllColumnFamilies on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-2444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet updated CASSANDRA-2444: -- Attachment: 0001-CASSANDRA-2444-Remove-checking-all-column-families-o.patch > Remove checkAllColumnFamilies on startup > > > Key: CASSANDRA-2444 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2444 > Project: Cassandra > Issue Type: Bug >Reporter: Chris Goffinet >Assignee: Chris Goffinet >Priority: Minor > Labels: compaction > Fix For: 0.8.1 > > Attachments: > 0001-CASSANDRA-2444-Remove-checking-all-column-families-o.patch > > > We've ran into many times where we do not want compaction to run right away > against CFs when booting up a node. If the node needs to compact, it will do > so at the first flush -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2444) Remove checkAllColumnFamilies on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-2444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet updated CASSANDRA-2444: -- Attachment: (was: 0001-CASSANDRA-2444-Provide-an-option-to-enable-disable-c.patch) > Remove checkAllColumnFamilies on startup > > > Key: CASSANDRA-2444 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2444 > Project: Cassandra > Issue Type: Bug >Reporter: Chris Goffinet >Assignee: Chris Goffinet >Priority: Minor > Labels: compaction > Fix For: 0.8.1 > > Attachments: > 0001-CASSANDRA-2444-Remove-checking-all-column-families-o.patch > > > We've ran into many times where we do not want compaction to run right away > against CFs when booting up a node. If the node needs to compact, it will do > so at the first flush -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2444) Remove checkAllColumnFamilies on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-2444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet updated CASSANDRA-2444: -- Description: We've ran into many times where we do not want compaction to run right away against CFs when booting up a node. If the node needs to compact, it will do so at the first flush (was: We've ran into many times where we do not want compaction to run right away against CFs when booting up a node. I propose we make that an option in the config, so operators do not have to take the penalty of compacting right away, and can return the node as close to working state as possible.) Summary: Remove checkAllColumnFamilies on startup (was: An option to disable compaction on startup) > Remove checkAllColumnFamilies on startup > > > Key: CASSANDRA-2444 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2444 > Project: Cassandra > Issue Type: Bug >Reporter: Chris Goffinet >Assignee: Chris Goffinet >Priority: Minor > Labels: compaction > Fix For: 0.8.1 > > Attachments: > 0001-CASSANDRA-2444-Provide-an-option-to-enable-disable-c.patch > > > We've ran into many times where we do not want compaction to run right away > against CFs when booting up a node. If the node needs to compact, it will do > so at the first flush -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2539) CQL: cqlsh does shows Exception, but not error message when running truncate while a node is down.
[
https://issues.apache.org/jira/browse/CASSANDRA-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023424#comment-13023424
]
Eric Evans commented on CASSANDRA-2539:
---
+1
> CQL: cqlsh does shows Exception, but not error message when running truncate
> while a node is down.
> ---
>
> Key: CASSANDRA-2539
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2539
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 0.8.0
>Reporter: Cathy Daw
>Assignee: Eric Evans
>Priority: Trivial
> Labels: cql
> Attachments: 2539-v3.txt,
> v2-0001-CASSANDRA-2539-print-friendlier-message-for-Unavailabl.txt
>
>
> This is really just a usability bug, but it would nice to bubble the error
> message that is printed in the log file up to the interface.
> *cqlsh output*
> {noformat}
> cqlsh> truncate users;
> Exception: UnavailableException()
> {noformat}
> *log file error*
> {noformat}
> INFO [pool-2-thread-5] 2011-04-21 23:53:30,466 StorageProxy.java (line 1021)
> Cannot perform truncate, some hosts are down
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1096056 - in /cassandra/site: publish/download/index.html src/settings.py
Author: eevans Date: Fri Apr 22 21:48:39 2011 New Revision: 1096056 URL: http://svn.apache.org/viewvc?rev=1096056&view=rev Log: update site for 0.8 beta1 release Modified: cassandra/site/publish/download/index.html cassandra/site/src/settings.py Modified: cassandra/site/publish/download/index.html URL: http://svn.apache.org/viewvc/cassandra/site/publish/download/index.html?rev=1096056&r1=1096055&r2=1096056&view=diff == --- cassandra/site/publish/download/index.html (original) +++ cassandra/site/publish/download/index.html Fri Apr 22 21:48:39 2011 @@ -102,6 +102,26 @@ + + The latest development release is 0.8.0-beta1 (released on + 2011-04-22). + + + + +http://www.apache.org/dyn/closer.cgi?path=/cassandra/0.8.0/apache-cassandra-0.8.0-beta1-bin.tar.gz";>apache-cassandra-0.8.0-beta1-bin.tar.gz +[http://www.apache.org/dist/cassandra/0.8.0/apache-cassandra-0.8.0-beta1-bin.tar.gz.asc";>PGP] +[http://www.apache.org/dist/cassandra/0.8.0/apache-cassandra-0.8.0-beta1-bin.tar.gz.md5";>MD5] +[http://www.apache.org/dist/cassandra/0.8.0/apache-cassandra-0.8.0-beta1-bin.tar.gz.sha";>SHA1] + + +http://www.apache.org/dyn/closer.cgi?path=/cassandra/0.8.0/apache-cassandra-0.8.0-beta1-src.tar.gz";>apache-cassandra-0.8.0-beta1-src.tar.gz +[http://www.apache.org/dist/cassandra/0.8.0/apache-cassandra-0.8.0-beta1-src.tar.gz.asc";>PGP] +[http://www.apache.org/dist/cassandra/0.8.0/apache-cassandra-0.8.0-beta1-src.tar.gz.md5";>MD5] +[http://www.apache.org/dist/cassandra/0.8.0/apache-cassandra-0.8.0-beta1-src.tar.gz.sha";>SHA1] + + + When downloading from a mirror, please be sure to verify the checksums Modified: cassandra/site/src/settings.py URL: http://svn.apache.org/viewvc/cassandra/site/src/settings.py?rev=1096056&r1=1096055&r2=1096056&view=diff == --- cassandra/site/src/settings.py (original) +++ cassandra/site/src/settings.py Fri Apr 22 21:48:39 2011 @@ -97,9 +97,9 @@ class CassandraDef(object): oldstable_exists = True stable_version = '0.7.4' stable_release_date = '2011-03-15' -devel_version = '0.7.0-rc4' -devel_release_date = '2011-01-01' -devel_exists = False +devel_version = '0.8.0-beta1' +devel_release_date = '2011-04-22' +devel_exists = True _apache_base_url = 'http://www.apache.org' _svn_base_url = 'https://svn.apache.org/repos/asf' _apache_path = 'cassandra'
[jira] [Updated] (CASSANDRA-2539) CQL: cqlsh does shows Exception, but not error message when running truncate while a node is down.
[
https://issues.apache.org/jira/browse/CASSANDRA-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-2539:
--
Attachment: 2539-v3.txt
v3 also adds a wrapper for TimedOutException
> CQL: cqlsh does shows Exception, but not error message when running truncate
> while a node is down.
> ---
>
> Key: CASSANDRA-2539
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2539
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 0.8.0
>Reporter: Cathy Daw
>Assignee: Eric Evans
>Priority: Trivial
> Labels: cql
> Attachments: 2539-v3.txt,
> v2-0001-CASSANDRA-2539-print-friendlier-message-for-Unavailabl.txt
>
>
> This is really just a usability bug, but it would nice to bubble the error
> message that is printed in the log file up to the interface.
> *cqlsh output*
> {noformat}
> cqlsh> truncate users;
> Exception: UnavailableException()
> {noformat}
> *log file error*
> {noformat}
> INFO [pool-2-thread-5] 2011-04-21 23:53:30,466 StorageProxy.java (line 1021)
> Cannot perform truncate, some hosts are down
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2527) Add ability to snapshot data as input to hadoop jobs
[ https://issues.apache.org/jira/browse/CASSANDRA-2527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023391#comment-13023391 ] Jeremy Hanna commented on CASSANDRA-2527: - I remember the acunu guys talking about having point-in-time versioning for sstables. That would be a helpful feature for doing something like this. > Add ability to snapshot data as input to hadoop jobs > > > Key: CASSANDRA-2527 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2527 > Project: Cassandra > Issue Type: Improvement >Reporter: Jeremy Hanna > Labels: hadoop > > It is desirable to have immutable inputs to hadoop jobs for the duration of > the job. That way re-execution of individual tasks do not alter the output. > One way to accomplish this would be to snapshot the data that is used as > input to a job. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2537) CQL: Support for batch insert/delete
[
https://issues.apache.org/jira/browse/CASSANDRA-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023389#comment-13023389
]
Jonathan Ellis commented on CASSANDRA-2537:
---
bq. Lets make this an Improvement and change version to 0.8.1 "
+1
bq. My assumption is that we allow batch processing to speed performance
Partially, but grouping updates for idempotence is more important:
http://maxgrinev.com/2010/07/12/update-idempotency-why-it-is-important-in-cassandra-applications-2/
> CQL: Support for batch insert/delete
>
>
> Key: CASSANDRA-2537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2537
> Project: Cassandra
> Issue Type: New Feature
>Affects Versions: 0.8 beta 1
> Environment: 3-node Centos 5.5 cluster running 0.8 build from apr20.
>Reporter: Cathy Daw
>Assignee: Pavel Yaskevich
>Priority: Minor
> Labels: cql
> Fix For: 0.8.1
>
>
> *Test Case To Run*
> {code}
> // Setup
> CREATE COLUMNFAMILY users (
> KEY varchar PRIMARY KEY,
> password varchar);
> //Batch Insert
> BEGIN BATCH USING QUORUM
> INSERT INTO users (KEY, password) VALUES ('user2', 'ch@ngem3b');
> INSERT INTO users (KEY, password) VALUES ('user3', 'ch@ngem3c');
> APPLY BATCH
> {code}
> *Actual Behavior*
> {code}
> cqlsh> BEGIN BATCH USING QUORUM
>... INSERT INTO users (KEY, password) VALUES ('user2', 'ch@ngem3b');
> Bad Request: line 0:-1 mismatched input '' expecting K_APPLY
> {code}
> *Documentation Sample*
> {code}
> BEGIN BATCH [USING ]
> UPDATE CF1 SET name1 = value1, name2 = value2 WHERE KEY = keyname1;
> UPDATE CF1 SET name3 = value3 WHERE KEY = keyname2;
> UPDATE CF2 SET name4 = value4, name5 = value5 WHERE KEY = keyname3;
> APPLY BATCH
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2525) CQL: create keyspace does not the replication factor argument and allows invalid sql to pass thru
[
https://issues.apache.org/jira/browse/CASSANDRA-2525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023380#comment-13023380
]
Eric Evans commented on CASSANDRA-2525:
---
+1
> CQL: create keyspace does not the replication factor argument and allows
> invalid sql to pass thru
> -
>
> Key: CASSANDRA-2525
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2525
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 0.8 beta 1
> Environment: Cluster: 3 node Rackspace cluster running Centos 5.5.
> Build:
> https://builds.apache.org/hudson/job/Cassandra/859/artifact/cassandra/build/apache-cassandra-2011-04-20_10-01-29-bin.tar.gz
>Reporter: Cathy Daw
>Assignee: Jonathan Ellis
>Priority: Critical
> Labels: cql
> Fix For: 0.8.0
>
> Attachments: 2525.txt
>
>
> I ran the following SQL in cqlsh and immediately received a socket closed
> error. After that point, I couldn't run nodetool, and then got an exception
> starting up the cluster.
> Please Note: The following syntax is valid in 0.74 but invalid in 0.8.
> The 0.8 cassandra-cli errors on the following statement, so the resolution of
> the bug is to have cqlsh block this incorrect syntax.
> {code}
> create keyspace testcli with replication_factor=1
> and placement_strategy = 'org.apache.cassandra.locator.SimpleStrategy';
> {code}
> {code}
> CREATE KEYSPACE testcql with replication_factor = 1 and strategy_class =
> 'org.apache.cassandra.locator.SimpleStrategy';
> {code}
> {code}
> ERROR 01:29:26,989 Exception encountered during startup.
> java.lang.RuntimeException:
> org.apache.cassandra.config.ConfigurationException: SimpleStrategy requires a
> replication_factor strategy option.
> at org.apache.cassandra.db.Table.(Table.java:278)
> at org.apache.cassandra.db.Table.open(Table.java:110)
> at
> org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:160)
> at
> org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:314)
> at
> org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:80)
> Caused by: org.apache.cassandra.config.ConfigurationException: SimpleStrategy
> requires a replication_factor strategy option.
> at
> org.apache.cassandra.locator.SimpleStrategy.validateOptions(SimpleStrategy.java:79)
> at
> org.apache.cassandra.locator.AbstractReplicationStrategy.createReplicationStrategy(AbstractReplicationStrategy.java:262)
> at
> org.apache.cassandra.db.Table.createReplicationStrategy(Table.java:328)
> at org.apache.cassandra.db.Table.(Table.java:274)
> ... 4 more
> Exception encountered during startup.
> java.lang.RuntimeException:
> org.apache.cassandra.config.ConfigurationException: SimpleStrategy requires a
> replication_factor strategy option.
> at org.apache.cassandra.db.Table.(Table.java:278)
> at org.apache.cassandra.db.Table.open(Table.java:110)
> at
> org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:160)
> at
> org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:314)
> at
> org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:80)
> Caused by: org.apache.cassandra.config.ConfigurationException: SimpleStrategy
> requires a replication_factor strategy option.
> at
> org.apache.cassandra.locator.SimpleStrategy.validateOptions(SimpleStrategy.java:79)
> at
> org.apache.cassandra.locator.AbstractReplicationStrategy.createReplicationStrategy(AbstractReplicationStrategy.java:262)
> at
> org.apache.cassandra.db.Table.createReplicationStrategy(Table.java:328)
> at org.apache.cassandra.db.Table.(Table.java:274)
> ... 4 more
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1096011 - /cassandra/tags/cassandra-0.8.0-beta1/
Author: eevans Date: Fri Apr 22 20:06:58 2011 New Revision: 1096011 URL: http://svn.apache.org/viewvc?rev=1096011&view=rev Log: tagging 0.8.0 beta1 Added: cassandra/tags/cassandra-0.8.0-beta1/ - copied from r1095239, cassandra/branches/cassandra-0.8/
[jira] [Updated] (CASSANDRA-2539) CQL: cqlsh does shows Exception, but not error message when running truncate while a node is down.
[
https://issues.apache.org/jira/browse/CASSANDRA-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Evans updated CASSANDRA-2539:
--
Attachment: (was:
v1-0001-CASSANDRA-2539-print-friendlier-message-for-Unavailabl.txt)
> CQL: cqlsh does shows Exception, but not error message when running truncate
> while a node is down.
> ---
>
> Key: CASSANDRA-2539
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2539
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 0.8.0
>Reporter: Cathy Daw
>Priority: Trivial
> Labels: cql
> Attachments:
> v2-0001-CASSANDRA-2539-print-friendlier-message-for-Unavailabl.txt
>
>
> This is really just a usability bug, but it would nice to bubble the error
> message that is printed in the log file up to the interface.
> *cqlsh output*
> {noformat}
> cqlsh> truncate users;
> Exception: UnavailableException()
> {noformat}
> *log file error*
> {noformat}
> INFO [pool-2-thread-5] 2011-04-21 23:53:30,466 StorageProxy.java (line 1021)
> Cannot perform truncate, some hosts are down
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2539) CQL: cqlsh does shows Exception, but not error message when running truncate while a node is down.
[
https://issues.apache.org/jira/browse/CASSANDRA-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Evans updated CASSANDRA-2539:
--
Assignee: Eric Evans
> CQL: cqlsh does shows Exception, but not error message when running truncate
> while a node is down.
> ---
>
> Key: CASSANDRA-2539
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2539
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 0.8.0
>Reporter: Cathy Daw
>Assignee: Eric Evans
>Priority: Trivial
> Labels: cql
> Attachments:
> v2-0001-CASSANDRA-2539-print-friendlier-message-for-Unavailabl.txt
>
>
> This is really just a usability bug, but it would nice to bubble the error
> message that is printed in the log file up to the interface.
> *cqlsh output*
> {noformat}
> cqlsh> truncate users;
> Exception: UnavailableException()
> {noformat}
> *log file error*
> {noformat}
> INFO [pool-2-thread-5] 2011-04-21 23:53:30,466 StorageProxy.java (line 1021)
> Cannot perform truncate, some hosts are down
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2539) CQL: cqlsh does shows Exception, but not error message when running truncate while a node is down.
[
https://issues.apache.org/jira/browse/CASSANDRA-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Evans updated CASSANDRA-2539:
--
Attachment:
v1-0001-CASSANDRA-2539-print-friendlier-message-for-Unavailabl.txt
> CQL: cqlsh does shows Exception, but not error message when running truncate
> while a node is down.
> ---
>
> Key: CASSANDRA-2539
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2539
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 0.8.0
>Reporter: Cathy Daw
>Priority: Trivial
> Labels: cql
> Attachments:
> v1-0001-CASSANDRA-2539-print-friendlier-message-for-Unavailabl.txt,
> v2-0001-CASSANDRA-2539-print-friendlier-message-for-Unavailabl.txt
>
>
> This is really just a usability bug, but it would nice to bubble the error
> message that is printed in the log file up to the interface.
> *cqlsh output*
> {noformat}
> cqlsh> truncate users;
> Exception: UnavailableException()
> {noformat}
> *log file error*
> {noformat}
> INFO [pool-2-thread-5] 2011-04-21 23:53:30,466 StorageProxy.java (line 1021)
> Cannot perform truncate, some hosts are down
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2539) CQL: cqlsh does shows Exception, but not error message when running truncate while a node is down.
[
https://issues.apache.org/jira/browse/CASSANDRA-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Evans updated CASSANDRA-2539:
--
Attachment:
v2-0001-CASSANDRA-2539-print-friendlier-message-for-Unavailabl.txt
> CQL: cqlsh does shows Exception, but not error message when running truncate
> while a node is down.
> ---
>
> Key: CASSANDRA-2539
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2539
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 0.8.0
>Reporter: Cathy Daw
>Priority: Trivial
> Labels: cql
> Attachments:
> v1-0001-CASSANDRA-2539-print-friendlier-message-for-Unavailabl.txt,
> v2-0001-CASSANDRA-2539-print-friendlier-message-for-Unavailabl.txt
>
>
> This is really just a usability bug, but it would nice to bubble the error
> message that is printed in the log file up to the interface.
> *cqlsh output*
> {noformat}
> cqlsh> truncate users;
> Exception: UnavailableException()
> {noformat}
> *log file error*
> {noformat}
> INFO [pool-2-thread-5] 2011-04-21 23:53:30,466 StorageProxy.java (line 1021)
> Cannot perform truncate, some hosts are down
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2537) CQL: Support for batch insert/delete
[
https://issues.apache.org/jira/browse/CASSANDRA-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cathy Daw updated CASSANDRA-2537:
-
Fix Version/s: (was: 0.8.0)
0.8.1
Issue Type: New Feature (was: Bug)
Summary: CQL: Support for batch insert/delete (was: CQL: Error
performing batch insert)
> CQL: Support for batch insert/delete
>
>
> Key: CASSANDRA-2537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2537
> Project: Cassandra
> Issue Type: New Feature
>Affects Versions: 0.8 beta 1
> Environment: 3-node Centos 5.5 cluster running 0.8 build from apr20.
>Reporter: Cathy Daw
>Assignee: Pavel Yaskevich
>Priority: Minor
> Labels: cql
> Fix For: 0.8.1
>
>
> *Test Case To Run*
> {code}
> // Setup
> CREATE COLUMNFAMILY users (
> KEY varchar PRIMARY KEY,
> password varchar);
> //Batch Insert
> BEGIN BATCH USING QUORUM
> INSERT INTO users (KEY, password) VALUES ('user2', 'ch@ngem3b');
> INSERT INTO users (KEY, password) VALUES ('user3', 'ch@ngem3c');
> APPLY BATCH
> {code}
> *Actual Behavior*
> {code}
> cqlsh> BEGIN BATCH USING QUORUM
>... INSERT INTO users (KEY, password) VALUES ('user2', 'ch@ngem3b');
> Bad Request: line 0:-1 mismatched input '' expecting K_APPLY
> {code}
> *Documentation Sample*
> {code}
> BEGIN BATCH [USING ]
> UPDATE CF1 SET name1 = value1, name2 = value2 WHERE KEY = keyname1;
> UPDATE CF1 SET name3 = value3 WHERE KEY = keyname2;
> UPDATE CF2 SET name4 = value4, name5 = value5 WHERE KEY = keyname3;
> APPLY BATCH
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2537) CQL: Error performing batch insert
[
https://issues.apache.org/jira/browse/CASSANDRA-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023347#comment-13023347
]
Pavel Yaskevich commented on CASSANDRA-2537:
Lets make this an Improvement and change version to 0.8.1 "add support for
INSERT/DELETE to the BATCH statement"?
> CQL: Error performing batch insert
> --
>
> Key: CASSANDRA-2537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2537
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 0.8 beta 1
> Environment: 3-node Centos 5.5 cluster running 0.8 build from apr20.
>Reporter: Cathy Daw
>Assignee: Pavel Yaskevich
>Priority: Minor
> Labels: cql
> Fix For: 0.8.0
>
>
> *Test Case To Run*
> {code}
> // Setup
> CREATE COLUMNFAMILY users (
> KEY varchar PRIMARY KEY,
> password varchar);
> //Batch Insert
> BEGIN BATCH USING QUORUM
> INSERT INTO users (KEY, password) VALUES ('user2', 'ch@ngem3b');
> INSERT INTO users (KEY, password) VALUES ('user3', 'ch@ngem3c');
> APPLY BATCH
> {code}
> *Actual Behavior*
> {code}
> cqlsh> BEGIN BATCH USING QUORUM
>... INSERT INTO users (KEY, password) VALUES ('user2', 'ch@ngem3b');
> Bad Request: line 0:-1 mismatched input '' expecting K_APPLY
> {code}
> *Documentation Sample*
> {code}
> BEGIN BATCH [USING ]
> UPDATE CF1 SET name1 = value1, name2 = value2 WHERE KEY = keyname1;
> UPDATE CF1 SET name3 = value3 WHERE KEY = keyname2;
> UPDATE CF2 SET name4 = value4, name5 = value5 WHERE KEY = keyname3;
> APPLY BATCH
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2537) CQL: Error performing batch insert
[
https://issues.apache.org/jira/browse/CASSANDRA-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023345#comment-13023345
]
Eric Evans commented on CASSANDRA-2537:
---
There is no support for batch INSERT or DELETE (UPDATE is identical to INSERT
semantically so that one isn't about capability per se), but it would be
reasonable to add them, (read: for a version > 0.8.0).
Rollback is another matter entirely. A BATCH operation in CQL is decidedly not
the same as a transaction, and transactions are going to require a whole lot
more than language support.
> CQL: Error performing batch insert
> --
>
> Key: CASSANDRA-2537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2537
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 0.8 beta 1
> Environment: 3-node Centos 5.5 cluster running 0.8 build from apr20.
>Reporter: Cathy Daw
>Assignee: Pavel Yaskevich
>Priority: Minor
> Labels: cql
> Fix For: 0.8.0
>
>
> *Test Case To Run*
> {code}
> // Setup
> CREATE COLUMNFAMILY users (
> KEY varchar PRIMARY KEY,
> password varchar);
> //Batch Insert
> BEGIN BATCH USING QUORUM
> INSERT INTO users (KEY, password) VALUES ('user2', 'ch@ngem3b');
> INSERT INTO users (KEY, password) VALUES ('user3', 'ch@ngem3c');
> APPLY BATCH
> {code}
> *Actual Behavior*
> {code}
> cqlsh> BEGIN BATCH USING QUORUM
>... INSERT INTO users (KEY, password) VALUES ('user2', 'ch@ngem3b');
> Bad Request: line 0:-1 mismatched input '' expecting K_APPLY
> {code}
> *Documentation Sample*
> {code}
> BEGIN BATCH [USING ]
> UPDATE CF1 SET name1 = value1, name2 = value2 WHERE KEY = keyname1;
> UPDATE CF1 SET name3 = value3 WHERE KEY = keyname2;
> UPDATE CF2 SET name4 = value4, name5 = value5 WHERE KEY = keyname3;
> APPLY BATCH
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2537) CQL: Error performing batch insert
[
https://issues.apache.org/jira/browse/CASSANDRA-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023328#comment-13023328
]
Pavel Yaskevich commented on CASSANDRA-2537:
I agree about this, I would also like to hear Eric's opinion on this, I will
ping him to comment.
> CQL: Error performing batch insert
> --
>
> Key: CASSANDRA-2537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2537
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 0.8 beta 1
> Environment: 3-node Centos 5.5 cluster running 0.8 build from apr20.
>Reporter: Cathy Daw
>Assignee: Pavel Yaskevich
>Priority: Minor
> Labels: cql
> Fix For: 0.8.0
>
>
> *Test Case To Run*
> {code}
> // Setup
> CREATE COLUMNFAMILY users (
> KEY varchar PRIMARY KEY,
> password varchar);
> //Batch Insert
> BEGIN BATCH USING QUORUM
> INSERT INTO users (KEY, password) VALUES ('user2', 'ch@ngem3b');
> INSERT INTO users (KEY, password) VALUES ('user3', 'ch@ngem3c');
> APPLY BATCH
> {code}
> *Actual Behavior*
> {code}
> cqlsh> BEGIN BATCH USING QUORUM
>... INSERT INTO users (KEY, password) VALUES ('user2', 'ch@ngem3b');
> Bad Request: line 0:-1 mismatched input '' expecting K_APPLY
> {code}
> *Documentation Sample*
> {code}
> BEGIN BATCH [USING ]
> UPDATE CF1 SET name1 = value1, name2 = value2 WHERE KEY = keyname1;
> UPDATE CF1 SET name3 = value3 WHERE KEY = keyname2;
> UPDATE CF2 SET name4 = value4, name5 = value5 WHERE KEY = keyname3;
> APPLY BATCH
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2537) CQL: Error performing batch insert
[
https://issues.apache.org/jira/browse/CASSANDRA-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023325#comment-13023325
]
Cathy Daw commented on CASSANDRA-2537:
--
It seems like we probably need to change this bug to an improvement or new
feature to support batch inserts, batch deletes and the ability to rollback or
abort batch. My assumption is that we allow batch processing to speed
performance (batch writes being more efficient than single row writes), and not
for transactionality.
> CQL: Error performing batch insert
> --
>
> Key: CASSANDRA-2537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2537
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 0.8 beta 1
> Environment: 3-node Centos 5.5 cluster running 0.8 build from apr20.
>Reporter: Cathy Daw
>Assignee: Pavel Yaskevich
>Priority: Minor
> Labels: cql
> Fix For: 0.8.0
>
>
> *Test Case To Run*
> {code}
> // Setup
> CREATE COLUMNFAMILY users (
> KEY varchar PRIMARY KEY,
> password varchar);
> //Batch Insert
> BEGIN BATCH USING QUORUM
> INSERT INTO users (KEY, password) VALUES ('user2', 'ch@ngem3b');
> INSERT INTO users (KEY, password) VALUES ('user3', 'ch@ngem3c');
> APPLY BATCH
> {code}
> *Actual Behavior*
> {code}
> cqlsh> BEGIN BATCH USING QUORUM
>... INSERT INTO users (KEY, password) VALUES ('user2', 'ch@ngem3b');
> Bad Request: line 0:-1 mismatched input '' expecting K_APPLY
> {code}
> *Documentation Sample*
> {code}
> BEGIN BATCH [USING ]
> UPDATE CF1 SET name1 = value1, name2 = value2 WHERE KEY = keyname1;
> UPDATE CF1 SET name3 = value3 WHERE KEY = keyname2;
> UPDATE CF2 SET name4 = value4, name5 = value5 WHERE KEY = keyname3;
> APPLY BATCH
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2540) Data reads by default
[
https://issues.apache.org/jira/browse/CASSANDRA-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stu Hood updated CASSANDRA-2540:
Labels: (was: ponies)
> Data reads by default
> -
>
> Key: CASSANDRA-2540
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2540
> Project: Cassandra
> Issue Type: Wish
>Reporter: Stu Hood
>Priority: Minor
>
> The intention of digest vs data reads is to save bandwidth in the read path
> at the cost of latency, but I expect that this has been a premature
> optimization.
> * Data requested by a read will often be within an order of magnitude of the
> digest size, and a failed digest means extra roundtrips, more bandwidth
> * The [digest reads but not your data
> read|https://issues.apache.org/jira/browse/CASSANDRA-2282?focusedCommentId=13004656&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13004656]
> problem means failing QUORUM reads because a single node is unavailable, and
> would require eagerly re-requesting at some fraction of your timeout
> * Saving bandwidth in cross datacenter usecases comes at huge cost to
> latency, but since both constraints change proportionally (enough), the
> tradeoff is not clear
> Some options:
> # Add an option to use digest reads
> # Remove digest reads entirely (and/or punt and make them a runtime
> optimization based on data size in the future)
> # Continue to use digest reads, but send them to {{N - R}} nodes for
> (somewhat) more predicatable behavior with QUORUM
> \\
> The outcome of data-reads-by-default should be significantly improved
> latency, with a moderate increase in bandwidth usage for large reads.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2537) CQL: Error performing batch insert
[
https://issues.apache.org/jira/browse/CASSANDRA-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023318#comment-13023318
]
Pavel Yaskevich commented on CASSANDRA-2537:
Cathy: I don't see in the grammar that BATCH supports any operation expect
UPDATE right now. I don't think it's possible to rollback any operation if
that's what you mean...
> CQL: Error performing batch insert
> --
>
> Key: CASSANDRA-2537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2537
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 0.8 beta 1
> Environment: 3-node Centos 5.5 cluster running 0.8 build from apr20.
>Reporter: Cathy Daw
>Assignee: Pavel Yaskevich
>Priority: Minor
> Labels: cql
> Fix For: 0.8.0
>
>
> *Test Case To Run*
> {code}
> // Setup
> CREATE COLUMNFAMILY users (
> KEY varchar PRIMARY KEY,
> password varchar);
> //Batch Insert
> BEGIN BATCH USING QUORUM
> INSERT INTO users (KEY, password) VALUES ('user2', 'ch@ngem3b');
> INSERT INTO users (KEY, password) VALUES ('user3', 'ch@ngem3c');
> APPLY BATCH
> {code}
> *Actual Behavior*
> {code}
> cqlsh> BEGIN BATCH USING QUORUM
>... INSERT INTO users (KEY, password) VALUES ('user2', 'ch@ngem3b');
> Bad Request: line 0:-1 mismatched input '' expecting K_APPLY
> {code}
> *Documentation Sample*
> {code}
> BEGIN BATCH [USING ]
> UPDATE CF1 SET name1 = value1, name2 = value2 WHERE KEY = keyname1;
> UPDATE CF1 SET name3 = value3 WHERE KEY = keyname2;
> UPDATE CF2 SET name4 = value4, name5 = value5 WHERE KEY = keyname3;
> APPLY BATCH
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2544) build produces unneeded/confusing checksum files
[ https://issues.apache.org/jira/browse/CASSANDRA-2544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Evans updated CASSANDRA-2544: -- Reviewer: slebresne > build produces unneeded/confusing checksum files > > > Key: CASSANDRA-2544 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2544 > Project: Cassandra > Issue Type: Bug > Components: Packaging, Tools >Affects Versions: 0.7.5 >Reporter: Eric Evans >Assignee: Stephen Connolly > > The artifacts recently created for 0.7.5 (vote pending), have checksum files > generated for the signatures (apache-cassandra-0.7.5-bin.tar.gz.asc.md5, > apache-cassandra-0.7.5-bin.tar.gz.asc.sha1, > apache-cassandra-0.7.5-src.tar.gz.asc.md5, and > apache-cassandra-0.7.5-src.tar.gz.asc.sha1). These should be removed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2544) build produces unneeded/confusing checksum files
build produces unneeded/confusing checksum files Key: CASSANDRA-2544 URL: https://issues.apache.org/jira/browse/CASSANDRA-2544 Project: Cassandra Issue Type: Bug Components: Packaging, Tools Affects Versions: 0.7.5 Reporter: Eric Evans Assignee: Stephen Connolly The artifacts recently created for 0.7.5 (vote pending), have checksum files generated for the signatures (apache-cassandra-0.7.5-bin.tar.gz.asc.md5, apache-cassandra-0.7.5-bin.tar.gz.asc.sha1, apache-cassandra-0.7.5-src.tar.gz.asc.md5, and apache-cassandra-0.7.5-src.tar.gz.asc.sha1). These should be removed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2543) Node not responding, bringing down cluster, marked as up
[ https://issues.apache.org/jira/browse/CASSANDRA-2543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023298#comment-13023298 ] Thibaut commented on CASSANDRA-2543: I stopped all java programs and restarted the cluster and increased the heap size to 5.5 gig. All my table have a memtable limit of 32MB and I only have about 20 tables with 2 column families in each table. Executing a manual compactation or just waiting will return the following error: ERROR [ReadStage:24] 2011-04-22 19:30:58,330 AbstractCassandraDaemon.java (line 112) Fatal exception in thread Thread[ReadStage:24,5,main] java.lang.OutOfMemoryError: Java heap space at org.apache.cassandra.io.util.BufferedRandomAccessFile.(BufferedRandomAccessFile.java:123) at org.apache.cassandra.io.util.BufferedRandomAccessFile.(BufferedRandomAccessFile.java:108) at org.apache.cassandra.io.util.BufferedRandomAccessFile.(BufferedRandomAccessFile.java:93) at org.apache.cassandra.io.sstable.SSTableScanner.(SSTableScanner.java:74) at org.apache.cassandra.io.sstable.SSTableReader.getScanner(SSTableReader.java:548) at org.apache.cassandra.db.RowIteratorFactory.getIterator(RowIteratorFactory.java:95) at org.apache.cassandra.db.ColumnFamilyStore.getRangeSlice(ColumnFamilyStore.java:1425) at org.apache.cassandra.service.RangeSliceVerbHandler.doVerb(RangeSliceVerbHandler.java:49) at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:72) 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) One table has 778 intermediate tables and won't compact. (Each table has about the size of the memtable flush limit). Only the first one are biggers (e.g 5x 19 GB) -rw-r--r-- 1 root root 18M 2011-04-22 17:07 table_userentries-f-42142-Data.db -rw-r--r-- 1 root root 17M 2011-04-22 17:10 table_userentries-f-42143-Data.db -rw-r--r-- 1 root root 17M 2011-04-22 17:12 table_userentries-f-42144-Data.db -rw-r--r-- 1 root root 17M 2011-04-22 17:15 table_userentries-f-42145-Data.db -rw-r--r-- 1 root root 17M 2011-04-22 17:17 table_userentries-f-42146-Data.db -rw-r--r-- 1 root root 17M 2011-04-22 17:20 table_userentries-f-42147-Data.db -rw-r--r-- 1 root root 17M 2011-04-22 17:23 table_userentries-f-42148-Data.db -rw-r--r-- 1 root root 17M 2011-04-22 17:26 table_userentries-f-42149-Data.db -rw-r--r-- 1 root root 13M 2011-04-22 17:33 table_userentries-f-42150-Data.db -rw-r--r-- 1 root root 17M 2011-04-22 17:37 table_userentries-f-42152-Data.db -rw-r--r-- 1 root root 17M 2011-04-22 17:38 table_userentries-f-42153-Data.db -rw-r--r-- 1 root root 17M 2011-04-22 17:39 table_userentries-f-42154-Data.db -rw-r--r-- 1 root root 17M 2011-04-22 17:40 table_userentries-f-42155-Data.db -rw-r--r-- 1 root root 17M 2011-04-22 17:42 table_userentries-f-42156-Data.db -rw-r--r-- 1 root root 17M 2011-04-22 17:43 table_userentries-f-42157-Data.db -rw-r--r-- 1 root root 17M 2011-04-22 17:44 table_userentries-f-42158-Data.db -rw-r--r-- 1 root root 17M 2011-04-22 17:45 table_userentries-f-42159-Data.db -rw-r--r-- 1 root root 6.7M 2011-04-22 19:18 table_userentries-f-42160-Data.db -rw-r--r-- 1 root root 528M 2011-04-22 19:19 table_userentries-f-42161-Data.db It's certainly something related to compacting. There are log file entries related to cassandra compacting other tables (Compacting table_). But this table never shows up (even not when I trigger a manual compaction on that table). > Node not responding, bringing down cluster, marked as up > > > Key: CASSANDRA-2543 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2543 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.7.4 >Reporter: Thibaut > Fix For: 0.7.6 > > Attachments: jstack > > > I have one node which constantly hangs and brings done the entire cluster > (not giving any answers). > If I restart the node, the node will hang after a certain number of time. I > have no indication > It's marked as up when executing the nodetool ring command. > Executing the ring command on the node itself (without any traffic on the > cluster) takes at least 2 minutes to execute. The node takes about 50%-100% > of cpu over all cpus. > Netstats doesn't list anything interesting: > /software/cassandra/bin/nodetool -h localhost netstats > Mode: Normal > Not sending any streams. > Not receiving any streams. > Pool NameActive Pending Completed > Commandsn/a 0 51064 > Responses n/a 0 5
svn commit: r1095960 - /cassandra/branches/cassandra-0.7/NEWS.txt
Author: slebresne Date: Fri Apr 22 16:33:31 2011 New Revision: 1095960 URL: http://svn.apache.org/viewvc?rev=1095960&view=rev Log: Update NEWS.txt for 0.7.5 release Modified: cassandra/branches/cassandra-0.7/NEWS.txt Modified: cassandra/branches/cassandra-0.7/NEWS.txt URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/NEWS.txt?rev=1095960&r1=1095959&r2=1095960&view=diff == --- cassandra/branches/cassandra-0.7/NEWS.txt (original) +++ cassandra/branches/cassandra-0.7/NEWS.txt Fri Apr 22 16:33:31 2011 @@ -3,7 +3,7 @@ Upgrading - -- Nothing specific to 0.7.4, but see 0.7.3 Upgrading if upgrading +- Nothing specific to 0.7.5, but see 0.7.3 Upgrading if upgrading from earlier than 0.7.1. Changes @@ -11,6 +11,11 @@ Changes - system_update_column_family no longer snapshots before applying the schema change. (_update_keyspace never did. _drop_keyspace and _drop_column_family continue to snapshot.) +- added memtable_flush_queue_size option to cassandra.yaml to + avoid blocking writes when multiple column families (or a colum + family with indexes) are flushed at the same time. +- allow overriding initial_token, storage_port and rpc_port using + system properties 0.7.4
[jira] [Commented] (CASSANDRA-2536) Schema disagreements when using connections to multiple hosts
[ https://issues.apache.org/jira/browse/CASSANDRA-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023263#comment-13023263 ] Tyler Hobbs commented on CASSANDRA-2536: Nevermind my thoughts that it doesn't happen in 0.7.3 -- it seems to happen there too. It appears this is not a recent problem. > Schema disagreements when using connections to multiple hosts > - > > Key: CASSANDRA-2536 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2536 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.8 beta 1 > Environment: Two node 0.8-beta1 cluster with one seed and JNA. >Reporter: Tyler Hobbs >Assignee: Gary Dusbabek > Attachments: schema_disagree.py > > > If you have two thrift connections open to different nodes and you create a > KS using the first, then a CF in that KS using the second, you wind up with a > schema disagreement even if you wait/sleep after creating the KS. > The attached script reproduces the issue using pycassa (1.0.6 should work > fine, although it has the 0.7 thrift-gen code). It's also reproducible by > hand with two cassandra-cli sessions. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2537) CQL: Error performing batch insert
[
https://issues.apache.org/jira/browse/CASSANDRA-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023240#comment-13023240
]
Cathy Daw edited comment on CASSANDRA-2537 at 4/22/11 4:11 PM:
---
I will look at batch deletes today, but if you want to be one step ahead of me
it can save you a bug. Also how do you rollback a batch?
was (Author: cdaw):
Also how do you rollback a batch?
> CQL: Error performing batch insert
> --
>
> Key: CASSANDRA-2537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2537
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 0.8 beta 1
> Environment: 3-node Centos 5.5 cluster running 0.8 build from apr20.
>Reporter: Cathy Daw
>Assignee: Pavel Yaskevich
>Priority: Minor
> Labels: cql
> Fix For: 0.8.0
>
>
> *Test Case To Run*
> {code}
> // Setup
> CREATE COLUMNFAMILY users (
> KEY varchar PRIMARY KEY,
> password varchar);
> //Batch Insert
> BEGIN BATCH USING QUORUM
> INSERT INTO users (KEY, password) VALUES ('user2', 'ch@ngem3b');
> INSERT INTO users (KEY, password) VALUES ('user3', 'ch@ngem3c');
> APPLY BATCH
> {code}
> *Actual Behavior*
> {code}
> cqlsh> BEGIN BATCH USING QUORUM
>... INSERT INTO users (KEY, password) VALUES ('user2', 'ch@ngem3b');
> Bad Request: line 0:-1 mismatched input '' expecting K_APPLY
> {code}
> *Documentation Sample*
> {code}
> BEGIN BATCH [USING ]
> UPDATE CF1 SET name1 = value1, name2 = value2 WHERE KEY = keyname1;
> UPDATE CF1 SET name3 = value3 WHERE KEY = keyname2;
> UPDATE CF2 SET name4 = value4, name5 = value5 WHERE KEY = keyname3;
> APPLY BATCH
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2536) Schema disagreements when using connections to multiple hosts
[ https://issues.apache.org/jira/browse/CASSANDRA-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023257#comment-13023257 ] Tyler Hobbs commented on CASSANDRA-2536: Actually, I can also reproduce this with a two node 0.7.4 cluster. I'm pretty sure that this does not happen with 0.7.3, but I'll go ahead and verify that. > Schema disagreements when using connections to multiple hosts > - > > Key: CASSANDRA-2536 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2536 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.8 beta 1 > Environment: Two node 0.8-beta1 cluster with one seed and JNA. >Reporter: Tyler Hobbs >Assignee: Gary Dusbabek > Attachments: schema_disagree.py > > > If you have two thrift connections open to different nodes and you create a > KS using the first, then a CF in that KS using the second, you wind up with a > schema disagreement even if you wait/sleep after creating the KS. > The attached script reproduces the issue using pycassa (1.0.6 should work > fine, although it has the 0.7 thrift-gen code). It's also reproducible by > hand with two cassandra-cli sessions. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2494) Quorum reads are not consistent
[ https://issues.apache.org/jira/browse/CASSANDRA-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023242#comment-13023242 ] Sean Bridges edited comment on CASSANDRA-2494 at 4/22/11 3:23 PM: -- To be clear, this is a new guarantee. The current guarantee is R+W>N gives you consistency. This bug is asking that a successful quorum read of A means that A has been committed to a quorum of nodes. "How can we ensure the quorum read property that you want ?" If when reading at quorum, and no quorum can be found which agrees on a particular value, then the coordinator ( ? ) will wait for acks of read repair writes (or perhaps just do normal writes) to be returned from a sufficient number of nodes to ensure that the value has been committed to a quorum of nodes. Without this new guarantee it is hard for readers to function correctly. The reader does not know that the quorum write failed, or is still in progress, so without reading at ALL, the R+W>N guarantee does not help the reader. was (Author: sbridges): To be clear, this is a new guarantee. The current guarantee is R+W>N gives you consistency. This bug is asking that a quorum read of A means that A has been committed to a quorum of nodes. "How can we ensure the quorum read property that you want ?" If when reading at quorum, and no quorum can be found which agrees on a particular value, then the coordinator (?) will wait for acks of read repair writes (or perhaps just do normal writes) to be returned from a sufficient number of nodes to ensure that the value has been committed to a quorum of nodes. Without this new guarantee it is hard for readers to function correctly. The reader does not know that the quorum write failed, or is still in progress, so without reading at ALL, the R+W>N guarantee does not help the reader. > Quorum reads are not consistent > --- > > Key: CASSANDRA-2494 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2494 > Project: Cassandra > Issue Type: Bug >Reporter: Sean Bridges > > As discussed in this thread, > http://www.mail-archive.com/user@cassandra.apache.org/msg12421.html > Quorum reads should be consistent. Assume we have a cluster of 3 nodes > (X,Y,Z) and a replication factor of 3. If a write of N is committed to X, but > not Y and Z, then a read from X should not return N unless the read is > committed to at least two nodes. To ensure this, a read from X should wait > for an ack of the read repair write from either Y or Z before returning. > Are there system tests for cassandra? If so, there should be a test similar > to the original post in the email thread. One thread should write 1,2,3... > at consistency level ONE. Another thread should read at consistency level > QUORUM from a random host, and verify that each read is >= the last read. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2494) Quorum reads are not consistent
[ https://issues.apache.org/jira/browse/CASSANDRA-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023242#comment-13023242 ] Sean Bridges commented on CASSANDRA-2494: - To be clear, this is a new guarantee. The current guarantee is R+W>N gives you consistency. This bug is asking that a quorum read of A means that A has been committed to a quorum of nodes. "How can we ensure the quorum read property that you want ?" If when reading at quorum, and no quorum can be found which agrees on a particular value, then the coordinator (?) will wait for acks of read repair writes (or perhaps just do normal writes) to be returned from a sufficient number of nodes to ensure that the value has been committed to a quorum of nodes. Without this new guarantee it is hard for readers to function correctly. The reader does not know that the quorum write failed, or is still in progress, so without reading at ALL, the R+W>N guarantee does not help the reader. > Quorum reads are not consistent > --- > > Key: CASSANDRA-2494 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2494 > Project: Cassandra > Issue Type: Bug >Reporter: Sean Bridges > > As discussed in this thread, > http://www.mail-archive.com/user@cassandra.apache.org/msg12421.html > Quorum reads should be consistent. Assume we have a cluster of 3 nodes > (X,Y,Z) and a replication factor of 3. If a write of N is committed to X, but > not Y and Z, then a read from X should not return N unless the read is > committed to at least two nodes. To ensure this, a read from X should wait > for an ack of the read repair write from either Y or Z before returning. > Are there system tests for cassandra? If so, there should be a test similar > to the original post in the email thread. One thread should write 1,2,3... > at consistency level ONE. Another thread should read at consistency level > QUORUM from a random host, and verify that each read is >= the last read. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2537) CQL: Error performing batch insert
[
https://issues.apache.org/jira/browse/CASSANDRA-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023240#comment-13023240
]
Cathy Daw commented on CASSANDRA-2537:
--
Also how do you rollback a batch?
> CQL: Error performing batch insert
> --
>
> Key: CASSANDRA-2537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2537
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 0.8 beta 1
> Environment: 3-node Centos 5.5 cluster running 0.8 build from apr20.
>Reporter: Cathy Daw
>Assignee: Pavel Yaskevich
>Priority: Minor
> Labels: cql
> Fix For: 0.8.0
>
>
> *Test Case To Run*
> {code}
> // Setup
> CREATE COLUMNFAMILY users (
> KEY varchar PRIMARY KEY,
> password varchar);
> //Batch Insert
> BEGIN BATCH USING QUORUM
> INSERT INTO users (KEY, password) VALUES ('user2', 'ch@ngem3b');
> INSERT INTO users (KEY, password) VALUES ('user3', 'ch@ngem3c');
> APPLY BATCH
> {code}
> *Actual Behavior*
> {code}
> cqlsh> BEGIN BATCH USING QUORUM
>... INSERT INTO users (KEY, password) VALUES ('user2', 'ch@ngem3b');
> Bad Request: line 0:-1 mismatched input '' expecting K_APPLY
> {code}
> *Documentation Sample*
> {code}
> BEGIN BATCH [USING ]
> UPDATE CF1 SET name1 = value1, name2 = value2 WHERE KEY = keyname1;
> UPDATE CF1 SET name3 = value3 WHERE KEY = keyname2;
> UPDATE CF2 SET name4 = value4, name5 = value5 WHERE KEY = keyname3;
> APPLY BATCH
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Cassandra Wiki] Update of "ArchitectureGossip" by MakiWatanabe
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "ArchitectureGossip" page has been changed by MakiWatanabe. The comment on this change is: Add description of HeartBeatState Generation. http://wiki.apache.org/cassandra/ArchitectureGossip?action=diff&rev1=7&rev2=8 -- == Data structures == HeartBeatState - Consists of generation and version number. Generation stays the same when server is running and grows every time the node is started. Used for distinguishing state information before and after a node restart. Version number is shared with application states and guarantees ordering. Each node has one !HeartBeatState associated with it. + Consists of generation and version number. Generation is the timestamp when the node is started, represented by seconds since 1970/01/01. It stays the same when server is running and grows every time the node is started. Used for distinguishing state information before and after a node restart. Version number is shared with application states and guarantees ordering. Each node has one !HeartBeatState associated with it. ApplicationState Consists of state and version number and represents a state of single "component" or "element" within Cassandra. For instance application state for "load information" could be (5.2, 45), which means that node load is 5.2 at version 45. Similarly a node that is bootstrapping would have "bootstrapping" application state: (bxLpassF3XD8Kyks, 56) where first one is bootstrap token, and the second is version. Version number is shared by application states and !HeartBeatState to guarantee ordering and can only grow.
[jira] [Commented] (CASSANDRA-2494) Quorum reads are not consistent
[ https://issues.apache.org/jira/browse/CASSANDRA-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023239#comment-13023239 ] Peter Schuller commented on CASSANDRA-2494: --- The issue is that of *failed* QUORUM writes. I.e., you design your system to use QUORUM writes and QUORUM reads, and expect that once a QUORUM read sees a given piece of data a subsequent QUORUM read will also see it (or a later data). A *failed* QUORUM write that was replicated to less than a QUORUM would be visible as part of QUORUM reads that happen to touch one of those replicas, but there is no guarantee that subsequent reads see it. I was under the impression this was never an intended guarantee. Apparently I may be wrong about that given the jbellis quote above. In either case, it is certainly not an *actual* guarantee given by the current implementation. The guarantee that a *successful* QUORUM write is seen by a subsequent QUORUM read is, as far as I can tell, not in question here. > Quorum reads are not consistent > --- > > Key: CASSANDRA-2494 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2494 > Project: Cassandra > Issue Type: Bug >Reporter: Sean Bridges > > As discussed in this thread, > http://www.mail-archive.com/user@cassandra.apache.org/msg12421.html > Quorum reads should be consistent. Assume we have a cluster of 3 nodes > (X,Y,Z) and a replication factor of 3. If a write of N is committed to X, but > not Y and Z, then a read from X should not return N unless the read is > committed to at least two nodes. To ensure this, a read from X should wait > for an ack of the read repair write from either Y or Z before returning. > Are there system tests for cassandra? If so, there should be a test similar > to the original post in the email thread. One thread should write 1,2,3... > at consistency level ONE. Another thread should read at consistency level > QUORUM from a random host, and verify that each read is >= the last read. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1095941 - /cassandra/branches/cassandra-0.7/debian/changelog
Author: eevans Date: Fri Apr 22 15:12:01 2011 New Revision: 1095941 URL: http://svn.apache.org/viewvc?rev=1095941&view=rev Log: update debian/changelog for 0.7.5 release Modified: cassandra/branches/cassandra-0.7/debian/changelog Modified: cassandra/branches/cassandra-0.7/debian/changelog URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/debian/changelog?rev=1095941&r1=1095940&r2=1095941&view=diff == --- cassandra/branches/cassandra-0.7/debian/changelog (original) +++ cassandra/branches/cassandra-0.7/debian/changelog Fri Apr 22 15:12:01 2011 @@ -1,3 +1,9 @@ +cassandra (0.7.5) unstable; urgency=low + + * New stable point release. + + -- Eric Evans Fri, 22 Apr 2011 10:11:01 -0500 + cassandra (0.7.4) unstable; urgency=low * New stable point release.
[jira] [Commented] (CASSANDRA-2494) Quorum reads are not consistent
[ https://issues.apache.org/jira/browse/CASSANDRA-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023237#comment-13023237 ] Sylvain Lebresne commented on CASSANDRA-2494: - The problem is you are considering the consistency of reads but not write. The guarantee is: "quorum reads will not see old quorum write once a quorum read sees a new quorum". Period. I you don't consider the consistency of a write, consider the case of a CL.ANY write. In this case, the update may not be at all on any replica. How can we ensure the quorum read property that you want ? We query all nodes for quorum reads in case there is an hint somewhere ? If you look at the Consistency part of http://wiki.apache.org/cassandra/ArchitectureOverview, it seems to me that it is pretty clear that the consistency of reads *and* writes is involved to achieve strong consistency. So I would hope 'most people' are aware of that. > Quorum reads are not consistent > --- > > Key: CASSANDRA-2494 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2494 > Project: Cassandra > Issue Type: Bug >Reporter: Sean Bridges > > As discussed in this thread, > http://www.mail-archive.com/user@cassandra.apache.org/msg12421.html > Quorum reads should be consistent. Assume we have a cluster of 3 nodes > (X,Y,Z) and a replication factor of 3. If a write of N is committed to X, but > not Y and Z, then a read from X should not return N unless the read is > committed to at least two nodes. To ensure this, a read from X should wait > for an ack of the read repair write from either Y or Z before returning. > Are there system tests for cassandra? If so, there should be a test similar > to the original post in the email thread. One thread should write 1,2,3... > at consistency level ONE. Another thread should read at consistency level > QUORUM from a random host, and verify that each read is >= the last read. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2543) Node not responding, bringing down cluster, marked as up
[ https://issues.apache.org/jira/browse/CASSANDRA-2543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023236#comment-13023236 ] Jonathan Ellis commented on CASSANDRA-2543: --- bq. It still interest me why the node didn't recover even though there were nearly no requests at all from our application the two big users of memory are usually memtables and cache and neither one gets freed when requests stop. (until memtable_flush_after_mins is reached... and flush needs memory to work so if you are GC storming hard enough it may not make progress even then.) > Node not responding, bringing down cluster, marked as up > > > Key: CASSANDRA-2543 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2543 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.7.4 >Reporter: Thibaut > Fix For: 0.7.6 > > Attachments: jstack > > > I have one node which constantly hangs and brings done the entire cluster > (not giving any answers). > If I restart the node, the node will hang after a certain number of time. I > have no indication > It's marked as up when executing the nodetool ring command. > Executing the ring command on the node itself (without any traffic on the > cluster) takes at least 2 minutes to execute. The node takes about 50%-100% > of cpu over all cpus. > Netstats doesn't list anything interesting: > /software/cassandra/bin/nodetool -h localhost netstats > Mode: Normal > Not sending any streams. > Not receiving any streams. > Pool NameActive Pending Completed > Commandsn/a 0 51064 > Responses n/a 0 530479 > I attached the jstack of the node. There are no indications that the node has > faulty hardware. > /usr/bin/java -ea -XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 > -Xms5254M -Xmx5254M -Xmn400M -XX:+HeapDumpOnOutOfMemoryError -Xss128k > -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled > -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=1 > -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly > -Djava.net.preferIPv4Stack=true -Dcom.sun.management.jmxremote.port=8080 > -Dcom.sun.management.jmxremote.ssl=false > -Dcom.sun.management.jmxremote.authenticate=false > -Dlog4j.configuration=log4j-server.properties > -Dlog4j.defaultInitOverride=true -Dcassandra-foreground=yes -cp > /software/cassandra/bin/../conf:/software/cassandra/bin/../build/classes:/software/cassandra/bin/../lib/antlr-3.1.3.jar:/software/cassandra/bin/../lib/apache-cassandra-0.7.4.jar:/software/cassandra/bin/../lib/avro-1.4.0-fixes.jar:/software/cassandra/bin/../lib/avro-1.4.0-sources-fixes.jar:/software/cassandra/bin/../lib/commons-cli-1.1.jar:/software/cassandra/bin/../lib/commons-codec-1.2.jar:/software/cassandra/bin/../lib/commons-collections-3.2.1.jar:/software/cassandra/bin/../lib/commons-lang-2.4.jar:/software/cassandra/bin/../lib/concurrentlinkedhashmap-lru-1.1.jar:/software/cassandra/bin/../lib/guava-r05.jar:/software/cassandra/bin/../lib/high-scale-lib.jar:/software/cassandra/bin/../lib/jackson-core-asl-1.4.0.jar:/software/cassandra/bin/../lib/jackson-mapper-asl-1.4.0.jar:/software/cassandra/bin/../lib/jetty-6.1.21.jar:/software/cassandra/bin/../lib/jetty-util-6.1.21.jar:/software/cassandra/bin/../lib/jline-0.9.94.jar:/software/cassandra/bin/../lib/json-simple-1.1.jar:/software/cassandra/bin/../lib/jug-2.0.0.jar:/software/cassandra/bin/../lib/libthrift-0.5.jar:/software/cassandra/bin/../lib/log4j-1.2.16.jar:/software/cassandra/bin/../lib/servlet-api-2.5-20081211.jar:/software/cassandra/bin/../lib/slf4j-api-1.6.1.jar:/software/cassandra/bin/../lib/slf4j-log4j12-1.6.1.jar:/software/cassandra/bin/../lib/snakeyaml-1.6.jar > org.apache.cassandra.thrift.CassandraDaemon -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2542) InvalidRequestException
[
https://issues.apache.org/jira/browse/CASSANDRA-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023231#comment-13023231
]
Timu Eren commented on CASSANDRA-2542:
--
ok, thats my folly. i confused rowkey with column name, i am so sory for that.
> InvalidRequestException
> ---
>
> Key: CASSANDRA-2542
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2542
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 0.7.4
>Reporter: Timu Eren
>Priority: Minor
>
> i got InvalidRequestException when execute map reduce jobs on supercolumn, if
> i set the comparator as LongType, other types (AsciiType, UTF8Type,
> IntegerType) works just fine
> Here is reprocedure details.
> create column family
> SuperTest
> with
> column_type=Super and
> comparator=LongType and
> subcomparator=UTF8Type and
> default_validation_class=UTF8Type;
> list SuperTest;
> Using default limit of 100
> ---
> RowKey: 2
> => (super_column=10,
> (column=1, value=1, timestamp=1303459440853000))
> => (super_column=11,
> (column=1, value=1, timestamp=1303459437632000))
> => (super_column=12,
> (column=1, value=1, timestamp=1303459432652000))
> => (super_column=13,
> (column=1, value=1, timestamp=1303459435102000))
> ---
> RowKey: 1
> => (super_column=10,
> (column=1, value=1, timestamp=1303459423202000))
> => (super_column=11,
> (column=1, value=1, timestamp=1303459419112000))
> => (super_column=12,
> (column=deneme, value=1, timestamp=1303459362702000))
> => (super_column=13,
> (column=deneme, value=1, timestamp=1303459382023000))
> => (super_column=15,
> (column=1, value=1, timestamp=1303459426402000))
> 2 Rows Returned.
> == Test class ==
> import java.io.IOException;
> import java.nio.ByteBuffer;
> import java.util.List;
> import java.util.SortedMap;
> import org.apache.cassandra.hadoop.ColumnFamilyInputFormat;
> import org.apache.cassandra.hadoop.ColumnFamilyOutputFormat;
> import org.apache.cassandra.hadoop.ConfigHelper;
> import org.apache.cassandra.avro.Mutation;
> import org.apache.cassandra.thrift.SliceRange;
> import org.apache.cassandra.thrift.SlicePredicate;
> import org.apache.cassandra.utils.ByteBufferUtil;
> import org.apache.cassandra.db.IColumn;
> import org.apache.hadoop.conf.Configuration;
> import org.apache.hadoop.conf.Configured;
> import org.apache.hadoop.io.IntWritable;
> import org.apache.hadoop.io.Text;
> import org.apache.hadoop.mapreduce.Job;
> import org.apache.hadoop.mapreduce.Mapper;
> import org.apache.hadoop.mapreduce.Reducer;
> import org.apache.hadoop.util.Tool;
> import org.apache.hadoop.util.ToolRunner;
> import org.slf4j.Logger;
> import org.slf4j.LoggerFactory;
> class SuperColumnTest extends Configured implements Tool {
>
> private static final Logger logger =
> LoggerFactory.getLogger(SuperColumnTest.class);
>
> public static void main(String[] args) throws Exception {
> ToolRunner.run(new Configuration(), new SuperColumnTest(), args);
> System.exit(0);
> }
>
> public static class SuperColumnTestMapper extends Mapper SortedMap, Text, IntWritable> {
> private static final Logger logger =
> LoggerFactory.getLogger(SuperColumnTestMapper.class);
>
> public void map(ByteBuffer key, SortedMap
> columns, Context context) throws IOException, InterruptedException {
>
> logger.info(String.format("Key:%s, size: %s",
> ByteBufferUtil.string(key), columns.size()));
>
>
> }
> }
>
> public static class SuperColumnTestReducer extends Reducer IntWritable, ByteBuffer, List> {
> public void reduce(Text key, Iterable values, Context
> context) throws IOException, InterruptedException {
>
> }
> }
>
> public int run(String[] args) throws Exception{
>
> Job job = new Job(this.getConf(), "SuperColumnMapReduceTest");
> job.setJarByClass(SuperColumnTest.class);
> job.setMapperClass(SuperColumnTestMapper.class);
> job.setReducerClass(SuperColumnTestReducer.class);
>
>
> job.setOutputFormatClass(ColumnFamilyOutputFormat.class);
> ConfigHelper.setOutputColumnFamily(job.getConfiguration(), "",
> "SuperTest");
>
> job.setMapOutputKeyClass(Text.class);
> job.setMapOutputValueClass(IntWritable.class);
>
> job.setOutputKeyClass(ByteBuffer.class);
> job.setOutputValueClass(List.class);
> job.setInputFormatClass(ColumnFamilyInputFormat.class);
>
>
> ConfigHelper.setInputColumnFamily(job.getConfiguration(), "",
> "SuperTest");
> ConfigHelp
[jira] [Commented] (CASSANDRA-2494) Quorum reads are not consistent
[ https://issues.apache.org/jira/browse/CASSANDRA-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023233#comment-13023233 ] Sean Bridges commented on CASSANDRA-2494: - I think the guarantee of quorum reads not seeing old writes once a quorum read sees a new write is very useful. I suspect most people already think that this guarantee occurs, including, it seems, Jonathan Ellis whose quote can be found in the email thread linked to in the bug, "The important guarantee this gives you is that once one quorum read sees the new value, all others will too. You can't see the newest version, then see an older version on a subsequent write [sic, I assume he meant read], which is the characteristic of non-strong consistency" > Quorum reads are not consistent > --- > > Key: CASSANDRA-2494 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2494 > Project: Cassandra > Issue Type: Bug >Reporter: Sean Bridges > > As discussed in this thread, > http://www.mail-archive.com/user@cassandra.apache.org/msg12421.html > Quorum reads should be consistent. Assume we have a cluster of 3 nodes > (X,Y,Z) and a replication factor of 3. If a write of N is committed to X, but > not Y and Z, then a read from X should not return N unless the read is > committed to at least two nodes. To ensure this, a read from X should wait > for an ack of the read repair write from either Y or Z before returning. > Are there system tests for cassandra? If so, there should be a test similar > to the original post in the email thread. One thread should write 1,2,3... > at consistency level ONE. Another thread should read at consistency level > QUORUM from a random host, and verify that each read is >= the last read. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2543) Node not responding, bringing down cluster, marked as up
[ https://issues.apache.org/jira/browse/CASSANDRA-2543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023232#comment-13023232 ] Thibaut commented on CASSANDRA-2543: Ok thanks. I will try above to make sure it's the GC thread taking up 100% cpu (which I suspect). The GC indeed ran indeed very very often: (grepping the old log file) INFO [ScheduledTasks:1] 2011-04-22 15:07:24,742 GCInspector.java (line 128) GC for ConcurrentMarkSweep: 3133 ms, 1537221688 reclaimed leaving 3830570400 used; max is 5605687296 INFO [ScheduledTasks:1] 2011-04-22 15:07:28,978 GCInspector.java (line 128) GC for ConcurrentMarkSweep: 2901 ms, 2172093472 reclaimed leaving 3219903248 used; max is 5605687296 INFO [ScheduledTasks:1] 2011-04-22 15:07:33,946 GCInspector.java (line 128) GC for ConcurrentMarkSweep: 3138 ms, 1715631768 reclaimed leaving 3581355456 used; max is 5605687296 INFO [ScheduledTasks:1] 2011-04-22 15:07:38,318 GCInspector.java (line 128) GC for ConcurrentMarkSweep: 2860 ms, 2467501736 reclaimed leaving 2874209912 used; max is 5605687296 INFO [ScheduledTasks:1] 2011-04-22 15:07:43,466 GCInspector.java (line 128) GC for ConcurrentMarkSweep: 3059 ms, 1491300856 reclaimed leaving 3875493760 used; max is 5605687296 INFO [ScheduledTasks:1] 2011-04-22 15:07:47,529 GCInspector.java (line 128) GC for ConcurrentMarkSweep: 2780 ms, 2521501408 reclaimed leaving 2824239464 used; max is 5605687296 INFO [ScheduledTasks:1] 2011-04-22 15:07:52,983 GCInspector.java (line 128) GC for ConcurrentMarkSweep: 3330 ms, 1287324312 reclaimed leaving 3964465048 used; max is 5605687296 INFO [ScheduledTasks:1] 2011-04-22 15:07:57,147 GCInspector.java (line 128) GC for ConcurrentMarkSweep: 3071 ms, 1950115232 reclaimed leaving 3337420088 used; max is 5605687296 INFO [ScheduledTasks:1] 2011-04-22 15:08:01,785 GCInspector.java (line 128) GC for ConcurrentMarkSweep: 3069 ms, 1748108592 reclaimed leaving 3444685288 used; max is 5605687296 INFO [ScheduledTasks:1] 2011-04-22 15:08:06,397 GCInspector.java (line 128) GC for ConcurrentMarkSweep: 3011 ms, 1779092920 reclaimed leaving 3637964728 used; max is 5605687296 INFO [ScheduledTasks:1] 2011-04-22 15:08:10,715 GCInspector.java (line 128) GC for ConcurrentMarkSweep: 2950 ms, 2042754088 reclaimed leaving 3223819496 used; max is 5605687296 INFO [ScheduledTasks:1] 2011-04-22 15:08:15,528 GCInspector.java (line 128) GC for ConcurrentMarkSweep: 3217 ms, 956021816 reclaimed leaving 4371838768 used; max is 5605687296 INFO [ScheduledTasks:1] 2011-04-22 15:08:19,380 GCInspector.java (line 128) GC for ConcurrentMarkSweep: 3007 ms, 2216336016 reclaimed leaving 3213552904 used; max is 5605687296 INFO [ScheduledTasks:1] 2011-04-22 15:08:24,154 GCInspector.java (line 128) GC for ConcurrentMarkSweep: 2973 ms, 1964499424 reclaimed leaving 3287557528 used; max is 5605687296 INFO [ScheduledTasks:1] 2011-04-22 15:08:29,088 GCInspector.java (line 128) GC for ConcurrentMarkSweep: 2988 ms, 1964657952 reclaimed leaving 3418170312 used; max is 5605687296 It still interest me why the node didn't recover even though there were nearly no requests at all from our application. > Node not responding, bringing down cluster, marked as up > > > Key: CASSANDRA-2543 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2543 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.7.4 >Reporter: Thibaut > Fix For: 0.7.6 > > Attachments: jstack > > > I have one node which constantly hangs and brings done the entire cluster > (not giving any answers). > If I restart the node, the node will hang after a certain number of time. I > have no indication > It's marked as up when executing the nodetool ring command. > Executing the ring command on the node itself (without any traffic on the > cluster) takes at least 2 minutes to execute. The node takes about 50%-100% > of cpu over all cpus. > Netstats doesn't list anything interesting: > /software/cassandra/bin/nodetool -h localhost netstats > Mode: Normal > Not sending any streams. > Not receiving any streams. > Pool NameActive Pending Completed > Commandsn/a 0 51064 > Responses n/a 0 530479 > I attached the jstack of the node. There are no indications that the node has > faulty hardware. > /usr/bin/java -ea -XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 > -Xms5254M -Xmx5254M -Xmn400M -XX:+HeapDumpOnOutOfMemoryError -Xss128k > -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled > -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=1 > -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly > -Djava.net.preferIPv4Stack=true -Dcom.sun
[jira] [Commented] (CASSANDRA-2542) InvalidRequestException
[
https://issues.apache.org/jira/browse/CASSANDRA-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023227#comment-13023227
]
Timu Eren commented on CASSANDRA-2542:
--
yes, i see this message but i don't pass any row name in map reduce job, i use
column names (subcomparator=UTF8Type) instead SliceRange for SlicePredicate and
i still get IRE, so who is passing invalid row names if i don't passed? and
same code, same data is works if i use IntegerType for comparator instead
LongType.
more readable code is here: http://pastebin.com/dVYGvy8A
> InvalidRequestException
> ---
>
> Key: CASSANDRA-2542
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2542
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 0.7.4
>Reporter: Timu Eren
>Priority: Minor
>
> i got InvalidRequestException when execute map reduce jobs on supercolumn, if
> i set the comparator as LongType, other types (AsciiType, UTF8Type,
> IntegerType) works just fine
> Here is reprocedure details.
> create column family
> SuperTest
> with
> column_type=Super and
> comparator=LongType and
> subcomparator=UTF8Type and
> default_validation_class=UTF8Type;
> list SuperTest;
> Using default limit of 100
> ---
> RowKey: 2
> => (super_column=10,
> (column=1, value=1, timestamp=1303459440853000))
> => (super_column=11,
> (column=1, value=1, timestamp=1303459437632000))
> => (super_column=12,
> (column=1, value=1, timestamp=1303459432652000))
> => (super_column=13,
> (column=1, value=1, timestamp=1303459435102000))
> ---
> RowKey: 1
> => (super_column=10,
> (column=1, value=1, timestamp=1303459423202000))
> => (super_column=11,
> (column=1, value=1, timestamp=1303459419112000))
> => (super_column=12,
> (column=deneme, value=1, timestamp=1303459362702000))
> => (super_column=13,
> (column=deneme, value=1, timestamp=1303459382023000))
> => (super_column=15,
> (column=1, value=1, timestamp=1303459426402000))
> 2 Rows Returned.
> == Test class ==
> import java.io.IOException;
> import java.nio.ByteBuffer;
> import java.util.List;
> import java.util.SortedMap;
> import org.apache.cassandra.hadoop.ColumnFamilyInputFormat;
> import org.apache.cassandra.hadoop.ColumnFamilyOutputFormat;
> import org.apache.cassandra.hadoop.ConfigHelper;
> import org.apache.cassandra.avro.Mutation;
> import org.apache.cassandra.thrift.SliceRange;
> import org.apache.cassandra.thrift.SlicePredicate;
> import org.apache.cassandra.utils.ByteBufferUtil;
> import org.apache.cassandra.db.IColumn;
> import org.apache.hadoop.conf.Configuration;
> import org.apache.hadoop.conf.Configured;
> import org.apache.hadoop.io.IntWritable;
> import org.apache.hadoop.io.Text;
> import org.apache.hadoop.mapreduce.Job;
> import org.apache.hadoop.mapreduce.Mapper;
> import org.apache.hadoop.mapreduce.Reducer;
> import org.apache.hadoop.util.Tool;
> import org.apache.hadoop.util.ToolRunner;
> import org.slf4j.Logger;
> import org.slf4j.LoggerFactory;
> class SuperColumnTest extends Configured implements Tool {
>
> private static final Logger logger =
> LoggerFactory.getLogger(SuperColumnTest.class);
>
> public static void main(String[] args) throws Exception {
> ToolRunner.run(new Configuration(), new SuperColumnTest(), args);
> System.exit(0);
> }
>
> public static class SuperColumnTestMapper extends Mapper SortedMap, Text, IntWritable> {
> private static final Logger logger =
> LoggerFactory.getLogger(SuperColumnTestMapper.class);
>
> public void map(ByteBuffer key, SortedMap
> columns, Context context) throws IOException, InterruptedException {
>
> logger.info(String.format("Key:%s, size: %s",
> ByteBufferUtil.string(key), columns.size()));
>
>
> }
> }
>
> public static class SuperColumnTestReducer extends Reducer IntWritable, ByteBuffer, List> {
> public void reduce(Text key, Iterable values, Context
> context) throws IOException, InterruptedException {
>
> }
> }
>
> public int run(String[] args) throws Exception{
>
> Job job = new Job(this.getConf(), "SuperColumnMapReduceTest");
> job.setJarByClass(SuperColumnTest.class);
> job.setMapperClass(SuperColumnTestMapper.class);
> job.setReducerClass(SuperColumnTestReducer.class);
>
>
> job.setOutputFormatClass(ColumnFamilyOutputFormat.class);
> ConfigHelper.setOutputColumnFamily(job.getConfiguration(), "",
> "SuperTest");
>
> job.setMapOutputKeyClass(Text.class);
> job.setMapOutputValueClass(IntWritable.class);
>
>
[jira] [Commented] (CASSANDRA-2543) Node not responding, bringing down cluster, marked as up
[ https://issues.apache.org/jira/browse/CASSANDRA-2543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023226#comment-13023226 ] Jonathan Ellis commented on CASSANDRA-2543: --- bq. How can the gc run constantly if there are still 1.5 Gig free could be fragmentation. could be it's not gc. i told you how to find out for sure earlier. :) bq. dynamic snitch is indeed disabled (because of data locality) you can have best of both worlds with dynamic snitch + badness threshold. > Node not responding, bringing down cluster, marked as up > > > Key: CASSANDRA-2543 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2543 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.7.4 >Reporter: Thibaut > Fix For: 0.7.6 > > Attachments: jstack > > > I have one node which constantly hangs and brings done the entire cluster > (not giving any answers). > If I restart the node, the node will hang after a certain number of time. I > have no indication > It's marked as up when executing the nodetool ring command. > Executing the ring command on the node itself (without any traffic on the > cluster) takes at least 2 minutes to execute. The node takes about 50%-100% > of cpu over all cpus. > Netstats doesn't list anything interesting: > /software/cassandra/bin/nodetool -h localhost netstats > Mode: Normal > Not sending any streams. > Not receiving any streams. > Pool NameActive Pending Completed > Commandsn/a 0 51064 > Responses n/a 0 530479 > I attached the jstack of the node. There are no indications that the node has > faulty hardware. > /usr/bin/java -ea -XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 > -Xms5254M -Xmx5254M -Xmn400M -XX:+HeapDumpOnOutOfMemoryError -Xss128k > -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled > -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=1 > -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly > -Djava.net.preferIPv4Stack=true -Dcom.sun.management.jmxremote.port=8080 > -Dcom.sun.management.jmxremote.ssl=false > -Dcom.sun.management.jmxremote.authenticate=false > -Dlog4j.configuration=log4j-server.properties > -Dlog4j.defaultInitOverride=true -Dcassandra-foreground=yes -cp > /software/cassandra/bin/../conf:/software/cassandra/bin/../build/classes:/software/cassandra/bin/../lib/antlr-3.1.3.jar:/software/cassandra/bin/../lib/apache-cassandra-0.7.4.jar:/software/cassandra/bin/../lib/avro-1.4.0-fixes.jar:/software/cassandra/bin/../lib/avro-1.4.0-sources-fixes.jar:/software/cassandra/bin/../lib/commons-cli-1.1.jar:/software/cassandra/bin/../lib/commons-codec-1.2.jar:/software/cassandra/bin/../lib/commons-collections-3.2.1.jar:/software/cassandra/bin/../lib/commons-lang-2.4.jar:/software/cassandra/bin/../lib/concurrentlinkedhashmap-lru-1.1.jar:/software/cassandra/bin/../lib/guava-r05.jar:/software/cassandra/bin/../lib/high-scale-lib.jar:/software/cassandra/bin/../lib/jackson-core-asl-1.4.0.jar:/software/cassandra/bin/../lib/jackson-mapper-asl-1.4.0.jar:/software/cassandra/bin/../lib/jetty-6.1.21.jar:/software/cassandra/bin/../lib/jetty-util-6.1.21.jar:/software/cassandra/bin/../lib/jline-0.9.94.jar:/software/cassandra/bin/../lib/json-simple-1.1.jar:/software/cassandra/bin/../lib/jug-2.0.0.jar:/software/cassandra/bin/../lib/libthrift-0.5.jar:/software/cassandra/bin/../lib/log4j-1.2.16.jar:/software/cassandra/bin/../lib/servlet-api-2.5-20081211.jar:/software/cassandra/bin/../lib/slf4j-api-1.6.1.jar:/software/cassandra/bin/../lib/slf4j-log4j12-1.6.1.jar:/software/cassandra/bin/../lib/snakeyaml-1.6.jar > org.apache.cassandra.thrift.CassandraDaemon -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2543) Node not responding, bringing down cluster, marked as up
[ https://issues.apache.org/jira/browse/CASSANDRA-2543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023225#comment-13023225 ] Thibaut commented on CASSANDRA-2543: It flaps between one core and multiple cores. There was one thread taking 100% cpu, and the other ones flapping as you said. How can the gc run constantly if there are still 1.5 Gig free according to nodetool info and I did shut down our application, so there shouldn't be any requests (or just a very few read requests) at all? But the localhost info heap info changed constantly (also grew close to the limit). There also many small tables which haven't yet been compacted. dynamic snitch is indeed disabled (because of data locality), but I will enable it and then bring the node to life again. > Node not responding, bringing down cluster, marked as up > > > Key: CASSANDRA-2543 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2543 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.7.4 >Reporter: Thibaut > Fix For: 0.7.6 > > Attachments: jstack > > > I have one node which constantly hangs and brings done the entire cluster > (not giving any answers). > If I restart the node, the node will hang after a certain number of time. I > have no indication > It's marked as up when executing the nodetool ring command. > Executing the ring command on the node itself (without any traffic on the > cluster) takes at least 2 minutes to execute. The node takes about 50%-100% > of cpu over all cpus. > Netstats doesn't list anything interesting: > /software/cassandra/bin/nodetool -h localhost netstats > Mode: Normal > Not sending any streams. > Not receiving any streams. > Pool NameActive Pending Completed > Commandsn/a 0 51064 > Responses n/a 0 530479 > I attached the jstack of the node. There are no indications that the node has > faulty hardware. > /usr/bin/java -ea -XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 > -Xms5254M -Xmx5254M -Xmn400M -XX:+HeapDumpOnOutOfMemoryError -Xss128k > -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled > -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=1 > -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly > -Djava.net.preferIPv4Stack=true -Dcom.sun.management.jmxremote.port=8080 > -Dcom.sun.management.jmxremote.ssl=false > -Dcom.sun.management.jmxremote.authenticate=false > -Dlog4j.configuration=log4j-server.properties > -Dlog4j.defaultInitOverride=true -Dcassandra-foreground=yes -cp > /software/cassandra/bin/../conf:/software/cassandra/bin/../build/classes:/software/cassandra/bin/../lib/antlr-3.1.3.jar:/software/cassandra/bin/../lib/apache-cassandra-0.7.4.jar:/software/cassandra/bin/../lib/avro-1.4.0-fixes.jar:/software/cassandra/bin/../lib/avro-1.4.0-sources-fixes.jar:/software/cassandra/bin/../lib/commons-cli-1.1.jar:/software/cassandra/bin/../lib/commons-codec-1.2.jar:/software/cassandra/bin/../lib/commons-collections-3.2.1.jar:/software/cassandra/bin/../lib/commons-lang-2.4.jar:/software/cassandra/bin/../lib/concurrentlinkedhashmap-lru-1.1.jar:/software/cassandra/bin/../lib/guava-r05.jar:/software/cassandra/bin/../lib/high-scale-lib.jar:/software/cassandra/bin/../lib/jackson-core-asl-1.4.0.jar:/software/cassandra/bin/../lib/jackson-mapper-asl-1.4.0.jar:/software/cassandra/bin/../lib/jetty-6.1.21.jar:/software/cassandra/bin/../lib/jetty-util-6.1.21.jar:/software/cassandra/bin/../lib/jline-0.9.94.jar:/software/cassandra/bin/../lib/json-simple-1.1.jar:/software/cassandra/bin/../lib/jug-2.0.0.jar:/software/cassandra/bin/../lib/libthrift-0.5.jar:/software/cassandra/bin/../lib/log4j-1.2.16.jar:/software/cassandra/bin/../lib/servlet-api-2.5-20081211.jar:/software/cassandra/bin/../lib/slf4j-api-1.6.1.jar:/software/cassandra/bin/../lib/slf4j-log4j12-1.6.1.jar:/software/cassandra/bin/../lib/snakeyaml-1.6.jar > org.apache.cassandra.thrift.CassandraDaemon -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-2542) InvalidRequestException
[
https://issues.apache.org/jira/browse/CASSANDRA-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-2542.
---
Resolution: Invalid
"Expected 8 or 0 byte long"
you are passing a non-Long value to something that expects a Long
> InvalidRequestException
> ---
>
> Key: CASSANDRA-2542
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2542
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 0.7.4
>Reporter: Timu Eren
>Priority: Minor
>
> i got InvalidRequestException when execute map reduce jobs on supercolumn, if
> i set the comparator as LongType, other types (AsciiType, UTF8Type,
> IntegerType) works just fine
> Here is reprocedure details.
> create column family
> SuperTest
> with
> column_type=Super and
> comparator=LongType and
> subcomparator=UTF8Type and
> default_validation_class=UTF8Type;
> list SuperTest;
> Using default limit of 100
> ---
> RowKey: 2
> => (super_column=10,
> (column=1, value=1, timestamp=1303459440853000))
> => (super_column=11,
> (column=1, value=1, timestamp=1303459437632000))
> => (super_column=12,
> (column=1, value=1, timestamp=1303459432652000))
> => (super_column=13,
> (column=1, value=1, timestamp=1303459435102000))
> ---
> RowKey: 1
> => (super_column=10,
> (column=1, value=1, timestamp=1303459423202000))
> => (super_column=11,
> (column=1, value=1, timestamp=1303459419112000))
> => (super_column=12,
> (column=deneme, value=1, timestamp=1303459362702000))
> => (super_column=13,
> (column=deneme, value=1, timestamp=1303459382023000))
> => (super_column=15,
> (column=1, value=1, timestamp=1303459426402000))
> 2 Rows Returned.
> == Test class ==
> import java.io.IOException;
> import java.nio.ByteBuffer;
> import java.util.List;
> import java.util.SortedMap;
> import org.apache.cassandra.hadoop.ColumnFamilyInputFormat;
> import org.apache.cassandra.hadoop.ColumnFamilyOutputFormat;
> import org.apache.cassandra.hadoop.ConfigHelper;
> import org.apache.cassandra.avro.Mutation;
> import org.apache.cassandra.thrift.SliceRange;
> import org.apache.cassandra.thrift.SlicePredicate;
> import org.apache.cassandra.utils.ByteBufferUtil;
> import org.apache.cassandra.db.IColumn;
> import org.apache.hadoop.conf.Configuration;
> import org.apache.hadoop.conf.Configured;
> import org.apache.hadoop.io.IntWritable;
> import org.apache.hadoop.io.Text;
> import org.apache.hadoop.mapreduce.Job;
> import org.apache.hadoop.mapreduce.Mapper;
> import org.apache.hadoop.mapreduce.Reducer;
> import org.apache.hadoop.util.Tool;
> import org.apache.hadoop.util.ToolRunner;
> import org.slf4j.Logger;
> import org.slf4j.LoggerFactory;
> class SuperColumnTest extends Configured implements Tool {
>
> private static final Logger logger =
> LoggerFactory.getLogger(SuperColumnTest.class);
>
> public static void main(String[] args) throws Exception {
> ToolRunner.run(new Configuration(), new SuperColumnTest(), args);
> System.exit(0);
> }
>
> public static class SuperColumnTestMapper extends Mapper SortedMap, Text, IntWritable> {
> private static final Logger logger =
> LoggerFactory.getLogger(SuperColumnTestMapper.class);
>
> public void map(ByteBuffer key, SortedMap
> columns, Context context) throws IOException, InterruptedException {
>
> logger.info(String.format("Key:%s, size: %s",
> ByteBufferUtil.string(key), columns.size()));
>
>
> }
> }
>
> public static class SuperColumnTestReducer extends Reducer IntWritable, ByteBuffer, List> {
> public void reduce(Text key, Iterable values, Context
> context) throws IOException, InterruptedException {
>
> }
> }
>
> public int run(String[] args) throws Exception{
>
> Job job = new Job(this.getConf(), "SuperColumnMapReduceTest");
> job.setJarByClass(SuperColumnTest.class);
> job.setMapperClass(SuperColumnTestMapper.class);
> job.setReducerClass(SuperColumnTestReducer.class);
>
>
> job.setOutputFormatClass(ColumnFamilyOutputFormat.class);
> ConfigHelper.setOutputColumnFamily(job.getConfiguration(), "",
> "SuperTest");
>
> job.setMapOutputKeyClass(Text.class);
> job.setMapOutputValueClass(IntWritable.class);
>
> job.setOutputKeyClass(ByteBuffer.class);
> job.setOutputValueClass(List.class);
> job.setInputFormatClass(ColumnFamilyInputFormat.class);
>
>
> ConfigHelper.setInputColumnFamily(job.getConfiguration(), "",
> "SuperTest");
> ConfigHelper.s
[jira] [Commented] (CASSANDRA-2543) Node not responding, bringing down cluster, marked as up
[ https://issues.apache.org/jira/browse/CASSANDRA-2543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023220#comment-13023220 ] Peter Schuller commented on CASSANDRA-2543: --- If you're running out of memory with CMS there should be a constant fallback to full GC, which is single-threaded (with CMS). That's inconsistent with 50-100% cpu across all cores (typically you check top and it's immediately obvious that it's at almost exactly 100% and that tells you it's full gc). Are you definitely spinning across multiple cores constantly, or does it flap between one core and multiple cores? > Node not responding, bringing down cluster, marked as up > > > Key: CASSANDRA-2543 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2543 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.7.4 >Reporter: Thibaut > Fix For: 0.7.6 > > Attachments: jstack > > > I have one node which constantly hangs and brings done the entire cluster > (not giving any answers). > If I restart the node, the node will hang after a certain number of time. I > have no indication > It's marked as up when executing the nodetool ring command. > Executing the ring command on the node itself (without any traffic on the > cluster) takes at least 2 minutes to execute. The node takes about 50%-100% > of cpu over all cpus. > Netstats doesn't list anything interesting: > /software/cassandra/bin/nodetool -h localhost netstats > Mode: Normal > Not sending any streams. > Not receiving any streams. > Pool NameActive Pending Completed > Commandsn/a 0 51064 > Responses n/a 0 530479 > I attached the jstack of the node. There are no indications that the node has > faulty hardware. > /usr/bin/java -ea -XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 > -Xms5254M -Xmx5254M -Xmn400M -XX:+HeapDumpOnOutOfMemoryError -Xss128k > -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled > -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=1 > -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly > -Djava.net.preferIPv4Stack=true -Dcom.sun.management.jmxremote.port=8080 > -Dcom.sun.management.jmxremote.ssl=false > -Dcom.sun.management.jmxremote.authenticate=false > -Dlog4j.configuration=log4j-server.properties > -Dlog4j.defaultInitOverride=true -Dcassandra-foreground=yes -cp > /software/cassandra/bin/../conf:/software/cassandra/bin/../build/classes:/software/cassandra/bin/../lib/antlr-3.1.3.jar:/software/cassandra/bin/../lib/apache-cassandra-0.7.4.jar:/software/cassandra/bin/../lib/avro-1.4.0-fixes.jar:/software/cassandra/bin/../lib/avro-1.4.0-sources-fixes.jar:/software/cassandra/bin/../lib/commons-cli-1.1.jar:/software/cassandra/bin/../lib/commons-codec-1.2.jar:/software/cassandra/bin/../lib/commons-collections-3.2.1.jar:/software/cassandra/bin/../lib/commons-lang-2.4.jar:/software/cassandra/bin/../lib/concurrentlinkedhashmap-lru-1.1.jar:/software/cassandra/bin/../lib/guava-r05.jar:/software/cassandra/bin/../lib/high-scale-lib.jar:/software/cassandra/bin/../lib/jackson-core-asl-1.4.0.jar:/software/cassandra/bin/../lib/jackson-mapper-asl-1.4.0.jar:/software/cassandra/bin/../lib/jetty-6.1.21.jar:/software/cassandra/bin/../lib/jetty-util-6.1.21.jar:/software/cassandra/bin/../lib/jline-0.9.94.jar:/software/cassandra/bin/../lib/json-simple-1.1.jar:/software/cassandra/bin/../lib/jug-2.0.0.jar:/software/cassandra/bin/../lib/libthrift-0.5.jar:/software/cassandra/bin/../lib/log4j-1.2.16.jar:/software/cassandra/bin/../lib/servlet-api-2.5-20081211.jar:/software/cassandra/bin/../lib/slf4j-api-1.6.1.jar:/software/cassandra/bin/../lib/slf4j-log4j12-1.6.1.jar:/software/cassandra/bin/../lib/snakeyaml-1.6.jar > org.apache.cassandra.thrift.CassandraDaemon -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2542) InvalidRequestException
[
https://issues.apache.org/jira/browse/CASSANDRA-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023217#comment-13023217
]
Timu Eren commented on CASSANDRA-2542:
--
i have absolutely no idea why i get this exception, if i use column names
instead SliceRange for SlicePredicate does not change at all
> InvalidRequestException
> ---
>
> Key: CASSANDRA-2542
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2542
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 0.7.4
>Reporter: Timu Eren
>Priority: Minor
>
> i got InvalidRequestException when execute map reduce jobs on supercolumn, if
> i set the comparator as LongType, other types (AsciiType, UTF8Type,
> IntegerType) works just fine
> Here is reprocedure details.
> create column family
> SuperTest
> with
> column_type=Super and
> comparator=LongType and
> subcomparator=UTF8Type and
> default_validation_class=UTF8Type;
> list SuperTest;
> Using default limit of 100
> ---
> RowKey: 2
> => (super_column=10,
> (column=1, value=1, timestamp=1303459440853000))
> => (super_column=11,
> (column=1, value=1, timestamp=1303459437632000))
> => (super_column=12,
> (column=1, value=1, timestamp=1303459432652000))
> => (super_column=13,
> (column=1, value=1, timestamp=1303459435102000))
> ---
> RowKey: 1
> => (super_column=10,
> (column=1, value=1, timestamp=1303459423202000))
> => (super_column=11,
> (column=1, value=1, timestamp=1303459419112000))
> => (super_column=12,
> (column=deneme, value=1, timestamp=1303459362702000))
> => (super_column=13,
> (column=deneme, value=1, timestamp=1303459382023000))
> => (super_column=15,
> (column=1, value=1, timestamp=1303459426402000))
> 2 Rows Returned.
> == Test class ==
> import java.io.IOException;
> import java.nio.ByteBuffer;
> import java.util.List;
> import java.util.SortedMap;
> import org.apache.cassandra.hadoop.ColumnFamilyInputFormat;
> import org.apache.cassandra.hadoop.ColumnFamilyOutputFormat;
> import org.apache.cassandra.hadoop.ConfigHelper;
> import org.apache.cassandra.avro.Mutation;
> import org.apache.cassandra.thrift.SliceRange;
> import org.apache.cassandra.thrift.SlicePredicate;
> import org.apache.cassandra.utils.ByteBufferUtil;
> import org.apache.cassandra.db.IColumn;
> import org.apache.hadoop.conf.Configuration;
> import org.apache.hadoop.conf.Configured;
> import org.apache.hadoop.io.IntWritable;
> import org.apache.hadoop.io.Text;
> import org.apache.hadoop.mapreduce.Job;
> import org.apache.hadoop.mapreduce.Mapper;
> import org.apache.hadoop.mapreduce.Reducer;
> import org.apache.hadoop.util.Tool;
> import org.apache.hadoop.util.ToolRunner;
> import org.slf4j.Logger;
> import org.slf4j.LoggerFactory;
> class SuperColumnTest extends Configured implements Tool {
>
> private static final Logger logger =
> LoggerFactory.getLogger(SuperColumnTest.class);
>
> public static void main(String[] args) throws Exception {
> ToolRunner.run(new Configuration(), new SuperColumnTest(), args);
> System.exit(0);
> }
>
> public static class SuperColumnTestMapper extends Mapper SortedMap, Text, IntWritable> {
> private static final Logger logger =
> LoggerFactory.getLogger(SuperColumnTestMapper.class);
>
> public void map(ByteBuffer key, SortedMap
> columns, Context context) throws IOException, InterruptedException {
>
> logger.info(String.format("Key:%s, size: %s",
> ByteBufferUtil.string(key), columns.size()));
>
>
> }
> }
>
> public static class SuperColumnTestReducer extends Reducer IntWritable, ByteBuffer, List> {
> public void reduce(Text key, Iterable values, Context
> context) throws IOException, InterruptedException {
>
> }
> }
>
> public int run(String[] args) throws Exception{
>
> Job job = new Job(this.getConf(), "SuperColumnMapReduceTest");
> job.setJarByClass(SuperColumnTest.class);
> job.setMapperClass(SuperColumnTestMapper.class);
> job.setReducerClass(SuperColumnTestReducer.class);
>
>
> job.setOutputFormatClass(ColumnFamilyOutputFormat.class);
> ConfigHelper.setOutputColumnFamily(job.getConfiguration(), "",
> "SuperTest");
>
> job.setMapOutputKeyClass(Text.class);
> job.setMapOutputValueClass(IntWritable.class);
>
> job.setOutputKeyClass(ByteBuffer.class);
> job.setOutputValueClass(List.class);
> job.setInputFormatClass(ColumnFamilyInputFormat.class);
>
>
> ConfigHelper.setInputColumnFamily(job.getConfi
[jira] [Commented] (CASSANDRA-2543) Node not responding, bringing down cluster, marked as up
[ https://issues.apache.org/jira/browse/CASSANDRA-2543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023213#comment-13023213 ] Jonathan Ellis commented on CASSANDRA-2543: --- sounds like your node is OOMing enable gc logging and check gc thread CPU usage (http://publib.boulder.ibm.com/infocenter/javasdk/tools/index.jsp?topic=/com.ibm.java.doc.igaa/_1vg0001475cb4a-1190e2e0f74-8000_1007.html) re "bringing down cluster", are you sure dynamic snitch is enabled? > Node not responding, bringing down cluster, marked as up > > > Key: CASSANDRA-2543 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2543 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.7.4 >Reporter: Thibaut > Fix For: 0.7.6 > > Attachments: jstack > > > I have one node which constantly hangs and brings done the entire cluster > (not giving any answers). > If I restart the node, the node will hang after a certain number of time. I > have no indication > It's marked as up when executing the nodetool ring command. > Executing the ring command on the node itself (without any traffic on the > cluster) takes at least 2 minutes to execute. The node takes about 50%-100% > of cpu over all cpus. > Netstats doesn't list anything interesting: > /software/cassandra/bin/nodetool -h localhost netstats > Mode: Normal > Not sending any streams. > Not receiving any streams. > Pool NameActive Pending Completed > Commandsn/a 0 51064 > Responses n/a 0 530479 > I attached the jstack of the node. There are no indications that the node has > faulty hardware. > /usr/bin/java -ea -XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 > -Xms5254M -Xmx5254M -Xmn400M -XX:+HeapDumpOnOutOfMemoryError -Xss128k > -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled > -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=1 > -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly > -Djava.net.preferIPv4Stack=true -Dcom.sun.management.jmxremote.port=8080 > -Dcom.sun.management.jmxremote.ssl=false > -Dcom.sun.management.jmxremote.authenticate=false > -Dlog4j.configuration=log4j-server.properties > -Dlog4j.defaultInitOverride=true -Dcassandra-foreground=yes -cp > /software/cassandra/bin/../conf:/software/cassandra/bin/../build/classes:/software/cassandra/bin/../lib/antlr-3.1.3.jar:/software/cassandra/bin/../lib/apache-cassandra-0.7.4.jar:/software/cassandra/bin/../lib/avro-1.4.0-fixes.jar:/software/cassandra/bin/../lib/avro-1.4.0-sources-fixes.jar:/software/cassandra/bin/../lib/commons-cli-1.1.jar:/software/cassandra/bin/../lib/commons-codec-1.2.jar:/software/cassandra/bin/../lib/commons-collections-3.2.1.jar:/software/cassandra/bin/../lib/commons-lang-2.4.jar:/software/cassandra/bin/../lib/concurrentlinkedhashmap-lru-1.1.jar:/software/cassandra/bin/../lib/guava-r05.jar:/software/cassandra/bin/../lib/high-scale-lib.jar:/software/cassandra/bin/../lib/jackson-core-asl-1.4.0.jar:/software/cassandra/bin/../lib/jackson-mapper-asl-1.4.0.jar:/software/cassandra/bin/../lib/jetty-6.1.21.jar:/software/cassandra/bin/../lib/jetty-util-6.1.21.jar:/software/cassandra/bin/../lib/jline-0.9.94.jar:/software/cassandra/bin/../lib/json-simple-1.1.jar:/software/cassandra/bin/../lib/jug-2.0.0.jar:/software/cassandra/bin/../lib/libthrift-0.5.jar:/software/cassandra/bin/../lib/log4j-1.2.16.jar:/software/cassandra/bin/../lib/servlet-api-2.5-20081211.jar:/software/cassandra/bin/../lib/slf4j-api-1.6.1.jar:/software/cassandra/bin/../lib/slf4j-log4j12-1.6.1.jar:/software/cassandra/bin/../lib/snakeyaml-1.6.jar > org.apache.cassandra.thrift.CassandraDaemon -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2542) InvalidRequestException
[
https://issues.apache.org/jira/browse/CASSANDRA-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023212#comment-13023212
]
Jonathan Ellis commented on CASSANDRA-2542:
---
and what is IRE.why?
> InvalidRequestException
> ---
>
> Key: CASSANDRA-2542
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2542
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 0.7.4
>Reporter: Timu Eren
>Priority: Minor
>
> i got InvalidRequestException when execute map reduce jobs on supercolumn, if
> i set the comparator as LongType, other types (AsciiType, UTF8Type,
> IntegerType) works just fine
> Here is reprocedure details.
> create column family
> SuperTest
> with
> column_type=Super and
> comparator=LongType and
> subcomparator=UTF8Type and
> default_validation_class=UTF8Type;
> list SuperTest;
> Using default limit of 100
> ---
> RowKey: 2
> => (super_column=10,
> (column=1, value=1, timestamp=1303459440853000))
> => (super_column=11,
> (column=1, value=1, timestamp=1303459437632000))
> => (super_column=12,
> (column=1, value=1, timestamp=1303459432652000))
> => (super_column=13,
> (column=1, value=1, timestamp=1303459435102000))
> ---
> RowKey: 1
> => (super_column=10,
> (column=1, value=1, timestamp=1303459423202000))
> => (super_column=11,
> (column=1, value=1, timestamp=1303459419112000))
> => (super_column=12,
> (column=deneme, value=1, timestamp=1303459362702000))
> => (super_column=13,
> (column=deneme, value=1, timestamp=1303459382023000))
> => (super_column=15,
> (column=1, value=1, timestamp=1303459426402000))
> 2 Rows Returned.
> == Test class ==
> import java.io.IOException;
> import java.nio.ByteBuffer;
> import java.util.List;
> import java.util.SortedMap;
> import org.apache.cassandra.hadoop.ColumnFamilyInputFormat;
> import org.apache.cassandra.hadoop.ColumnFamilyOutputFormat;
> import org.apache.cassandra.hadoop.ConfigHelper;
> import org.apache.cassandra.avro.Mutation;
> import org.apache.cassandra.thrift.SliceRange;
> import org.apache.cassandra.thrift.SlicePredicate;
> import org.apache.cassandra.utils.ByteBufferUtil;
> import org.apache.cassandra.db.IColumn;
> import org.apache.hadoop.conf.Configuration;
> import org.apache.hadoop.conf.Configured;
> import org.apache.hadoop.io.IntWritable;
> import org.apache.hadoop.io.Text;
> import org.apache.hadoop.mapreduce.Job;
> import org.apache.hadoop.mapreduce.Mapper;
> import org.apache.hadoop.mapreduce.Reducer;
> import org.apache.hadoop.util.Tool;
> import org.apache.hadoop.util.ToolRunner;
> import org.slf4j.Logger;
> import org.slf4j.LoggerFactory;
> class SuperColumnTest extends Configured implements Tool {
>
> private static final Logger logger =
> LoggerFactory.getLogger(SuperColumnTest.class);
>
> public static void main(String[] args) throws Exception {
> ToolRunner.run(new Configuration(), new SuperColumnTest(), args);
> System.exit(0);
> }
>
> public static class SuperColumnTestMapper extends Mapper SortedMap, Text, IntWritable> {
> private static final Logger logger =
> LoggerFactory.getLogger(SuperColumnTestMapper.class);
>
> public void map(ByteBuffer key, SortedMap
> columns, Context context) throws IOException, InterruptedException {
>
> logger.info(String.format("Key:%s, size: %s",
> ByteBufferUtil.string(key), columns.size()));
>
>
> }
> }
>
> public static class SuperColumnTestReducer extends Reducer IntWritable, ByteBuffer, List> {
> public void reduce(Text key, Iterable values, Context
> context) throws IOException, InterruptedException {
>
> }
> }
>
> public int run(String[] args) throws Exception{
>
> Job job = new Job(this.getConf(), "SuperColumnMapReduceTest");
> job.setJarByClass(SuperColumnTest.class);
> job.setMapperClass(SuperColumnTestMapper.class);
> job.setReducerClass(SuperColumnTestReducer.class);
>
>
> job.setOutputFormatClass(ColumnFamilyOutputFormat.class);
> ConfigHelper.setOutputColumnFamily(job.getConfiguration(), "",
> "SuperTest");
>
> job.setMapOutputKeyClass(Text.class);
> job.setMapOutputValueClass(IntWritable.class);
>
> job.setOutputKeyClass(ByteBuffer.class);
> job.setOutputValueClass(List.class);
> job.setInputFormatClass(ColumnFamilyInputFormat.class);
>
>
> ConfigHelper.setInputColumnFamily(job.getConfiguration(), "",
> "SuperTest");
> ConfigHelper.setRpcPort(job.getConfiguration(), "9160");
>
[jira] [Updated] (CASSANDRA-2537) CQL: Error performing batch insert
[
https://issues.apache.org/jira/browse/CASSANDRA-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-2537:
--
Priority: Minor (was: Major)
Affects Version/s: (was: 0.8.0)
0.8 beta 1
Fix Version/s: 0.8.0
> CQL: Error performing batch insert
> --
>
> Key: CASSANDRA-2537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2537
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 0.8 beta 1
> Environment: 3-node Centos 5.5 cluster running 0.8 build from apr20.
>Reporter: Cathy Daw
>Assignee: Pavel Yaskevich
>Priority: Minor
> Labels: cql
> Fix For: 0.8.0
>
>
> *Test Case To Run*
> {code}
> // Setup
> CREATE COLUMNFAMILY users (
> KEY varchar PRIMARY KEY,
> password varchar);
> //Batch Insert
> BEGIN BATCH USING QUORUM
> INSERT INTO users (KEY, password) VALUES ('user2', 'ch@ngem3b');
> INSERT INTO users (KEY, password) VALUES ('user3', 'ch@ngem3c');
> APPLY BATCH
> {code}
> *Actual Behavior*
> {code}
> cqlsh> BEGIN BATCH USING QUORUM
>... INSERT INTO users (KEY, password) VALUES ('user2', 'ch@ngem3b');
> Bad Request: line 0:-1 mismatched input '' expecting K_APPLY
> {code}
> *Documentation Sample*
> {code}
> BEGIN BATCH [USING ]
> UPDATE CF1 SET name1 = value1, name2 = value2 WHERE KEY = keyname1;
> UPDATE CF1 SET name3 = value3 WHERE KEY = keyname2;
> UPDATE CF2 SET name4 = value4, name5 = value5 WHERE KEY = keyname3;
> APPLY BATCH
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-2537) CQL: Error performing batch insert
[
https://issues.apache.org/jira/browse/CASSANDRA-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis reassigned CASSANDRA-2537:
-
Assignee: Pavel Yaskevich
batch does not support insert syntax yet, only update. Pavel to fix.
> CQL: Error performing batch insert
> --
>
> Key: CASSANDRA-2537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2537
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 0.8.0
> Environment: 3-node Centos 5.5 cluster running 0.8 build from apr20.
>Reporter: Cathy Daw
>Assignee: Pavel Yaskevich
> Labels: cql
>
> *Test Case To Run*
> {code}
> // Setup
> CREATE COLUMNFAMILY users (
> KEY varchar PRIMARY KEY,
> password varchar);
> //Batch Insert
> BEGIN BATCH USING QUORUM
> INSERT INTO users (KEY, password) VALUES ('user2', 'ch@ngem3b');
> INSERT INTO users (KEY, password) VALUES ('user3', 'ch@ngem3c');
> APPLY BATCH
> {code}
> *Actual Behavior*
> {code}
> cqlsh> BEGIN BATCH USING QUORUM
>... INSERT INTO users (KEY, password) VALUES ('user2', 'ch@ngem3b');
> Bad Request: line 0:-1 mismatched input '' expecting K_APPLY
> {code}
> *Documentation Sample*
> {code}
> BEGIN BATCH [USING ]
> UPDATE CF1 SET name1 = value1, name2 = value2 WHERE KEY = keyname1;
> UPDATE CF1 SET name3 = value3 WHERE KEY = keyname2;
> UPDATE CF2 SET name4 = value4, name5 = value5 WHERE KEY = keyname3;
> APPLY BATCH
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2540) Data reads by default
[
https://issues.apache.org/jira/browse/CASSANDRA-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-2540:
--
Priority: Minor (was: Major)
Fix Version/s: (was: 0.8.0)
Labels: ponies (was: )
Issue Type: Wish (was: Bug)
> Data reads by default
> -
>
> Key: CASSANDRA-2540
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2540
> Project: Cassandra
> Issue Type: Wish
>Reporter: Stu Hood
>Priority: Minor
> Labels: ponies
>
> The intention of digest vs data reads is to save bandwidth in the read path
> at the cost of latency, but I expect that this has been a premature
> optimization.
> * Data requested by a read will often be within an order of magnitude of the
> digest size, and a failed digest means extra roundtrips, more bandwidth
> * The [digest reads but not your data
> read|https://issues.apache.org/jira/browse/CASSANDRA-2282?focusedCommentId=13004656&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13004656]
> problem means failing QUORUM reads because a single node is unavailable, and
> would require eagerly re-requesting at some fraction of your timeout
> * Saving bandwidth in cross datacenter usecases comes at huge cost to
> latency, but since both constraints change proportionally (enough), the
> tradeoff is not clear
> Some options:
> # Add an option to use digest reads
> # Remove digest reads entirely (and/or punt and make them a runtime
> optimization based on data size in the future)
> # Continue to use digest reads, but send them to {{N - R}} nodes for
> (somewhat) more predicatable behavior with QUORUM
> \\
> The outcome of data-reads-by-default should be significantly improved
> latency, with a moderate increase in bandwidth usage for large reads.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2543) Node not responding, bringing down cluster, marked as up
[ https://issues.apache.org/jira/browse/CASSANDRA-2543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023209#comment-13023209 ] Thibaut commented on CASSANDRA-2543: /software/cassandra/bin/nodetool -h localhost info 199 Gossip active: true Load : 161.12 GB Generation No: 1303472783 Uptime (seconds) : 5024 Heap Memory (MB) : 3656.35 / 5214.00 As mentioned, restarting the node will put the node into this state again after some time. > Node not responding, bringing down cluster, marked as up > > > Key: CASSANDRA-2543 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2543 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.7.4 >Reporter: Thibaut > Fix For: 0.7.6 > > Attachments: jstack > > > I have one node which constantly hangs and brings done the entire cluster > (not giving any answers). > If I restart the node, the node will hang after a certain number of time. I > have no indication > It's marked as up when executing the nodetool ring command. > Executing the ring command on the node itself (without any traffic on the > cluster) takes at least 2 minutes to execute. The node takes about 50%-100% > of cpu over all cpus. > Netstats doesn't list anything interesting: > /software/cassandra/bin/nodetool -h localhost netstats > Mode: Normal > Not sending any streams. > Not receiving any streams. > Pool NameActive Pending Completed > Commandsn/a 0 51064 > Responses n/a 0 530479 > I attached the jstack of the node. There are no indications that the node has > faulty hardware. > /usr/bin/java -ea -XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 > -Xms5254M -Xmx5254M -Xmn400M -XX:+HeapDumpOnOutOfMemoryError -Xss128k > -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled > -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=1 > -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly > -Djava.net.preferIPv4Stack=true -Dcom.sun.management.jmxremote.port=8080 > -Dcom.sun.management.jmxremote.ssl=false > -Dcom.sun.management.jmxremote.authenticate=false > -Dlog4j.configuration=log4j-server.properties > -Dlog4j.defaultInitOverride=true -Dcassandra-foreground=yes -cp > /software/cassandra/bin/../conf:/software/cassandra/bin/../build/classes:/software/cassandra/bin/../lib/antlr-3.1.3.jar:/software/cassandra/bin/../lib/apache-cassandra-0.7.4.jar:/software/cassandra/bin/../lib/avro-1.4.0-fixes.jar:/software/cassandra/bin/../lib/avro-1.4.0-sources-fixes.jar:/software/cassandra/bin/../lib/commons-cli-1.1.jar:/software/cassandra/bin/../lib/commons-codec-1.2.jar:/software/cassandra/bin/../lib/commons-collections-3.2.1.jar:/software/cassandra/bin/../lib/commons-lang-2.4.jar:/software/cassandra/bin/../lib/concurrentlinkedhashmap-lru-1.1.jar:/software/cassandra/bin/../lib/guava-r05.jar:/software/cassandra/bin/../lib/high-scale-lib.jar:/software/cassandra/bin/../lib/jackson-core-asl-1.4.0.jar:/software/cassandra/bin/../lib/jackson-mapper-asl-1.4.0.jar:/software/cassandra/bin/../lib/jetty-6.1.21.jar:/software/cassandra/bin/../lib/jetty-util-6.1.21.jar:/software/cassandra/bin/../lib/jline-0.9.94.jar:/software/cassandra/bin/../lib/json-simple-1.1.jar:/software/cassandra/bin/../lib/jug-2.0.0.jar:/software/cassandra/bin/../lib/libthrift-0.5.jar:/software/cassandra/bin/../lib/log4j-1.2.16.jar:/software/cassandra/bin/../lib/servlet-api-2.5-20081211.jar:/software/cassandra/bin/../lib/slf4j-api-1.6.1.jar:/software/cassandra/bin/../lib/slf4j-log4j12-1.6.1.jar:/software/cassandra/bin/../lib/snakeyaml-1.6.jar > org.apache.cassandra.thrift.CassandraDaemon -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2543) Node not responding, bringing down cluster, marked as up
[ https://issues.apache.org/jira/browse/CASSANDRA-2543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thibaut updated CASSANDRA-2543: --- Attachment: jstack > Node not responding, bringing down cluster, marked as up > > > Key: CASSANDRA-2543 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2543 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.7.4 >Reporter: Thibaut > Fix For: 0.7.6 > > Attachments: jstack > > > I have one node which constantly hangs and brings done the entire cluster > (not giving any answers). > If I restart the node, the node will hang after a certain number of time. I > have no indication > It's marked as up when executing the nodetool ring command. > Executing the ring command on the node itself (without any traffic on the > cluster) takes at least 2 minutes to execute. The node takes about 50%-100% > of cpu over all cpus. > Netstats doesn't list anything interesting: > /software/cassandra/bin/nodetool -h localhost netstats > Mode: Normal > Not sending any streams. > Not receiving any streams. > Pool NameActive Pending Completed > Commandsn/a 0 51064 > Responses n/a 0 530479 > I attached the jstack of the node. There are no indications that the node has > faulty hardware. > /usr/bin/java -ea -XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 > -Xms5254M -Xmx5254M -Xmn400M -XX:+HeapDumpOnOutOfMemoryError -Xss128k > -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled > -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=1 > -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly > -Djava.net.preferIPv4Stack=true -Dcom.sun.management.jmxremote.port=8080 > -Dcom.sun.management.jmxremote.ssl=false > -Dcom.sun.management.jmxremote.authenticate=false > -Dlog4j.configuration=log4j-server.properties > -Dlog4j.defaultInitOverride=true -Dcassandra-foreground=yes -cp > /software/cassandra/bin/../conf:/software/cassandra/bin/../build/classes:/software/cassandra/bin/../lib/antlr-3.1.3.jar:/software/cassandra/bin/../lib/apache-cassandra-0.7.4.jar:/software/cassandra/bin/../lib/avro-1.4.0-fixes.jar:/software/cassandra/bin/../lib/avro-1.4.0-sources-fixes.jar:/software/cassandra/bin/../lib/commons-cli-1.1.jar:/software/cassandra/bin/../lib/commons-codec-1.2.jar:/software/cassandra/bin/../lib/commons-collections-3.2.1.jar:/software/cassandra/bin/../lib/commons-lang-2.4.jar:/software/cassandra/bin/../lib/concurrentlinkedhashmap-lru-1.1.jar:/software/cassandra/bin/../lib/guava-r05.jar:/software/cassandra/bin/../lib/high-scale-lib.jar:/software/cassandra/bin/../lib/jackson-core-asl-1.4.0.jar:/software/cassandra/bin/../lib/jackson-mapper-asl-1.4.0.jar:/software/cassandra/bin/../lib/jetty-6.1.21.jar:/software/cassandra/bin/../lib/jetty-util-6.1.21.jar:/software/cassandra/bin/../lib/jline-0.9.94.jar:/software/cassandra/bin/../lib/json-simple-1.1.jar:/software/cassandra/bin/../lib/jug-2.0.0.jar:/software/cassandra/bin/../lib/libthrift-0.5.jar:/software/cassandra/bin/../lib/log4j-1.2.16.jar:/software/cassandra/bin/../lib/servlet-api-2.5-20081211.jar:/software/cassandra/bin/../lib/slf4j-api-1.6.1.jar:/software/cassandra/bin/../lib/slf4j-log4j12-1.6.1.jar:/software/cassandra/bin/../lib/snakeyaml-1.6.jar > org.apache.cassandra.thrift.CassandraDaemon -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2543) Node not responding, bringing down cluster, marked as up
Node not responding, bringing down cluster, marked as up Key: CASSANDRA-2543 URL: https://issues.apache.org/jira/browse/CASSANDRA-2543 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.4 Reporter: Thibaut Fix For: 0.7.6 Attachments: jstack I have one node which constantly hangs and brings done the entire cluster (not giving any answers). If I restart the node, the node will hang after a certain number of time. I have no indication It's marked as up when executing the nodetool ring command. Executing the ring command on the node itself (without any traffic on the cluster) takes at least 2 minutes to execute. The node takes about 50%-100% of cpu over all cpus. Netstats doesn't list anything interesting: /software/cassandra/bin/nodetool -h localhost netstats Mode: Normal Not sending any streams. Not receiving any streams. Pool NameActive Pending Completed Commandsn/a 0 51064 Responses n/a 0 530479 I attached the jstack of the node. There are no indications that the node has faulty hardware. /usr/bin/java -ea -XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 -Xms5254M -Xmx5254M -Xmn400M -XX:+HeapDumpOnOutOfMemoryError -Xss128k -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=1 -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -Djava.net.preferIPv4Stack=true -Dcom.sun.management.jmxremote.port=8080 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Dlog4j.configuration=log4j-server.properties -Dlog4j.defaultInitOverride=true -Dcassandra-foreground=yes -cp /software/cassandra/bin/../conf:/software/cassandra/bin/../build/classes:/software/cassandra/bin/../lib/antlr-3.1.3.jar:/software/cassandra/bin/../lib/apache-cassandra-0.7.4.jar:/software/cassandra/bin/../lib/avro-1.4.0-fixes.jar:/software/cassandra/bin/../lib/avro-1.4.0-sources-fixes.jar:/software/cassandra/bin/../lib/commons-cli-1.1.jar:/software/cassandra/bin/../lib/commons-codec-1.2.jar:/software/cassandra/bin/../lib/commons-collections-3.2.1.jar:/software/cassandra/bin/../lib/commons-lang-2.4.jar:/software/cassandra/bin/../lib/concurrentlinkedhashmap-lru-1.1.jar:/software/cassandra/bin/../lib/guava-r05.jar:/software/cassandra/bin/../lib/high-scale-lib.jar:/software/cassandra/bin/../lib/jackson-core-asl-1.4.0.jar:/software/cassandra/bin/../lib/jackson-mapper-asl-1.4.0.jar:/software/cassandra/bin/../lib/jetty-6.1.21.jar:/software/cassandra/bin/../lib/jetty-util-6.1.21.jar:/software/cassandra/bin/../lib/jline-0.9.94.jar:/software/cassandra/bin/../lib/json-simple-1.1.jar:/software/cassandra/bin/../lib/jug-2.0.0.jar:/software/cassandra/bin/../lib/libthrift-0.5.jar:/software/cassandra/bin/../lib/log4j-1.2.16.jar:/software/cassandra/bin/../lib/servlet-api-2.5-20081211.jar:/software/cassandra/bin/../lib/slf4j-api-1.6.1.jar:/software/cassandra/bin/../lib/slf4j-log4j12-1.6.1.jar:/software/cassandra/bin/../lib/snakeyaml-1.6.jar org.apache.cassandra.thrift.CassandraDaemon -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2540) Data reads by default
[
https://issues.apache.org/jira/browse/CASSANDRA-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023208#comment-13023208
]
Sylvain Lebresne commented on CASSANDRA-2540:
-
bq. so I think we don't expect the dynamic snitch to kick in until RPC timeouts
True for dead or in very bad shape node, and in my opinion avoiding a single
dead node to fail a QUORUM request is clearly the most important part of this
ticket. However for node getting saturated, this usually is at least slightly
gradual so the dynamic snitch should adapt and start avoiding the node "long"
before it actually stop responding. That's, I think, when the dynamic snitch
make sense, dead node are a job for the failure detector.
> Data reads by default
> -
>
> Key: CASSANDRA-2540
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2540
> Project: Cassandra
> Issue Type: Bug
>Reporter: Stu Hood
> Fix For: 0.8.0
>
>
> The intention of digest vs data reads is to save bandwidth in the read path
> at the cost of latency, but I expect that this has been a premature
> optimization.
> * Data requested by a read will often be within an order of magnitude of the
> digest size, and a failed digest means extra roundtrips, more bandwidth
> * The [digest reads but not your data
> read|https://issues.apache.org/jira/browse/CASSANDRA-2282?focusedCommentId=13004656&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13004656]
> problem means failing QUORUM reads because a single node is unavailable, and
> would require eagerly re-requesting at some fraction of your timeout
> * Saving bandwidth in cross datacenter usecases comes at huge cost to
> latency, but since both constraints change proportionally (enough), the
> tradeoff is not clear
> Some options:
> # Add an option to use digest reads
> # Remove digest reads entirely (and/or punt and make them a runtime
> optimization based on data size in the future)
> # Continue to use digest reads, but send them to {{N - R}} nodes for
> (somewhat) more predicatable behavior with QUORUM
> \\
> The outcome of data-reads-by-default should be significantly improved
> latency, with a moderate increase in bandwidth usage for large reads.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2540) Data reads by default
[
https://issues.apache.org/jira/browse/CASSANDRA-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023207#comment-13023207
]
Peter Schuller commented on CASSANDRA-2540:
---
Fair enough ;)
Just one point about the dynamic snitch: It's true, though it's also the case
that the dynamic snitch has a periodicity to it and doesn't alter endpoint
selection in "real" time. With the default of 100 ms, at a request rate of
1000, you still have 50 requests on average that will be adversely affected in
the event of a node hiccup. And that's assuming instant feedback which I don't
think is the case (i.e., I believe requests have to actually time out before
they get accounted as high-latency, so I think we don't expect the dynamic
snitch to kick in until RPC timeouts, meaning that at a request rate of 1k you
expect thousands of requests to be affected).
In that sense, it would be nice to avoid extreme outliers without having to do
something like making dynamic re-routing terribly aggressive (which has
potential for foot-shooting if the feedback mechanism is too immediate).
So I guess my point is: the dynamic snitch is a different attack vector to a
related but not identical problem.
> Data reads by default
> -
>
> Key: CASSANDRA-2540
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2540
> Project: Cassandra
> Issue Type: Bug
>Reporter: Stu Hood
> Fix For: 0.8.0
>
>
> The intention of digest vs data reads is to save bandwidth in the read path
> at the cost of latency, but I expect that this has been a premature
> optimization.
> * Data requested by a read will often be within an order of magnitude of the
> digest size, and a failed digest means extra roundtrips, more bandwidth
> * The [digest reads but not your data
> read|https://issues.apache.org/jira/browse/CASSANDRA-2282?focusedCommentId=13004656&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13004656]
> problem means failing QUORUM reads because a single node is unavailable, and
> would require eagerly re-requesting at some fraction of your timeout
> * Saving bandwidth in cross datacenter usecases comes at huge cost to
> latency, but since both constraints change proportionally (enough), the
> tradeoff is not clear
> Some options:
> # Add an option to use digest reads
> # Remove digest reads entirely (and/or punt and make them a runtime
> optimization based on data size in the future)
> # Continue to use digest reads, but send them to {{N - R}} nodes for
> (somewhat) more predicatable behavior with QUORUM
> \\
> The outcome of data-reads-by-default should be significantly improved
> latency, with a moderate increase in bandwidth usage for large reads.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Cassandra Wiki] Update of "FAQ" by MakiWatanabe
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "FAQ" page has been changed by MakiWatanabe. The comment on this change is: Rewrite #seed. http://wiki.apache.org/cassandra/FAQ?action=diff&rev1=115&rev2=116 -- == What are seeds? == - Seeds, or seed nodes are the nodes which new nodes refer to on - bootstrap to know ring information. + If you configure your nodes to refer some node as seed, nodes in your ring tend to send Gossip message to seeds more often ( Refer to [[ArchitectureGossip]] for details ) than to non-seeds. In other words, seeds are worked as hubs of Gossip network. + With seeds, each node can detect status changes of other nodes quickly. + + Seeds are also referred by new nodes on bootstrap to learn other nodes in ring. When you add a new node to ring, you need to specify at least one live seed to contact. Once a node join the ring, it learns about the other nodes, so it doesn't need seed on subsequent boot. @@ -448, +450 @@ static ring, you can point non-seed node as seed on bootstrap though it is not recommended. - Nodes in the ring tend to send Gossip message to seeds more often ( Refer to [[ArchitectureGossip]] for more - details ) than to non-seeds. In other words, seeds are worked as hubs of Gossip network. - With seeds, each node can detect status changes of other nodes quickly. <>
[Cassandra Wiki] Update of "FAQ" by MakiWatanabe
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "FAQ" page has been changed by MakiWatanabe. The comment on this change is: Add #seed and #seed_spof. http://wiki.apache.org/cassandra/FAQ?action=diff&rev1=114&rev2=115 -- * [[#replicaplacement|How does Cassandra decide which nodes have what data?]] * [[#cachehitrateunits|I have a row or key cache hit rate of 0.XX123456789. Is that XX% or 0.XX% ?]] * [[#bigcommitlog|Commit Log gets very big. Cassandra does not delete "old" commit logs. Why?]] + * [[#seed|What are seeds?]] + * [[#seed_spof|Does single seed mean single point of failure?]] + <> @@ -431, +434 @@ update column family XXX with memtable_flush_after=60; + <> + + == What are seeds? == + + Seeds, or seed nodes are the nodes which new nodes refer to on + bootstrap to know ring information. + When you add a new node to ring, you need to specify at least one live + seed to contact. Once a node join the ring, it learns about the other + nodes, so it doesn't need seed on subsequent boot. + + There is no special configuration for seed node itself. In stable and + static ring, you can point non-seed node as seed on bootstrap though + it is not recommended. + + Nodes in the ring tend to send Gossip message to seeds more often ( Refer to [[ArchitectureGossip]] for more + details ) than to non-seeds. In other words, seeds are worked as hubs of Gossip network. + With seeds, each node can detect status changes of other nodes quickly. + + <> + + == Does single seed mean single point of failure? == + + If you are using replicated CF on the ring, only one seed in the ring + doesn't mean single point of failure. The ring can operate or boot + without the seed. However, it will need more time to spread status changes of node over the ring. + It is recommended to have multiple seeds in production system. +
[jira] [Updated] (CASSANDRA-2542) InvalidRequestException
[
https://issues.apache.org/jira/browse/CASSANDRA-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timu Eren updated CASSANDRA-2542:
-
Description:
i got InvalidRequestException when execute map reduce jobs on supercolumn, if i
set the comparator as LongType, other types (AsciiType, UTF8Type, IntegerType)
works just fine
Here is reprocedure details.
create column family
SuperTest
with
column_type=Super and
comparator=LongType and
subcomparator=UTF8Type and
default_validation_class=UTF8Type;
list SuperTest;
Using default limit of 100
---
RowKey: 2
=> (super_column=10,
(column=1, value=1, timestamp=1303459440853000))
=> (super_column=11,
(column=1, value=1, timestamp=1303459437632000))
=> (super_column=12,
(column=1, value=1, timestamp=1303459432652000))
=> (super_column=13,
(column=1, value=1, timestamp=1303459435102000))
---
RowKey: 1
=> (super_column=10,
(column=1, value=1, timestamp=1303459423202000))
=> (super_column=11,
(column=1, value=1, timestamp=1303459419112000))
=> (super_column=12,
(column=deneme, value=1, timestamp=1303459362702000))
=> (super_column=13,
(column=deneme, value=1, timestamp=1303459382023000))
=> (super_column=15,
(column=1, value=1, timestamp=1303459426402000))
2 Rows Returned.
== Test class ==
import java.io.IOException;
import java.nio.ByteBuffer;
import java.util.List;
import java.util.SortedMap;
import org.apache.cassandra.hadoop.ColumnFamilyInputFormat;
import org.apache.cassandra.hadoop.ColumnFamilyOutputFormat;
import org.apache.cassandra.hadoop.ConfigHelper;
import org.apache.cassandra.avro.Mutation;
import org.apache.cassandra.thrift.SliceRange;
import org.apache.cassandra.thrift.SlicePredicate;
import org.apache.cassandra.utils.ByteBufferUtil;
import org.apache.cassandra.db.IColumn;
import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.conf.Configured;
import org.apache.hadoop.io.IntWritable;
import org.apache.hadoop.io.Text;
import org.apache.hadoop.mapreduce.Job;
import org.apache.hadoop.mapreduce.Mapper;
import org.apache.hadoop.mapreduce.Reducer;
import org.apache.hadoop.util.Tool;
import org.apache.hadoop.util.ToolRunner;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
class SuperColumnTest extends Configured implements Tool {
private static final Logger logger =
LoggerFactory.getLogger(SuperColumnTest.class);
public static void main(String[] args) throws Exception {
ToolRunner.run(new Configuration(), new SuperColumnTest(), args);
System.exit(0);
}
public static class SuperColumnTestMapper extends Mapper, Text, IntWritable> {
private static final Logger logger =
LoggerFactory.getLogger(SuperColumnTestMapper.class);
public void map(ByteBuffer key, SortedMap columns,
Context context) throws IOException, InterruptedException {
logger.info(String.format("Key:%s, size: %s",
ByteBufferUtil.string(key), columns.size()));
}
}
public static class SuperColumnTestReducer extends Reducer> {
public void reduce(Text key, Iterable values, Context
context) throws IOException, InterruptedException {
}
}
public int run(String[] args) throws Exception{
Job job = new Job(this.getConf(), "SuperColumnMapReduceTest");
job.setJarByClass(SuperColumnTest.class);
job.setMapperClass(SuperColumnTestMapper.class);
job.setReducerClass(SuperColumnTestReducer.class);
job.setOutputFormatClass(ColumnFamilyOutputFormat.class);
ConfigHelper.setOutputColumnFamily(job.getConfiguration(), "",
"SuperTest");
job.setMapOutputKeyClass(Text.class);
job.setMapOutputValueClass(IntWritable.class);
job.setOutputKeyClass(ByteBuffer.class);
job.setOutputValueClass(List.class);
job.setInputFormatClass(ColumnFamilyInputFormat.class);
ConfigHelper.setInputColumnFamily(job.getConfiguration(), "",
"SuperTest");
ConfigHelper.setRpcPort(job.getConfiguration(), "9160");
ConfigHelper.setInitialAddress(job.getConfiguration(), "");
ConfigHelper.setPartitioner(job.getConfiguration(),
"org.apache.cassandra.dht.RandomPartitioner");
SlicePredicate sp =new SlicePredicate();
ByteBuffer startKey = ByteBuffer.wrap("".getBytes());
ByteBuffer endKey = ByteBuffer.wrap("".getBytes());
SliceRange range = new SliceRange();
range.setStart(startKey);
range.setFinish(endKey);
range.setCount(Integer.MAX_VALUE);
sp.setSlice_range(range);
ConfigHelper.setInputSlicePredicate(job.getConfiguration(), sp);
[jira] [Created] (CASSANDRA-2542) InvalidRequestException
InvalidRequestException --- Key: CASSANDRA-2542 URL: https://issues.apache.org/jira/browse/CASSANDRA-2542 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.4 Reporter: Timu Eren Priority: Minor i got InvalidRequestException when execute map reduce jobs on supercolumn, if i set the comparator as LongType, other types (AsciiType, UTF8Type, IntegerType) works just fine -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2541) Improve the precision of the repair merkle trees
Improve the precision of the repair merkle trees Key: CASSANDRA-2541 URL: https://issues.apache.org/jira/browse/CASSANDRA-2541 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.6 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 0.8.1 Repair uses the sstable sampled keys to split the merkle tree. This means the 'precision' of the tree will be index_interval (so 128 by default). This is probably fine when you have lots of skinny rows. But when you have less fat rows, this is probably unnecessary imprecise. Added to that the fact that each node will not have the same set of samples, you may not always end up using the more precise range in the trees when computing differences, which could make the imprecision worst (to be fair, it is quite possible this happens very rarely). Anyway, this ticket proposes to add an additional 'split_factor' (can be fixed, can be configurable (by the user or based on metrics on how fat the rows are)) that makes use re-split 'split_factor' times each ranges after the initial sample-based split of the tree. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2540) Data reads by default
[
https://issues.apache.org/jira/browse/CASSANDRA-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023190#comment-13023190
]
Sylvain Lebresne commented on CASSANDRA-2540:
-
bq. At least to me, "significantly improved latency" refers to the expected
behavior in the event of a single node being slow or individual messages being
dropped, etc. At least to me, this isn't about avoiding another network
round-trip to improve latency by a few milliseconds (or at least that is a
small part of it), but rather about experiencing a much more consistent latency
over time by removing outliers.
Yes, it will make for a more consistent latency upon failures, but failures are
not the norm overall (not saying they are not happening regularly nor what we
shouldn't try to handle them as well as we could) and it's unclear latency will
be better *on average*. So depends on what you want. As for GC and saturated
node, let's not forget that we have a dynamic snitch that is supposed to handle
that.
Again, I do agree there is room for improvements and let's totally explore that.
What I'm saying however is that it would be nice if we could avoid rushing into
expressions like "significantly improved latency" or "the potential latency
improvement is huge" before having tried anything and in general keep some
healthy amount of skepticism over what's an improvement and what's not. This is
not just about wording, this is about taking the time to validate we're not
screwing some people along the way. If you convince yourself too quickly that
something 'is the best thing ever', you're less likely to actually check that
it is. Anyway, just saying.
> Data reads by default
> -
>
> Key: CASSANDRA-2540
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2540
> Project: Cassandra
> Issue Type: Bug
>Reporter: Stu Hood
> Fix For: 0.8.0
>
>
> The intention of digest vs data reads is to save bandwidth in the read path
> at the cost of latency, but I expect that this has been a premature
> optimization.
> * Data requested by a read will often be within an order of magnitude of the
> digest size, and a failed digest means extra roundtrips, more bandwidth
> * The [digest reads but not your data
> read|https://issues.apache.org/jira/browse/CASSANDRA-2282?focusedCommentId=13004656&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13004656]
> problem means failing QUORUM reads because a single node is unavailable, and
> would require eagerly re-requesting at some fraction of your timeout
> * Saving bandwidth in cross datacenter usecases comes at huge cost to
> latency, but since both constraints change proportionally (enough), the
> tradeoff is not clear
> Some options:
> # Add an option to use digest reads
> # Remove digest reads entirely (and/or punt and make them a runtime
> optimization based on data size in the future)
> # Continue to use digest reads, but send them to {{N - R}} nodes for
> (somewhat) more predicatable behavior with QUORUM
> \\
> The outcome of data-reads-by-default should be significantly improved
> latency, with a moderate increase in bandwidth usage for large reads.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1095918 - in /cassandra/trunk: ./ contrib/ interface/thrift/gen-java/org/apache/cassandra/thrift/
Author: slebresne Date: Fri Apr 22 10:28:09 2011 New Revision: 1095918 URL: http://svn.apache.org/viewvc?rev=1095918&view=rev Log: merge from 0.8 Modified: cassandra/trunk/ (props changed) cassandra/trunk/CHANGES.txt cassandra/trunk/contrib/ (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/NotFoundException.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/SuperColumn.java (props changed) Propchange: cassandra/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Fri Apr 22 10:28:09 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1081914,1083000 -/cassandra/branches/cassandra-0.7:1026516-1095767 +/cassandra/branches/cassandra-0.7:1026516-1095767,1095916 /cassandra/branches/cassandra-0.7.0:1053690-1055654 -/cassandra/branches/cassandra-0.8:1090935-1095769 +/cassandra/branches/cassandra-0.8:1090935-1095769,1095917 /cassandra/tags/cassandra-0.7.0-rc3:1051699-1053689 /incubator/cassandra/branches/cassandra-0.3:774578-796573 /incubator/cassandra/branches/cassandra-0.4:810145-834239,834349-834350 Modified: cassandra/trunk/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/trunk/CHANGES.txt?rev=1095918&r1=1095917&r2=1095918&view=diff == --- cassandra/trunk/CHANGES.txt (original) +++ cassandra/trunk/CHANGES.txt Fri Apr 22 10:28:09 2011 @@ -28,41 +28,70 @@ 0.7.5 - * Avoid seeking when sstable2json exports the entire file (CASSANDRA-2318) + * improvements/fixes to PIG driver (CASSANDRA-1618, CASSANDRA-2387, + CASSANDRA-2465, CASSANDRA-2484) + * validate index names (CASSANDRA-1761) + * reduce contention on Table.flusherLock (CASSANDRA-1954) + * try harder to detect failures during streaming, cleaning up temporary + files more reliably (CASSANDRA-2088) + * shut down server for OOM on a Thrift thread (CASSANDRA-2269) * fix tombstone handling in repair and sstable2json (CASSANDRA-2279) + * preserve version when streaming data from old sstables (CASSANDRA-2283) + * don't start repair if a neighboring node is marked as dead (CASSANDRA-2290) + * purge tombstones from row cache (CASSANDRA-2305) + * Avoid seeking when sstable2json exports the entire file (CASSANDRA-2318) * clear Built flag in system table when dropping an index (CASSANDRA-2320) - * validate index names (CASSANDRA-1761) - * add memtable_flush_queue_size defaulting to 4 (CASSANDRA-2333) - * allow job configuration to set the CL used in Hadoop jobs (CASSANDRA-2331) + * don't allow arbitrary argument for stress.java (CASSANDRA-2323) + * validate values for index predicates in get_indexed_slice (CASSANDRA-2328) * queue secondary indexes for flush before the parent (CASSANDRA-2330) - * shut down server for OOM on a Thrift thread (CASSANDRA-2269) - * reduce contention on Table.flusherLock (CASSANDRA-1954) + * allow job configuration to set the CL used in Hadoop jobs (CASSANDRA-2331) + * add memtable_flush_queue_size defaulting to 4 (CASSANDRA-2333) + * Allow overriding of initial_token, storage_port and rpc_port from system + properties (CASSANDRA-2343) * fix comparator used for non-indexed secondary expressions in index scan (CASSANDRA-2347) * ensure size calculation and write phase of large-row compaction use the same threshold for TTL expiration (CASSANDRA-2349) * fix race when iterating CFs during add/drop (CASSANDRA-2350) * add ConsistencyLevel command to CLI (CASSANDRA-2354) + * allow negative numbers in the cli (CASSANDRA-2358) + * hard code serialVersionUID for tokens class (CASSANDRA-2361) * fix potential infinite loop in ByteBufferUtil.inputStream (CASSANDRA-2365) * fix encoding bugs in HintedHandoffManager, SystemTable when default charset is not UTF8 (CASSANDRA-2367) - * fsync statistics component on write (CASSANDRA-2382) - * fix incorrect truncation of long to int when reading columns via block + * avoids having removed node reappearing in Gossip (CASSANDRA-2371) + * fix incorrect truncation of long to int when reading columns via block index (CASSANDRA-2376) - * fix race condition that could leave orphaned data files when - dropping CF or KS (CASSANDRA-2381) + * fix NPE during stream session (CASSANDRA-2377) + * fix race condition that could leave orphaned data files when dropping CF or + KS (CASSANDRA-2381) + * fsync statistics component on write (CASSANDRA-2382) + * fix duplicate results from CFS.scan (CASSANDRA-2406) + * add IntegerType
svn commit: r1095917 - in /cassandra/branches/cassandra-0.8: ./ contrib/ interface/thrift/gen-java/org/apache/cassandra/thrift/
Author: slebresne Date: Fri Apr 22 10:26:56 2011 New Revision: 1095917 URL: http://svn.apache.org/viewvc?rev=1095917&view=rev Log: merge from 0.7 Modified: cassandra/branches/cassandra-0.8/ (props changed) cassandra/branches/cassandra-0.8/CHANGES.txt cassandra/branches/cassandra-0.8/contrib/ (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/NotFoundException.java (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/SuperColumn.java (props changed) Propchange: cassandra/branches/cassandra-0.8/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Fri Apr 22 10:26:56 2011 @@ -1,5 +1,5 @@ /cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1081914,1083000 -/cassandra/branches/cassandra-0.7:1026516-1095767 +/cassandra/branches/cassandra-0.7:1026516-1095767,1095916 /cassandra/branches/cassandra-0.7.0:1053690-1055654 /cassandra/tags/cassandra-0.7.0-rc3:1051699-1053689 /cassandra/trunk:1090978-1090979 Modified: cassandra/branches/cassandra-0.8/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/CHANGES.txt?rev=1095917&r1=1095916&r2=1095917&view=diff == --- cassandra/branches/cassandra-0.8/CHANGES.txt (original) +++ cassandra/branches/cassandra-0.8/CHANGES.txt Fri Apr 22 10:26:56 2011 @@ -32,41 +32,70 @@ 0.7.5 - * Avoid seeking when sstable2json exports the entire file (CASSANDRA-2318) + * improvements/fixes to PIG driver (CASSANDRA-1618, CASSANDRA-2387, + CASSANDRA-2465, CASSANDRA-2484) + * validate index names (CASSANDRA-1761) + * reduce contention on Table.flusherLock (CASSANDRA-1954) + * try harder to detect failures during streaming, cleaning up temporary + files more reliably (CASSANDRA-2088) + * shut down server for OOM on a Thrift thread (CASSANDRA-2269) * fix tombstone handling in repair and sstable2json (CASSANDRA-2279) + * preserve version when streaming data from old sstables (CASSANDRA-2283) + * don't start repair if a neighboring node is marked as dead (CASSANDRA-2290) + * purge tombstones from row cache (CASSANDRA-2305) + * Avoid seeking when sstable2json exports the entire file (CASSANDRA-2318) * clear Built flag in system table when dropping an index (CASSANDRA-2320) - * validate index names (CASSANDRA-1761) - * add memtable_flush_queue_size defaulting to 4 (CASSANDRA-2333) - * allow job configuration to set the CL used in Hadoop jobs (CASSANDRA-2331) + * don't allow arbitrary argument for stress.java (CASSANDRA-2323) + * validate values for index predicates in get_indexed_slice (CASSANDRA-2328) * queue secondary indexes for flush before the parent (CASSANDRA-2330) - * shut down server for OOM on a Thrift thread (CASSANDRA-2269) - * reduce contention on Table.flusherLock (CASSANDRA-1954) + * allow job configuration to set the CL used in Hadoop jobs (CASSANDRA-2331) + * add memtable_flush_queue_size defaulting to 4 (CASSANDRA-2333) + * Allow overriding of initial_token, storage_port and rpc_port from system + properties (CASSANDRA-2343) * fix comparator used for non-indexed secondary expressions in index scan (CASSANDRA-2347) * ensure size calculation and write phase of large-row compaction use the same threshold for TTL expiration (CASSANDRA-2349) * fix race when iterating CFs during add/drop (CASSANDRA-2350) * add ConsistencyLevel command to CLI (CASSANDRA-2354) + * allow negative numbers in the cli (CASSANDRA-2358) + * hard code serialVersionUID for tokens class (CASSANDRA-2361) * fix potential infinite loop in ByteBufferUtil.inputStream (CASSANDRA-2365) * fix encoding bugs in HintedHandoffManager, SystemTable when default charset is not UTF8 (CASSANDRA-2367) - * fsync statistics component on write (CASSANDRA-2382) - * fix incorrect truncation of long to int when reading columns via block + * avoids having removed node reappearing in Gossip (CASSANDRA-2371) + * fix incorrect truncation of long to int when reading columns via block index (CASSANDRA-2376) - * fix race condition that could leave orphaned data files when - dropping CF or KS (CASSANDRA-2381) + * fix NPE during stream session (CASSANDRA-2377) + * fix race condition that could leave orphaned data files when dropping CF or + KS (CASSANDRA-2381) + * fsync statistics component on write (CASSANDRA-2382) + * fix duplicate results from CFS.scan (CASSANDRA-2406) + * add
svn commit: r1095916 - /cassandra/branches/cassandra-0.7/CHANGES.txt
Author: slebresne Date: Fri Apr 22 10:24:16 2011 New Revision: 1095916 URL: http://svn.apache.org/viewvc?rev=1095916&view=rev Log: Update CHANGES.txt Modified: cassandra/branches/cassandra-0.7/CHANGES.txt Modified: cassandra/branches/cassandra-0.7/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/CHANGES.txt?rev=1095916&r1=1095915&r2=1095916&view=diff == --- cassandra/branches/cassandra-0.7/CHANGES.txt (original) +++ cassandra/branches/cassandra-0.7/CHANGES.txt Fri Apr 22 10:24:16 2011 @@ -1,42 +1,67 @@ 0.7.5 - * Avoid seeking when sstable2json exports the entire file (CASSANDRA-2318) + * improvements/fixes to PIG driver (CASSANDRA-1618, CASSANDRA-2387, + CASSANDRA-2465, CASSANDRA-2484) + * validate index names (CASSANDRA-1761) + * reduce contention on Table.flusherLock (CASSANDRA-1954) + * try harder to detect failures during streaming, cleaning up temporary + files more reliably (CASSANDRA-2088) + * shut down server for OOM on a Thrift thread (CASSANDRA-2269) * fix tombstone handling in repair and sstable2json (CASSANDRA-2279) + * preserve version when streaming data from old sstables (CASSANDRA-2283) + * don't start repair if a neighboring node is marked as dead (CASSANDRA-2290) + * purge tombstones from row cache (CASSANDRA-2305) + * Avoid seeking when sstable2json exports the entire file (CASSANDRA-2318) * clear Built flag in system table when dropping an index (CASSANDRA-2320) - * validate index names (CASSANDRA-1761) - * add memtable_flush_queue_size defaulting to 4 (CASSANDRA-2333) - * allow job configuration to set the CL used in Hadoop jobs (CASSANDRA-2331) + * don't allow arbitrary argument for stress.java (CASSANDRA-2323) + * validate values for index predicates in get_indexed_slice (CASSANDRA-2328) * queue secondary indexes for flush before the parent (CASSANDRA-2330) - * shut down server for OOM on a Thrift thread (CASSANDRA-2269) - * reduce contention on Table.flusherLock (CASSANDRA-1954) + * allow job configuration to set the CL used in Hadoop jobs (CASSANDRA-2331) + * add memtable_flush_queue_size defaulting to 4 (CASSANDRA-2333) + * Allow overriding of initial_token, storage_port and rpc_port from system + properties (CASSANDRA-2343) * fix comparator used for non-indexed secondary expressions in index scan (CASSANDRA-2347) * ensure size calculation and write phase of large-row compaction use the same threshold for TTL expiration (CASSANDRA-2349) * fix race when iterating CFs during add/drop (CASSANDRA-2350) * add ConsistencyLevel command to CLI (CASSANDRA-2354) + * allow negative numbers in the cli (CASSANDRA-2358) + * hard code serialVersionUID for tokens class (CASSANDRA-2361) * fix potential infinite loop in ByteBufferUtil.inputStream (CASSANDRA-2365) * fix encoding bugs in HintedHandoffManager, SystemTable when default charset is not UTF8 (CASSANDRA-2367) - * allow negative numbers in the cli (CASSANDRA-2358) - * fsync statistics component on write (CASSANDRA-2382) - * fix incorrect truncation of long to int when reading columns via block + * avoids having removed node reappearing in Gossip (CASSANDRA-2371) + * fix incorrect truncation of long to int when reading columns via block index (CASSANDRA-2376) - * fix race condition that could leave orphaned data files when - dropping CF or KS (CASSANDRA-2381) + * fix NPE during stream session (CASSANDRA-2377) + * fix race condition that could leave orphaned data files when dropping CF or + KS (CASSANDRA-2381) + * fsync statistics component on write (CASSANDRA-2382) + * fix duplicate results from CFS.scan (CASSANDRA-2406) * halve default memtable thresholds (CASSANDRA-2413) + * add IntegerType to CLI help (CASSANDRA-2414) + * avoid caching token-only decoratedkeys (CASSANDRA-2416) * convert mmap assertion to if/throw so scrub can catch it (CASSANDRA-2417) + * don't overwrite gc log (CASSANDR-2418) + * invalidate row cache for streamed row to avoid inconsitencies + (CASSANDRA-2420) + * avoid copies in range/index scans (CASSANDRA-2425) + * make sure we don't wipe data during cleanup if the node has not join + the ring (CASSANDRA-2428) * Try harder to close files after compaction (CASSANDRA-2431) * re-set bootstrapped flag after move finishes (CASSANDRA-2435) + * display validation_class in CLI 'describe keyspace' (CASSANDRA-2442) + * make cleanup compactions cleanup the row cache (CASSANDRA-2451) + * add column fields validation to scrub (CASSANDRA-2460) * use 64KB flush buffer instead of in_memory_compaction_limit (CASSANDRA-2463) - * fix duplicate results from CFS.scan (CASSANDRA-2406) - * avoid caching token-only decoratedkeys (CASSANDRA-2416) - * preserve version when streaming data from old sstables (CASSANDRA-2283) * fix backslash substitutions in CLI (CASSANDRA-2492) - * count a row deletion as one operation towards memtable threshold - (CASSANDRA-2519) + * dis
[jira] [Commented] (CASSANDRA-2540) Data reads by default
[
https://issues.apache.org/jira/browse/CASSANDRA-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023175#comment-13023175
]
Peter Schuller commented on CASSANDRA-2540:
---
At least to me, "significantly improved latency" refers to the expected
behavior in the event of a single node being slow or individual messages being
dropped, etc. At least to me, this isn't about avoiding another network
round-trip to improve latency by a few milliseconds (or at least that is a
small part of it), but rather about experiencing a much more consistent latency
over time by removing outliers.
Nodes doing GC, temporarily being saturated and dropping messages (e.g., just
came up with cold caches), being killed by an operator (crash-only) are
examples of events that tend to happen to individual nodes (at least not on
multiple in a co-ordinated fashion) that will cause a large amount of requests
to suddenly have extremely poor latency (causing e.g. spikes in concurrency in
the application using the cluster).
In that way, the aim isn't (to me again, maybe I'm mis-interpreting Stu) to
optimize for digest mismatches - but rather to optimize for the node that
happened to be picked for the data read being slow or down.
But I totally agree about fat columns (and of course especially in the multi-DC
case). So, there are definitely use-cases for digest reads.
> Data reads by default
> -
>
> Key: CASSANDRA-2540
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2540
> Project: Cassandra
> Issue Type: Bug
>Reporter: Stu Hood
> Fix For: 0.8.0
>
>
> The intention of digest vs data reads is to save bandwidth in the read path
> at the cost of latency, but I expect that this has been a premature
> optimization.
> * Data requested by a read will often be within an order of magnitude of the
> digest size, and a failed digest means extra roundtrips, more bandwidth
> * The [digest reads but not your data
> read|https://issues.apache.org/jira/browse/CASSANDRA-2282?focusedCommentId=13004656&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13004656]
> problem means failing QUORUM reads because a single node is unavailable, and
> would require eagerly re-requesting at some fraction of your timeout
> * Saving bandwidth in cross datacenter usecases comes at huge cost to
> latency, but since both constraints change proportionally (enough), the
> tradeoff is not clear
> Some options:
> # Add an option to use digest reads
> # Remove digest reads entirely (and/or punt and make them a runtime
> optimization based on data size in the future)
> # Continue to use digest reads, but send them to {{N - R}} nodes for
> (somewhat) more predicatable behavior with QUORUM
> \\
> The outcome of data-reads-by-default should be significantly improved
> latency, with a moderate increase in bandwidth usage for large reads.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-1941) Add distributed test doing reads during MovementTest
[ https://issues.apache.org/jira/browse/CASSANDRA-1941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023172#comment-13023172 ] Pavel Yaskevich commented on CASSANDRA-1941: Stu Hood: sure, I will take a look at CASSANDRA-2464! > Add distributed test doing reads during MovementTest > > > Key: CASSANDRA-1941 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1941 > Project: Cassandra > Issue Type: Test > Components: Core >Reporter: Jonathan Ellis >Assignee: Pavel Yaskevich >Priority: Minor > Fix For: 0.8.1 > > Attachments: CASSANDRA-1941.patch > > Original Estimate: 8h > Remaining Estimate: 8h > > Following introduction of the distributed test framework in CASSANDRA-1859, > we should extend that to test reads while bootstrap happens (this is a > scenario that has had regressions in the past). > See test/distributed/README.txt for intro. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2523) Distributed test scripts not working with Whirr 0.4.0
[ https://issues.apache.org/jira/browse/CASSANDRA-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023171#comment-13023171 ] Pavel Yaskevich commented on CASSANDRA-2523: Standard approach works for me most of the time but in like 2-3% of the cases it fails, I don't think that runurl is a good and stable solution, maybe we should hold our scripts in the test/distributed/scripts directory so we always sure that they are in place instead of using whirr's half-broken approach? > Distributed test scripts not working with Whirr 0.4.0 > - > > Key: CASSANDRA-2523 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2523 > Project: Cassandra > Issue Type: Bug >Reporter: Stu Hood > Fix For: 0.8.0 > > Attachments: > 0001-WIP-Update-to-use-jclouds-magical-functions-directory-.txt > > > I suspect that our runurl based script execution is not working with Whirr > 0.4.0, which is causing distributed tests that kill/wipe nodes to timeout. > See [this FAQ > entry|http://incubator.apache.org/whirr/faq.html#how-can-i-modify-the-instance-installation-and-configuration-scripts] > for a description of the change. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2540) Data reads by default
[
https://issues.apache.org/jira/browse/CASSANDRA-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023166#comment-13023166
]
Sylvain Lebresne commented on CASSANDRA-2540:
-
I agree that the "digest reads but not your data read" is not too nice (let's
still add for the record that you will potentially fail QUORUM reads only
during the time it takes for a node to be marked down by the failure detector).
For fixing that, I think 3) is a reasonable option.
bq. The outcome of data-reads-by-default should be significantly improved
latency
I'm not so sure of that. Digests mismatch are supposed to be the exception, not
the norm, and read with no mismatches are supposed to be at least an order of
magnitude more frequent that the ones with mismatch. Obviously the exact
details depends on the use case and it would be easy enough to start recording
such metric (to verify assumptions but perhaps also to help tweaking the ratio
between data reads and digest reads). For the use cases where we do have very
little mismatches (and those definitively exists, I would even guess this is
the majority of use cases), using data reads all over the place may actually
result in a decrease of (the average) latency (more things to transfer means
more time to do it and even though the requests are in parallel, it's still
more chances for increased latency).
And let's not forget that people having fat columns may see important drawbacks
to removing digest reads entirely.
Anyway, what I'm saying is that I'm very much opposed to removing digest reads
altogether, at least for now. I'm however in favor of making the ratio of
digest/data reads configurable (at least in the code, how we expose it to users
is another question), to add a metric to count the ratio of mismatch/reads and
to at least expose the option of 3) to the user.
> Data reads by default
> -
>
> Key: CASSANDRA-2540
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2540
> Project: Cassandra
> Issue Type: Bug
>Reporter: Stu Hood
> Fix For: 0.8.0
>
>
> The intention of digest vs data reads is to save bandwidth in the read path
> at the cost of latency, but I expect that this has been a premature
> optimization.
> * Data requested by a read will often be within an order of magnitude of the
> digest size, and a failed digest means extra roundtrips, more bandwidth
> * The [digest reads but not your data
> read|https://issues.apache.org/jira/browse/CASSANDRA-2282?focusedCommentId=13004656&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13004656]
> problem means failing QUORUM reads because a single node is unavailable, and
> would require eagerly re-requesting at some fraction of your timeout
> * Saving bandwidth in cross datacenter usecases comes at huge cost to
> latency, but since both constraints change proportionally (enough), the
> tradeoff is not clear
> Some options:
> # Add an option to use digest reads
> # Remove digest reads entirely (and/or punt and make them a runtime
> optimization based on data size in the future)
> # Continue to use digest reads, but send them to {{N - R}} nodes for
> (somewhat) more predicatable behavior with QUORUM
> \\
> The outcome of data-reads-by-default should be significantly improved
> latency, with a moderate increase in bandwidth usage for large reads.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2540) Data reads by default
[
https://issues.apache.org/jira/browse/CASSANDRA-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023155#comment-13023155
]
Peter Schuller commented on CASSANDRA-2540:
---
+1, I was discussing this just recently driven by the effects on latency.
Digest reads can definitely be useful sometimes depending on your data so I'm
not so sure about removing digest reads entirely, but certainly in many cases
it is essentially *only* detrimental (and potentially very significantly so).
This relates to the over-commit for latency purposes discussed in
CASSANDRA-2338.
> Data reads by default
> -
>
> Key: CASSANDRA-2540
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2540
> Project: Cassandra
> Issue Type: Bug
>Reporter: Stu Hood
> Fix For: 0.8.0
>
>
> The intention of digest vs data reads is to save bandwidth in the read path
> at the cost of latency, but I expect that this has been a premature
> optimization.
> * Data requested by a read will often be within an order of magnitude of the
> digest size, and a failed digest means extra roundtrips, more bandwidth
> * The [digest reads but not your data
> read|https://issues.apache.org/jira/browse/CASSANDRA-2282?focusedCommentId=13004656&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13004656]
> problem means failing QUORUM reads because a single node is unavailable, and
> would require eagerly re-requesting at some fraction of your timeout
> * Saving bandwidth in cross datacenter usecases comes at huge cost to
> latency, but since both constraints change proportionally (enough), the
> tradeoff is not clear
> Some options:
> # Add an option to use digest reads
> # Remove digest reads entirely (and/or punt and make them a runtime
> optimization based on data size in the future)
> # Continue to use digest reads, but send them to {{N - R}} nodes for
> (somewhat) more predicatable behavior with QUORUM
> \\
> The outcome of data-reads-by-default should be significantly improved
> latency, with a moderate increase in bandwidth usage for large reads.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2494) Quorum reads are not consistent
[ https://issues.apache.org/jira/browse/CASSANDRA-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023154#comment-13023154 ] Peter Schuller commented on CASSANDRA-2494: --- Ok, so my last suggestion is in fact broken. A counter example is: A: column @ t1 B: column @ t2 C: column @ t3 If A + B is participating, A's column @ t1 has timestamp quorum and would be selected. If B + C is participating, B's column is picked. Thus, a read where B + C participates will see data that will be reverted once A + B happens to be picked. Note to self: Think before posting. > Quorum reads are not consistent > --- > > Key: CASSANDRA-2494 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2494 > Project: Cassandra > Issue Type: Bug >Reporter: Sean Bridges > > As discussed in this thread, > http://www.mail-archive.com/user@cassandra.apache.org/msg12421.html > Quorum reads should be consistent. Assume we have a cluster of 3 nodes > (X,Y,Z) and a replication factor of 3. If a write of N is committed to X, but > not Y and Z, then a read from X should not return N unless the read is > committed to at least two nodes. To ensure this, a read from X should wait > for an ack of the read repair write from either Y or Z before returning. > Are there system tests for cassandra? If so, there should be a test similar > to the original post in the email thread. One thread should write 1,2,3... > at consistency level ONE. Another thread should read at consistency level > QUORUM from a random host, and verify that each read is >= the last read. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2494) Quorum reads are not consistent
[
https://issues.apache.org/jira/browse/CASSANDRA-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023151#comment-13023151
]
Peter Schuller commented on CASSANDRA-2494:
---
I don't think anyone is claiming otherwise, unless I'm misunderstanding. The
problem is that while the "if sucessfully written to quorum, subsequent quorum
reads will see it" guarantee is indeed maintained, it is possible for quorum
reads to see data go backwards (on a timeline) in the event of a *failed*
attempted quorum write. This includes the possibility of reads seeing data that
then permanently vanishes, even though you only lost say 1 node that you
designed your cluster for surviving (RF >= 3, QUORUM). ("lost 1 node" can be
substituted with "killed 1 node in periodic commit mode")
I still don't think this is a violation of what was promised, but I can see how
making the further guarantee would make for more useful consistency semantics
in some cases.
With respect to implicit write: An alternative is to adjust reconciliation
logic when applied as part of reads (as opposed to AES, hinted hand-off,
writes) to take consistency level into account and only consider columns whose
timestamp is >= the greatest timestamp that has quorum (off the top of my head
I think that should be correct in call cases, but I didn't think this through
terribly).
> Quorum reads are not consistent
> ---
>
> Key: CASSANDRA-2494
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2494
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sean Bridges
>
> As discussed in this thread,
> http://www.mail-archive.com/user@cassandra.apache.org/msg12421.html
> Quorum reads should be consistent. Assume we have a cluster of 3 nodes
> (X,Y,Z) and a replication factor of 3. If a write of N is committed to X, but
> not Y and Z, then a read from X should not return N unless the read is
> committed to at least two nodes. To ensure this, a read from X should wait
> for an ack of the read repair write from either Y or Z before returning.
> Are there system tests for cassandra? If so, there should be a test similar
> to the original post in the email thread. One thread should write 1,2,3...
> at consistency level ONE. Another thread should read at consistency level
> QUORUM from a random host, and verify that each read is >= the last read.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2539) CQL: cqlsh does shows Exception, but not error message when running truncate while a node is down.
[
https://issues.apache.org/jira/browse/CASSANDRA-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023150#comment-13023150
]
Sylvain Lebresne commented on CASSANDRA-2539:
-
UnavailableException does mean, by definition, "some hosts are down" (which
means that we don't really have anything to bubble anything, we can just have
cqlsh write it in plain english if we'd like).
But this made me think, maybe we could attach a String to the
UnavailableException saying which nodes are down. Not sure what are the
consequence in term of thrift compatibility though and if it has any, it's
probably not worth the trouble.
> CQL: cqlsh does shows Exception, but not error message when running truncate
> while a node is down.
> ---
>
> Key: CASSANDRA-2539
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2539
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 0.8.0
>Reporter: Cathy Daw
>Priority: Trivial
> Labels: cql
>
> This is really just a usability bug, but it would nice to bubble the error
> message that is printed in the log file up to the interface.
> *cqlsh output*
> {noformat}
> cqlsh> truncate users;
> Exception: UnavailableException()
> {noformat}
> *log file error*
> {noformat}
> INFO [pool-2-thread-5] 2011-04-21 23:53:30,466 StorageProxy.java (line 1021)
> Cannot perform truncate, some hosts are down
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2238) Allow nodetool to print out hostnames given an option
[ https://issues.apache.org/jira/browse/CASSANDRA-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023148#comment-13023148 ] Sylvain Lebresne commented on CASSANDRA-2238: - I would argue than calling InetAddress.getHostName() would be a really trivial to use and would in most cases 'do the right thing' (provided you have not some weird ass configuration). It will be useful in environments where a reverse DNS lookup do the right thing (imho, any non cloudy environment "should" - I know the cloud is the new cool thing around, but let's not restrict us to that arbitrarily) and the hostnames are what people are used to. I know at least one such environment where I would have been happy to have that option. Granted, this won't always be perfect, but if this is an option it's OK if it is only useful for 10% of users. And granted too, it is easy enough to write a awk or shell script but I think having the option directly will give a nicer sense of polish to nodetool (and thus Cassandra). If as an admin I had taken time and love to configure my environment correctly, I would be pissed to have to write a script because Cassandra "is too dumb to do a reverse DNS". Moreover, we trade 5 lines of changes on our side against all user that wants it writing scripts (and you know Cassandra will soon rule the world, so that will be a lot of users). Anyway, just saying. It's no big deal and I don't care so much, but I do think we should try to strive making Cassandra as easy on the user as possible, even in the details. And if I've convinced you, know that I'll be happy to write the 5 lines patch. > Allow nodetool to print out hostnames given an option > - > > Key: CASSANDRA-2238 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2238 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Joaquin Casares >Priority: Trivial > > Give nodetool the option of either displaying IPs or hostnames for the nodes > in a ring. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2540) Data reads by default
[
https://issues.apache.org/jira/browse/CASSANDRA-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023129#comment-13023129
]
Stu Hood edited comment on CASSANDRA-2540 at 4/22/11 7:46 AM:
--
Also, I targeted this at 0.8 because the "digest but not data" problem feels
far too much like a bug, and the potential latency improvement is huge.
EDIT: Also, I suspect that removing digest reads entirely would hugely simplify
the read path.
was (Author: stuhood):
Also, I targeted this at 0.8 because the "digest but not data" problem
feels far too much like a bug, and the potential latency improvement is huge.
> Data reads by default
> -
>
> Key: CASSANDRA-2540
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2540
> Project: Cassandra
> Issue Type: Bug
>Reporter: Stu Hood
> Fix For: 0.8.0
>
>
> The intention of digest vs data reads is to save bandwidth in the read path
> at the cost of latency, but I expect that this has been a premature
> optimization.
> * Data requested by a read will often be within an order of magnitude of the
> digest size, and a failed digest means extra roundtrips, more bandwidth
> * The [digest reads but not your data
> read|https://issues.apache.org/jira/browse/CASSANDRA-2282?focusedCommentId=13004656&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13004656]
> problem means failing QUORUM reads because a single node is unavailable, and
> would require eagerly re-requesting at some fraction of your timeout
> * Saving bandwidth in cross datacenter usecases comes at huge cost to
> latency, but since both constraints change proportionally (enough), the
> tradeoff is not clear
> Some options:
> # Add an option to use digest reads
> # Remove digest reads entirely (and/or punt and make them a runtime
> optimization based on data size in the future)
> # Continue to use digest reads, but send them to {{N - R}} nodes for
> (somewhat) more predicatable behavior with QUORUM
> \\
> The outcome of data-reads-by-default should be significantly improved
> latency, with a moderate increase in bandwidth usage for large reads.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2530) Additional AbstractType data type definitions to enrich CQL
[ https://issues.apache.org/jira/browse/CASSANDRA-2530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023142#comment-13023142 ] Sylvain Lebresne commented on CASSANDRA-2530: - bq. My reasoning was more about a guaranteed length that was short. We plan to put ENUMs into them in prepared statements. Again, selfishly, if we have a lot of Float usage we really have a lot of numbers between 1-10 to store! So all these volumes above are just more exaggerated in our need to store lots of short numbers in an optimal width. But I do understand the variable integer IntegerType could be used. It think what you want to use is a BytesType with only one byte each time. The only thing that you'll miss is that validate won't ensure you only have 1 byte long inputs. However, for that kind of thing, I would be in favor of using CASSANDRA-2355 and enriching BytesType so that you can write stuff like BytesType(max_length=1). That's more flexible and avoid adding tons of new classes. > Additional AbstractType data type definitions to enrich CQL > --- > > Key: CASSANDRA-2530 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2530 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 0.8.0 >Reporter: Rick Shaw >Priority: Trivial > Labels: cql > Attachments: patch-to-add -5 -new-AbstractTypes-v2.txt, patch-to-add > -5 -new-AbstractTypes-v3.txt, patch-to-add -5 -new-AbstractTypes.txt > > > Provide 5 additional Datatypes: ByteType, DateType, BooleanType, FloatType, > DoubleType. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2464) Distributed test for read repair
[ https://issues.apache.org/jira/browse/CASSANDRA-2464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023141#comment-13023141 ] Stu Hood commented on CASSANDRA-2464: - Shoot.. I just realized that "wipeHosts" will knock out the system table as well, so the downed node might try to bootstrap when it returns. Needs parameters. > Distributed test for read repair > > > Key: CASSANDRA-2464 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2464 > Project: Cassandra > Issue Type: Test >Reporter: Stu Hood >Assignee: Stu Hood > Labels: test > Fix For: 0.8.1 > > Attachments: 0001-Distributed-test-for-read-repair.txt > > > See title. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
