[jira] [Commented] (CASSANDRA-4481) Commitlog not replayed after restart - data lost
[
https://issues.apache.org/jira/browse/CASSANDRA-4481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13427889#comment-13427889
]
Ivo Meißner commented on CASSANDRA-4481:
I can reproduce the bug as follows:
1. I insert data with my client into a column family.
2. When I select the data afterwards with a cassandra client, the data is
returned.
{code}
get comment['1|3488da80-1dd5-11b2-aff8-030772c33eed'];
= (super_column=34942d20-1dd5-11b2-bfef-3f53095dd669,
(column=added, value=1343979036, timestamp=1343979036707674)
(column=id, value=34942d20-1dd5-11b2-bfef-3f53095dd669,
timestamp=1343979036707674)
(column=itemId, value=3488da801dd511b2aff8030772c33eed,
timestamp=1343979036707674)
(column=text, value=Comment, timestamp=1343979036707674)
(column=typeId, value=1, timestamp=1343979036707674)
(column=userId, value=4ab5fcb6753a8021ae02, timestamp=1343979036707674))
Returned 1 results.
Elapsed time: 6 msec(s).
{code}
3. Then I restart the machine
4. When I start cassandra again, I get the following output
{code}
INFO 09:33:56,857 Log replay complete, 0 replayed mutations
{code}
5. I select the exact same row and get no results, so the data I inserted
before is gone.
{code}
get comment['1|3488da80-1dd5-11b2-aff8-030772c33eed'];
Returned 0 results.
Elapsed time: 120 msec(s).
{code}
I tried to reproduce it with a newly created keyspace and column family and
wasn't able to reproduce it yet. In the other keyspace I can reproduce it
consistently and it happens on all column familys.
Any suggestions what I can try to narrow it down?
Commitlog not replayed after restart - data lost
Key: CASSANDRA-4481
URL: https://issues.apache.org/jira/browse/CASSANDRA-4481
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.2
Environment: Single node cluster on 64Bit CentOS
Reporter: Ivo Meißner
Priority: Critical
Fix For: 1.1.3
When data is written to the commitlog and I restart the machine, all commited
data is lost that has not been flushed to disk.
In the startup logs it says that it replays the commitlog successfully, but
the data is not available then.
When I open the commitlog file in an editor I can see the added data, but
after the restart it cannot be fetched from cassandra.
{code}
INFO 09:59:45,362 Replaying
/var/myproject/cassandra/commitlog/CommitLog-83203377067.log
INFO 09:59:45,476 Finished reading
/var/myproject/cassandra/commitlog/CommitLog-83203377067.log
INFO 09:59:45,476 Log replay complete, 0 replayed mutations
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4481) Commitlog not replayed after restart - data lost
[
https://issues.apache.org/jira/browse/CASSANDRA-4481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13427904#comment-13427904
]
sunjian commented on CASSANDRA-4481:
I need the 1.1.3 version to fix the Schema no longer modifiable bug ! when
should 1.1.3 release ?? so , please make sure does this matter is a bug or not !
Commitlog not replayed after restart - data lost
Key: CASSANDRA-4481
URL: https://issues.apache.org/jira/browse/CASSANDRA-4481
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.2
Environment: Single node cluster on 64Bit CentOS
Reporter: Ivo Meißner
Priority: Critical
Fix For: 1.1.3
When data is written to the commitlog and I restart the machine, all commited
data is lost that has not been flushed to disk.
In the startup logs it says that it replays the commitlog successfully, but
the data is not available then.
When I open the commitlog file in an editor I can see the added data, but
after the restart it cannot be fetched from cassandra.
{code}
INFO 09:59:45,362 Replaying
/var/myproject/cassandra/commitlog/CommitLog-83203377067.log
INFO 09:59:45,476 Finished reading
/var/myproject/cassandra/commitlog/CommitLog-83203377067.log
INFO 09:59:45,476 Log replay complete, 0 replayed mutations
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4486) UnavailableException when setting up a keyspace without a replication factor
Steve Arch created CASSANDRA-4486:
-
Summary: UnavailableException when setting up a keyspace without a
replication factor
Key: CASSANDRA-4486
URL: https://issues.apache.org/jira/browse/CASSANDRA-4486
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.10
Environment: ubuntu 12.04
Reporter: Steve Arch
Priority: Minor
We have a cassandra cluster of 4 nodes. When I use cassandra cli to set up a
keyspace without explicitely setting a replication factor, trying to add a CF
fails with an UnavailableException:
[default@unknown] create keyspace foo;
ae639ba0-d4b8-11e1--424d3d43a8df
Waiting for schema agreement...
schemas agree across the cluster
[default@unknown] use foo;
Authenticated to keyspace: foo
[default@foo] create column family User with comparator = UTF8Type;
b4608180-d4b8-11e1--424d3d43a8df
Waiting for schema agreement...
schemas agree across the cluster
[default@foo] update column family User with
... column_metadata =
... [
... {column_name: first, validation_class: UTF8Type},
... {column_name: last, validation_class: UTF8Type},
... {column_name: age, validation_class: UTF8Type, index_type: KEYS}
... ];
b70562c0-d4b8-11e1--424d3d43a8df
Waiting for schema agreement...
schemas agree across the cluster
[default@foo] set User['jsmith']['first'] = 'John';
null
UnavailableException()
at
org.apache.cassandra.thrift.Cassandra$insert_result.read(Cassandra.java:15206)
at
org.apache.cassandra.thrift.Cassandra$Client.recv_insert(Cassandra.java:858)
at
org.apache.cassandra.thrift.Cassandra$Client.insert(Cassandra.java:830)
at org.apache.cassandra.cli.CliClient.executeSet(CliClient.java:901)
at
org.apache.cassandra.cli.CliClient.executeCLIStatement(CliClient.java:218)
at
org.apache.cassandra.cli.CliMain.processStatementInteractive(CliMain.java:220)
at org.apache.cassandra.cli.CliMain.main(CliMain.java:348)
Either this should work fine (and no unavailableException shoud be thrown) or
an exception should be thrown when I create the keyspace because I have set it
up wrong.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4481) Commitlog not replayed after restart - data lost
[
https://issues.apache.org/jira/browse/CASSANDRA-4481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivo Meißner updated CASSANDRA-4481:
---
Fix Version/s: (was: 1.1.3)
1.1.4
Commitlog not replayed after restart - data lost
Key: CASSANDRA-4481
URL: https://issues.apache.org/jira/browse/CASSANDRA-4481
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.2
Environment: Single node cluster on 64Bit CentOS
Reporter: Ivo Meißner
Priority: Critical
Fix For: 1.1.4
When data is written to the commitlog and I restart the machine, all commited
data is lost that has not been flushed to disk.
In the startup logs it says that it replays the commitlog successfully, but
the data is not available then.
When I open the commitlog file in an editor I can see the added data, but
after the restart it cannot be fetched from cassandra.
{code}
INFO 09:59:45,362 Replaying
/var/myproject/cassandra/commitlog/CommitLog-83203377067.log
INFO 09:59:45,476 Finished reading
/var/myproject/cassandra/commitlog/CommitLog-83203377067.log
INFO 09:59:45,476 Log replay complete, 0 replayed mutations
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4481) Commitlog not replayed after restart - data lost
[
https://issues.apache.org/jira/browse/CASSANDRA-4481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13427970#comment-13427970
]
Ivo Meißner commented on CASSANDRA-4481:
I am still trying to narrow it down. I have created a new keyspace
(testkeyspace) with the same configuration and structure.
When I only use the testkeyspace, the error does not occur, everything in the
commitlog is available after reboot:
The following works as expected:
1. Insert dataA in testkeyspace
2. Reboot - 1 replayed mutations
3. Get dataA returns data as expected
The following does not work:
1. Insert dataA in testkeyspace
2. Get dataA from testkeyspace - returns data as expected
3. Insert dataB in brokenkeyspace
4. Get dataB from brokenkeypsace - returns data as expected
5. Reboot - 0 replayed mutations
6. Get dataA from testkeyspace - NO DATA
7. Get dataB from brokenkeyspace - NO DATA
So it seems to have something to do with the broken keyspace. I don't know
yet how to get the keyspace into that state. So any input of how I can figure
it out or what I could try would be appreciated.
I have changed the Fix-Version to 1.1.4.
Commitlog not replayed after restart - data lost
Key: CASSANDRA-4481
URL: https://issues.apache.org/jira/browse/CASSANDRA-4481
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.2
Environment: Single node cluster on 64Bit CentOS
Reporter: Ivo Meißner
Priority: Critical
Fix For: 1.1.4
When data is written to the commitlog and I restart the machine, all commited
data is lost that has not been flushed to disk.
In the startup logs it says that it replays the commitlog successfully, but
the data is not available then.
When I open the commitlog file in an editor I can see the added data, but
after the restart it cannot be fetched from cassandra.
{code}
INFO 09:59:45,362 Replaying
/var/myproject/cassandra/commitlog/CommitLog-83203377067.log
INFO 09:59:45,476 Finished reading
/var/myproject/cassandra/commitlog/CommitLog-83203377067.log
INFO 09:59:45,476 Log replay complete, 0 replayed mutations
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-4486) UnavailableException when setting up a keyspace without a replication factor
[
https://issues.apache.org/jira/browse/CASSANDRA-4486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-4486.
---
Resolution: Not A Problem
This is the other side of allowing creation of a KS with more replicas than you
have nodes in the cluster; see CASSANDRA-1428
UnavailableException when setting up a keyspace without a replication factor
Key: CASSANDRA-4486
URL: https://issues.apache.org/jira/browse/CASSANDRA-4486
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.10
Environment: ubuntu 12.04
Reporter: Steve Arch
Priority: Minor
We have a cassandra cluster of 4 nodes. When I use cassandra cli to set up a
keyspace without explicitely setting a replication factor, trying to add a CF
fails with an UnavailableException:
[default@unknown] create keyspace foo;
ae639ba0-d4b8-11e1--424d3d43a8df
Waiting for schema agreement...
schemas agree across the cluster
[default@unknown] use foo;
Authenticated to keyspace: foo
[default@foo] create column family User with comparator = UTF8Type;
b4608180-d4b8-11e1--424d3d43a8df
Waiting for schema agreement...
schemas agree across the cluster
[default@foo] update column family User with
... column_metadata =
... [
... {column_name: first, validation_class: UTF8Type},
... {column_name: last, validation_class: UTF8Type},
... {column_name: age, validation_class: UTF8Type, index_type:
KEYS}
... ];
b70562c0-d4b8-11e1--424d3d43a8df
Waiting for schema agreement...
schemas agree across the cluster
[default@foo] set User['jsmith']['first'] = 'John';
null
UnavailableException()
at
org.apache.cassandra.thrift.Cassandra$insert_result.read(Cassandra.java:15206)
at
org.apache.cassandra.thrift.Cassandra$Client.recv_insert(Cassandra.java:858)
at
org.apache.cassandra.thrift.Cassandra$Client.insert(Cassandra.java:830)
at org.apache.cassandra.cli.CliClient.executeSet(CliClient.java:901)
at
org.apache.cassandra.cli.CliClient.executeCLIStatement(CliClient.java:218)
at
org.apache.cassandra.cli.CliMain.processStatementInteractive(CliMain.java:220)
at org.apache.cassandra.cli.CliMain.main(CliMain.java:348)
Either this should work fine (and no unavailableException shoud be thrown) or
an exception should be thrown when I create the keyspace because I have set
it up wrong.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-4481) Commitlog not replayed after restart - data lost
[
https://issues.apache.org/jira/browse/CASSANDRA-4481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-4481.
---
Resolution: Cannot Reproduce
Fix Version/s: (was: 1.1.4)
Okay, so the real problem is you have a keyspace or CF that doesn't fully exist
but which allows you to insert data. We've fixed several schema manipulation
bugs for 1.1.3; please open a new ticket if you can reproduce there.
Commitlog not replayed after restart - data lost
Key: CASSANDRA-4481
URL: https://issues.apache.org/jira/browse/CASSANDRA-4481
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.2
Environment: Single node cluster on 64Bit CentOS
Reporter: Ivo Meißner
Priority: Critical
When data is written to the commitlog and I restart the machine, all commited
data is lost that has not been flushed to disk.
In the startup logs it says that it replays the commitlog successfully, but
the data is not available then.
When I open the commitlog file in an editor I can see the added data, but
after the restart it cannot be fetched from cassandra.
{code}
INFO 09:59:45,362 Replaying
/var/myproject/cassandra/commitlog/CommitLog-83203377067.log
INFO 09:59:45,476 Finished reading
/var/myproject/cassandra/commitlog/CommitLog-83203377067.log
INFO 09:59:45,476 Log replay complete, 0 replayed mutations
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4481) Commitlog not replayed after restart - data lost
[
https://issues.apache.org/jira/browse/CASSANDRA-4481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13428102#comment-13428102
]
Jonathan Ellis commented on CASSANDRA-4481:
---
(1.1.3 is planned for Monday release; in the meantime, artifacts are at
http://people.apache.org/~slebresne/.)
Commitlog not replayed after restart - data lost
Key: CASSANDRA-4481
URL: https://issues.apache.org/jira/browse/CASSANDRA-4481
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.2
Environment: Single node cluster on 64Bit CentOS
Reporter: Ivo Meißner
Priority: Critical
When data is written to the commitlog and I restart the machine, all commited
data is lost that has not been flushed to disk.
In the startup logs it says that it replays the commitlog successfully, but
the data is not available then.
When I open the commitlog file in an editor I can see the added data, but
after the restart it cannot be fetched from cassandra.
{code}
INFO 09:59:45,362 Replaying
/var/myproject/cassandra/commitlog/CommitLog-83203377067.log
INFO 09:59:45,476 Finished reading
/var/myproject/cassandra/commitlog/CommitLog-83203377067.log
INFO 09:59:45,476 Log replay complete, 0 replayed mutations
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3636) cassandra 1.0.x breakes APT on debian OpenVZ
[
https://issues.apache.org/jira/browse/CASSANDRA-3636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13428111#comment-13428111
]
Mohit Agarwal commented on CASSANDRA-3636:
--
I am still facing this issue with cassandra 1.1.2. I downloaded the debian file
and unpacked it to look at the postinst script. I don't see Paul's fix in there.
cassandra 1.0.x breakes APT on debian OpenVZ
Key: CASSANDRA-3636
URL: https://issues.apache.org/jira/browse/CASSANDRA-3636
Project: Cassandra
Issue Type: Bug
Components: Packaging
Affects Versions: 1.0.0
Environment: Debian Linux (stable), OpenVZ container
Reporter: Zenek Kraweznik
Assignee: paul cannon
Priority: Minor
Fix For: 1.0.11, 1.1.1
Attachments: 3636.patch.txt
During upgrade from 1.0.6
{code}Setting up cassandra (1.0.6) ...
*error: permission denied on key 'vm.max_map_count'*
dpkg: error processing cassandra (--configure):
subprocess installed post-installation script returned error exit status 255
Errors were encountered while processing:
cassandra
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4486) UnavailableException when setting up a keyspace without a replication factor
[
https://issues.apache.org/jira/browse/CASSANDRA-4486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13428175#comment-13428175
]
Dave Brosius commented on CASSANDRA-4486:
-
except this one is easy to detect, the other not so much.
UnavailableException when setting up a keyspace without a replication factor
Key: CASSANDRA-4486
URL: https://issues.apache.org/jira/browse/CASSANDRA-4486
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.10
Environment: ubuntu 12.04
Reporter: Steve Arch
Priority: Minor
We have a cassandra cluster of 4 nodes. When I use cassandra cli to set up a
keyspace without explicitely setting a replication factor, trying to add a CF
fails with an UnavailableException:
[default@unknown] create keyspace foo;
ae639ba0-d4b8-11e1--424d3d43a8df
Waiting for schema agreement...
schemas agree across the cluster
[default@unknown] use foo;
Authenticated to keyspace: foo
[default@foo] create column family User with comparator = UTF8Type;
b4608180-d4b8-11e1--424d3d43a8df
Waiting for schema agreement...
schemas agree across the cluster
[default@foo] update column family User with
... column_metadata =
... [
... {column_name: first, validation_class: UTF8Type},
... {column_name: last, validation_class: UTF8Type},
... {column_name: age, validation_class: UTF8Type, index_type:
KEYS}
... ];
b70562c0-d4b8-11e1--424d3d43a8df
Waiting for schema agreement...
schemas agree across the cluster
[default@foo] set User['jsmith']['first'] = 'John';
null
UnavailableException()
at
org.apache.cassandra.thrift.Cassandra$insert_result.read(Cassandra.java:15206)
at
org.apache.cassandra.thrift.Cassandra$Client.recv_insert(Cassandra.java:858)
at
org.apache.cassandra.thrift.Cassandra$Client.insert(Cassandra.java:830)
at org.apache.cassandra.cli.CliClient.executeSet(CliClient.java:901)
at
org.apache.cassandra.cli.CliClient.executeCLIStatement(CliClient.java:218)
at
org.apache.cassandra.cli.CliMain.processStatementInteractive(CliMain.java:220)
at org.apache.cassandra.cli.CliMain.main(CliMain.java:348)
Either this should work fine (and no unavailableException shoud be thrown) or
an exception should be thrown when I create the keyspace because I have set
it up wrong.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4486) UnavailableException when setting up a keyspace without a replication factor
[
https://issues.apache.org/jira/browse/CASSANDRA-4486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13428187#comment-13428187
]
Jonathan Ellis commented on CASSANDRA-4486:
---
That's not the point, the point is that it's legitimate to set up a
zero-replication keyspace (this is common when adding a new datacenter) and
change it later. In the meantime, it's correct to reject writes to it.
UnavailableException when setting up a keyspace without a replication factor
Key: CASSANDRA-4486
URL: https://issues.apache.org/jira/browse/CASSANDRA-4486
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.10
Environment: ubuntu 12.04
Reporter: Steve Arch
Priority: Minor
We have a cassandra cluster of 4 nodes. When I use cassandra cli to set up a
keyspace without explicitely setting a replication factor, trying to add a CF
fails with an UnavailableException:
[default@unknown] create keyspace foo;
ae639ba0-d4b8-11e1--424d3d43a8df
Waiting for schema agreement...
schemas agree across the cluster
[default@unknown] use foo;
Authenticated to keyspace: foo
[default@foo] create column family User with comparator = UTF8Type;
b4608180-d4b8-11e1--424d3d43a8df
Waiting for schema agreement...
schemas agree across the cluster
[default@foo] update column family User with
... column_metadata =
... [
... {column_name: first, validation_class: UTF8Type},
... {column_name: last, validation_class: UTF8Type},
... {column_name: age, validation_class: UTF8Type, index_type:
KEYS}
... ];
b70562c0-d4b8-11e1--424d3d43a8df
Waiting for schema agreement...
schemas agree across the cluster
[default@foo] set User['jsmith']['first'] = 'John';
null
UnavailableException()
at
org.apache.cassandra.thrift.Cassandra$insert_result.read(Cassandra.java:15206)
at
org.apache.cassandra.thrift.Cassandra$Client.recv_insert(Cassandra.java:858)
at
org.apache.cassandra.thrift.Cassandra$Client.insert(Cassandra.java:830)
at org.apache.cassandra.cli.CliClient.executeSet(CliClient.java:901)
at
org.apache.cassandra.cli.CliClient.executeCLIStatement(CliClient.java:218)
at
org.apache.cassandra.cli.CliMain.processStatementInteractive(CliMain.java:220)
at org.apache.cassandra.cli.CliMain.main(CliMain.java:348)
Either this should work fine (and no unavailableException shoud be thrown) or
an exception should be thrown when I create the keyspace because I have set
it up wrong.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3636) cassandra 1.0.x breakes APT on debian OpenVZ
[
https://issues.apache.org/jira/browse/CASSANDRA-3636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13428241#comment-13428241
]
Brandon Williams commented on CASSANDRA-3636:
-
You're looking at the wrong branch, in that case, because it's not in 1.1.2.
cassandra 1.0.x breakes APT on debian OpenVZ
Key: CASSANDRA-3636
URL: https://issues.apache.org/jira/browse/CASSANDRA-3636
Project: Cassandra
Issue Type: Bug
Components: Packaging
Affects Versions: 1.0.0
Environment: Debian Linux (stable), OpenVZ container
Reporter: Zenek Kraweznik
Assignee: paul cannon
Priority: Minor
Fix For: 1.0.11, 1.1.1
Attachments: 3636.patch.txt
During upgrade from 1.0.6
{code}Setting up cassandra (1.0.6) ...
*error: permission denied on key 'vm.max_map_count'*
dpkg: error processing cassandra (--configure):
subprocess installed post-installation script returned error exit status 255
Errors were encountered while processing:
cassandra
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3636) cassandra 1.0.x breakes APT on debian OpenVZ
[
https://issues.apache.org/jira/browse/CASSANDRA-3636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-3636:
Fix Version/s: (was: 1.1.1)
1.1.3
cassandra 1.0.x breakes APT on debian OpenVZ
Key: CASSANDRA-3636
URL: https://issues.apache.org/jira/browse/CASSANDRA-3636
Project: Cassandra
Issue Type: Bug
Components: Packaging
Affects Versions: 1.0.0
Environment: Debian Linux (stable), OpenVZ container
Reporter: Zenek Kraweznik
Assignee: paul cannon
Priority: Minor
Fix For: 1.0.11, 1.1.3
Attachments: 3636.patch.txt
During upgrade from 1.0.6
{code}Setting up cassandra (1.0.6) ...
*error: permission denied on key 'vm.max_map_count'*
dpkg: error processing cassandra (--configure):
subprocess installed post-installation script returned error exit status 255
Errors were encountered while processing:
cassandra
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Cassandra Wiki] Update of MultiTenant by JonathanEllis
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The MultiTenant page has been changed by JonathanEllis: http://wiki.apache.org/cassandra/MultiTenant?action=diffrev1=25rev2=26 * For multi-tenant order preserved partitioning, auto/online load balancing is pretty important [[https://issues.apache.org/jira/browse/CASSANDRA-1418|CASSANDRA-1418]] * Track per-user/per-keyspace statistics [[https://issues.apache.org/jira/browse/CASSANDRA-841|CASSANDRA-841]] * Improve load balancing to take into account load in terms of operations - probably add no. of operations performed on top of disk space used [[https://issues.apache.org/jira/browse/CASSANDRA-1037|CASSANDRA-1037]] - * Provide relative memory usage settings for Memtables (and eventually caches) out of configurable totals [[https://issues.apache.org/jira/browse/CASSANDRA-2006|CASSANDRA-2006]] - * Set limits per CF to help prevent OOMing nodes [[https://issues.apache.org/jira/browse/CASSANDRA-2068|CASSANDRA-2068]] + * Set query/resultset limits per CF to help prevent OOMing nodes [[https://issues.apache.org/jira/browse/CASSANDRA-2068|CASSANDRA-2068]] == Completed tickets having to do with multi-tenancy == + * Provide relative memory usage settings for Memtables (and eventually caches) out of configurable totals [[https://issues.apache.org/jira/browse/CASSANDRA-2006|CASSANDRA-2006]] * Ability to lock down schemas for Column Families - [[https://issues.apache.org/jira/browse/CASSANDRA-1554|CASSANDRA-1554]] * Better authorization system - [[https://issues.apache.org/jira/browse/CASSANDRA-1271|CASSANDRA-1271]] * Dynamic schema changes - [[https://issues.apache.org/jira/browse/CASSANDRA-44|CASSANDRA-44]]
[jira] [Commented] (CASSANDRA-3636) cassandra 1.0.x breakes APT on debian OpenVZ
[
https://issues.apache.org/jira/browse/CASSANDRA-3636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13428367#comment-13428367
]
Mohit Agarwal commented on CASSANDRA-3636:
--
The fix version here said 1.1.1 incorrectly, so i checked 1.1.2. Thanks for
correcting it.
cassandra 1.0.x breakes APT on debian OpenVZ
Key: CASSANDRA-3636
URL: https://issues.apache.org/jira/browse/CASSANDRA-3636
Project: Cassandra
Issue Type: Bug
Components: Packaging
Affects Versions: 1.0.0
Environment: Debian Linux (stable), OpenVZ container
Reporter: Zenek Kraweznik
Assignee: paul cannon
Priority: Minor
Fix For: 1.0.11, 1.1.3
Attachments: 3636.patch.txt
During upgrade from 1.0.6
{code}Setting up cassandra (1.0.6) ...
*error: permission denied on key 'vm.max_map_count'*
dpkg: error processing cassandra (--configure):
subprocess installed post-installation script returned error exit status 255
Errors were encountered while processing:
cassandra
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4486) UnavailableException when setting up a keyspace without a replication factor
[
https://issues.apache.org/jira/browse/CASSANDRA-4486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13428378#comment-13428378
]
paul cannon commented on CASSANDRA-4486:
Why would this set up a zero-replication keyspace? My reading of the code says
that the default config for a bare create keyspace foo in cassandra-cli is
NTS with {datacenter1:1}. And this cluster is supposed to have 4 nodes.
UnavailableException when setting up a keyspace without a replication factor
Key: CASSANDRA-4486
URL: https://issues.apache.org/jira/browse/CASSANDRA-4486
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.10
Environment: ubuntu 12.04
Reporter: Steve Arch
Priority: Minor
We have a cassandra cluster of 4 nodes. When I use cassandra cli to set up a
keyspace without explicitely setting a replication factor, trying to add a CF
fails with an UnavailableException:
[default@unknown] create keyspace foo;
ae639ba0-d4b8-11e1--424d3d43a8df
Waiting for schema agreement...
schemas agree across the cluster
[default@unknown] use foo;
Authenticated to keyspace: foo
[default@foo] create column family User with comparator = UTF8Type;
b4608180-d4b8-11e1--424d3d43a8df
Waiting for schema agreement...
schemas agree across the cluster
[default@foo] update column family User with
... column_metadata =
... [
... {column_name: first, validation_class: UTF8Type},
... {column_name: last, validation_class: UTF8Type},
... {column_name: age, validation_class: UTF8Type, index_type:
KEYS}
... ];
b70562c0-d4b8-11e1--424d3d43a8df
Waiting for schema agreement...
schemas agree across the cluster
[default@foo] set User['jsmith']['first'] = 'John';
null
UnavailableException()
at
org.apache.cassandra.thrift.Cassandra$insert_result.read(Cassandra.java:15206)
at
org.apache.cassandra.thrift.Cassandra$Client.recv_insert(Cassandra.java:858)
at
org.apache.cassandra.thrift.Cassandra$Client.insert(Cassandra.java:830)
at org.apache.cassandra.cli.CliClient.executeSet(CliClient.java:901)
at
org.apache.cassandra.cli.CliClient.executeCLIStatement(CliClient.java:218)
at
org.apache.cassandra.cli.CliMain.processStatementInteractive(CliMain.java:220)
at org.apache.cassandra.cli.CliMain.main(CliMain.java:348)
Either this should work fine (and no unavailableException shoud be thrown) or
an exception should be thrown when I create the keyspace because I have set
it up wrong.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4479) JMX attribute setters not consistent with cassandra.yaml
[
https://issues.apache.org/jira/browse/CASSANDRA-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13428387#comment-13428387
]
Chris Merrill commented on CASSANDRA-4479:
--
I'm looking into this and will submit a patch for consideration.
JMX attribute setters not consistent with cassandra.yaml
Key: CASSANDRA-4479
URL: https://issues.apache.org/jira/browse/CASSANDRA-4479
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.2
Reporter: Eric Dong
If a setting is configurable both via cassandra.yaml and JMX, the two should
be consistent. If that doesn't hold, then the JMX setter can't be trusted.
Here I present the example of phi_convict_threshold.
I'm trying to set phi_convict_threshold via JMX, which sets
FailureDetector.phiConvictThreshold_, but this doesn't update
Config.phi_convict_threshold, which gets its value from cassandra.yaml when
starting up.
Some places, such as FailureDetector.interpret(InetAddress), use
FailureDetector.phiConvictThreshold_; others, such as AntiEntropyService.line
813 in cassandra-1.1.2, use Config.phi_convict_threshold:
{code}
// We want a higher confidence in the failure detection than
usual because failing a repair wrongly has a high cost.
if (phi 2 * DatabaseDescriptor.getPhiConvictThreshold())
return;
{code}
where DatabaseDescriptor.getPhiConvictThreshold() returns
Conf.phi_convict_threshold.
So, it looks like there are cases where a value is stored in multiple places,
and setting the value via JMX doesn't set all of them. I'd say there should
only be a single place where a configuration parameter is stored, and that
single field:
* should read in the value from cassandra.yaml, optionally falling back to a
sane default
* should be the field that the JMX attribute reads and sets, and
* any place that needs the current global setting should get it from that
field. However, there could be cases where you read in a global value at the
start of a task and keep that value locally until the end of the task.
Also, anything settable via JMX should be volatile or set via a synchronized
setter, or else according to the Java memory model other threads may be stuck
with the old setting.
So, I'm requesting the following:
* Setting up guidelines for how to expose a configuration parameter both via
cassandra.yaml and JMX, based on what I've mentioned above
* Going through the list of configuration parameters and fixing any that
don't match those guidelines
I'd also recommend logging any changes to configuration parameters.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: Fix ScrubTest after file format change in CASSANDRA-4436
Updated Branches: refs/heads/trunk 6dfb3a855 - a075385d0 Fix ScrubTest after file format change in CASSANDRA-4436 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/a075385d Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a075385d Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a075385d Branch: refs/heads/trunk Commit: a075385d05c3e1d26475f448363958bad4645f17 Parents: 6dfb3a8 Author: Yuki Morishita yu...@apache.org Authored: Fri Aug 3 16:34:15 2012 -0500 Committer: Yuki Morishita yu...@apache.org Committed: Fri Aug 3 16:34:15 2012 -0500 -- .../Keyspace1-Standard3-ia-1-Statistics.db | Bin 4349 - 4353 bytes 1 files changed, 0 insertions(+), 0 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/a075385d/test/data/corrupt-sstables/Keyspace1-Standard3-ia-1-Statistics.db -- diff --git a/test/data/corrupt-sstables/Keyspace1-Standard3-ia-1-Statistics.db b/test/data/corrupt-sstables/Keyspace1-Standard3-ia-1-Statistics.db index ff68b08..305e010 100644 Binary files a/test/data/corrupt-sstables/Keyspace1-Standard3-ia-1-Statistics.db and b/test/data/corrupt-sstables/Keyspace1-Standard3-ia-1-Statistics.db differ
[jira] [Created] (CASSANDRA-4487) remove uses of SchemaDisagreementException
Jonathan Ellis created CASSANDRA-4487: - Summary: remove uses of SchemaDisagreementException Key: CASSANDRA-4487 URL: https://issues.apache.org/jira/browse/CASSANDRA-4487 Project: Cassandra Issue Type: Bug Components: API Affects Versions: 1.2 Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Priority: Minor Fix For: 1.2 Since we can handle concurrent schema changes now, there's no need to validateSchemaAgreement before modification now. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4488) update cqlsh recognized syntax (for tab completion, etc)
paul cannon created CASSANDRA-4488: -- Summary: update cqlsh recognized syntax (for tab completion, etc) Key: CASSANDRA-4488 URL: https://issues.apache.org/jira/browse/CASSANDRA-4488 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: paul cannon Assignee: paul cannon Priority: Minor Fix For: 1.1.4, 1.2 cqlsh syntax awareness (tab completion, etc) should be aware of several recent changes to CQL: * CASSANDRA-4179 (row key and column value composites; 1.2 only) * CASSANDRA-3647 (sets/lists/maps; 1.2 only) * CASSANDRA-4018 (inet type; 1.2 only) * CASSANDRA-4278 (hyphens in keyspace properties; 1.1 and up) * CASSANDRA-4217 (accessing ttl, timestamp; 1.1 and up) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4436) Counters in columns don't preserve correct values after cluster restart
[ https://issues.apache.org/jira/browse/CASSANDRA-4436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13428449#comment-13428449 ] Hudson commented on CASSANDRA-4436: --- Integrated in Cassandra #1861 (See [https://builds.apache.org/job/Cassandra/1861/]) Fix ScrubTest after file format change in CASSANDRA-4436 (Revision a075385d05c3e1d26475f448363958bad4645f17) Result = ABORTED yukim : Files : * test/data/corrupt-sstables/Keyspace1-Standard3-ia-1-Statistics.db Counters in columns don't preserve correct values after cluster restart --- Key: CASSANDRA-4436 URL: https://issues.apache.org/jira/browse/CASSANDRA-4436 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.10 Reporter: Peter Velas Assignee: Sylvain Lebresne Fix For: 1.1.3 Attachments: 4436-1.0-2.txt, 4436-1.0-2.txt, 4436-1.0.txt, 4436-1.1-2.txt, 4436-1.1-2.txt, 4436-1.1.txt, increments.cql.gz Similar to #3821. but affecting normal columns. Set up a 2-node cluster with rf=2. 1. Create a counter column family and increment a 100 keys in loop 5000 times. 2. Then make a rolling restart to cluster. 3. Again increment another 5000 times. 4. Make a rolling restart to cluster. 5. Again increment another 5000 times. 6. Make a rolling restart to cluster. After step 6 we were able to reproduce bug with bad counter values. Expected values were 15 000. Values returned from cluster are higher then 15000 + some random number. Rolling restarts are done with nodetool drain. Always waiting until second node discover its down then kill java process. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4489) LCS with Composite Columns NPE
Wing Lian created CASSANDRA-4489: Summary: LCS with Composite Columns NPE Key: CASSANDRA-4489 URL: https://issues.apache.org/jira/browse/CASSANDRA-4489 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.2 Environment: Mac OS X 10.8 java version 1.6.0_33 Java(TM) SE Runtime Environment (build 1.6.0_33-b03-424-11M3720) Java HotSpot(TM) 64-Bit Server VM (build 20.8-b03-424, mixed mode) Reporter: Wing Lian Creating the CF in cqlsh -3 cqlsh CREATE KEYSPACE tt WITH strategy_class=SimpleStrategy AND strategy_options:replication_factor=1; cqlsh USE tt; cqlsh:tt CREATE TABLE breakable ( ... dt timestamp, ... id timeuuid, ... metadata text, ... PRIMARY KEY (dt, id) ... ); cqlsh:tt Then changing to LCS using the CLI [default@unknown] use tt; Authenticated to keyspace: tt [default@tt] update column family breakable with compaction_strategy=LeveledCompactionStrategy; org.apache.thrift.transport.TTransportException And then trying to view the table schema cqlsh:tt describe table breakable; 'NoneType' object has no attribute 'startswith' cqlsh:tt Restarting cassandra causes an NPE ERROR 17:10:53,487 Exception encountered during startup java.lang.NullPointerException at org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167) at org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124) at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77) at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97) at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35) at org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87) at org.apache.cassandra.config.ColumnDefinition.fromSchema(ColumnDefinition.java:256) at org.apache.cassandra.config.CFMetaData.addColumnDefinitionSchema(CFMetaData.java:1293) at org.apache.cassandra.config.CFMetaData.fromSchema(CFMetaData.java:1225) at org.apache.cassandra.config.KSMetaData.deserializeColumnFamilies(KSMetaData.java:294) at org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:275) at org.apache.cassandra.db.DefsTable.loadFromTable(DefsTable.java:158) at org.apache.cassandra.config.DatabaseDescriptor.loadSchemas(DatabaseDescriptor.java:535) at org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:182) at org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:353) at org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:106) java.lang.NullPointerException at org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167) at org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124) at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77) at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97) at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35) at org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87) at org.apache.cassandra.config.ColumnDefinition.fromSchema(ColumnDefinition.java:256) at org.apache.cassandra.config.CFMetaData.addColumnDefinitionSchema(CFMetaData.java:1293) at org.apache.cassandra.config.CFMetaData.fromSchema(CFMetaData.java:1225) at org.apache.cassandra.config.KSMetaData.deserializeColumnFamilies(KSMetaData.java:294) at org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:275) at org.apache.cassandra.db.DefsTable.loadFromTable(DefsTable.java:158) at org.apache.cassandra.config.DatabaseDescriptor.loadSchemas(DatabaseDescriptor.java:535) at org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:182) at org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:353) at org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:106) Exception encountered during startup: null -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4489) LCS with Composite Columns NPE
[ https://issues.apache.org/jira/browse/CASSANDRA-4489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13428501#comment-13428501 ] Jonathan Ellis commented on CASSANDRA-4489: --- Can you reproduce with 1.1.3? http://people.apache.org/~slebresne/ LCS with Composite Columns NPE -- Key: CASSANDRA-4489 URL: https://issues.apache.org/jira/browse/CASSANDRA-4489 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.2 Environment: Mac OS X 10.8 java version 1.6.0_33 Java(TM) SE Runtime Environment (build 1.6.0_33-b03-424-11M3720) Java HotSpot(TM) 64-Bit Server VM (build 20.8-b03-424, mixed mode) Reporter: Wing Lian Creating the CF in cqlsh -3 cqlsh CREATE KEYSPACE tt WITH strategy_class=SimpleStrategy AND strategy_options:replication_factor=1; cqlsh USE tt; cqlsh:tt CREATE TABLE breakable ( ... dt timestamp, ... id timeuuid, ... metadata text, ... PRIMARY KEY (dt, id) ... ); cqlsh:tt Then changing to LCS using the CLI [default@unknown] use tt; Authenticated to keyspace: tt [default@tt] update column family breakable with compaction_strategy=LeveledCompactionStrategy; org.apache.thrift.transport.TTransportException And then trying to view the table schema cqlsh:tt describe table breakable; 'NoneType' object has no attribute 'startswith' cqlsh:tt Restarting cassandra causes an NPE ERROR 17:10:53,487 Exception encountered during startup java.lang.NullPointerException at org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167) at org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124) at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77) at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97) at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35) at org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87) at org.apache.cassandra.config.ColumnDefinition.fromSchema(ColumnDefinition.java:256) at org.apache.cassandra.config.CFMetaData.addColumnDefinitionSchema(CFMetaData.java:1293) at org.apache.cassandra.config.CFMetaData.fromSchema(CFMetaData.java:1225) at org.apache.cassandra.config.KSMetaData.deserializeColumnFamilies(KSMetaData.java:294) at org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:275) at org.apache.cassandra.db.DefsTable.loadFromTable(DefsTable.java:158) at org.apache.cassandra.config.DatabaseDescriptor.loadSchemas(DatabaseDescriptor.java:535) at org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:182) at org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:353) at org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:106) java.lang.NullPointerException at org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167) at org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124) at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77) at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97) at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35) at org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87) at org.apache.cassandra.config.ColumnDefinition.fromSchema(ColumnDefinition.java:256) at org.apache.cassandra.config.CFMetaData.addColumnDefinitionSchema(CFMetaData.java:1293) at org.apache.cassandra.config.CFMetaData.fromSchema(CFMetaData.java:1225) at org.apache.cassandra.config.KSMetaData.deserializeColumnFamilies(KSMetaData.java:294) at org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:275) at org.apache.cassandra.db.DefsTable.loadFromTable(DefsTable.java:158) at org.apache.cassandra.config.DatabaseDescriptor.loadSchemas(DatabaseDescriptor.java:535) at org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:182) at org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:353) at org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:106) Exception encountered during startup: null -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4489) LCS with Composite Columns NPE
[
https://issues.apache.org/jira/browse/CASSANDRA-4489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13428505#comment-13428505
]
Wing Lian commented on CASSANDRA-4489:
--
Updating the LCS seems to work now
[default@tt] update column family breakable with
compaction_strategy=LeveledCompactionStrategy;
735d459a-71c9-3510-9f78-0854e4c21a9d
Waiting for schema agreement...
... schemas agree across the cluster
[default@tt] describe column family breakable;
Syntax error at position 9: no viable alternative at input 'column'
[default@tt]
But seems to be missing a column and can't insert.
cqlsh:tt describe table breakable;
apache-cassandra-1.1.3-src/bin/../pylib/cqlshlib/cql3handling.py:768:
UnexpectedTableStructure: Unexpected table structure; may not translate
correctly to CQL. expected composite key CF to have column aliases, but found
none
apache-cassandra-1.1.3-src/bin/../pylib/cqlshlib/cql3handling.py:791:
UnexpectedTableStructure: Unexpected table structure; may not translate
correctly to CQL. expected [u'dt'] length to be 2, but it's 1.
comparator='org.apache.cassandra.db.marshal.CompositeType(org.apache.cassandra.db.marshal.TimeUUIDType,org.apache.cassandra.db.marshal.UTF8Type)'
CREATE TABLE breakable (
dt timestamp PRIMARY KEY
) WITH
comment='' AND
caching='KEYS_ONLY' AND
read_repair_chance=0.10 AND
gc_grace_seconds=864000 AND
replicate_on_write='true' AND
compaction_strategy_class='LeveledCompactionStrategy' AND
compression_parameters:sstable_compression='SnappyCompressor';
cqlsh:tt INSERT INTO breakable (dt, id, metadata) VALUES ('2012-08-03',
'3cea23f0-ddcc-11e1-9b23-0800200c9a66', '{result: some random data}');
Bad Request: Unknown identifier metadata
cqlsh:tt
However no NPE when restarting C*
LCS with Composite Columns NPE
--
Key: CASSANDRA-4489
URL: https://issues.apache.org/jira/browse/CASSANDRA-4489
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.2
Environment: Mac OS X 10.8
java version 1.6.0_33
Java(TM) SE Runtime Environment (build 1.6.0_33-b03-424-11M3720)
Java HotSpot(TM) 64-Bit Server VM (build 20.8-b03-424, mixed mode)
Reporter: Wing Lian
Creating the CF in cqlsh -3
cqlsh CREATE KEYSPACE tt WITH strategy_class=SimpleStrategy AND
strategy_options:replication_factor=1;
cqlsh USE tt;
cqlsh:tt CREATE TABLE breakable (
... dt timestamp,
... id timeuuid,
... metadata text,
... PRIMARY KEY (dt, id)
... );
cqlsh:tt
Then changing to LCS using the CLI
[default@unknown] use tt;
Authenticated to keyspace: tt
[default@tt] update column family breakable with
compaction_strategy=LeveledCompactionStrategy;
org.apache.thrift.transport.TTransportException
And then trying to view the table schema
cqlsh:tt describe table breakable;
'NoneType' object has no attribute 'startswith'
cqlsh:tt
Restarting cassandra causes an NPE
ERROR 17:10:53,487 Exception encountered during startup
java.lang.NullPointerException
at
org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
at
org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77)
at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97)
at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35)
at
org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87)
at
org.apache.cassandra.config.ColumnDefinition.fromSchema(ColumnDefinition.java:256)
at
org.apache.cassandra.config.CFMetaData.addColumnDefinitionSchema(CFMetaData.java:1293)
at
org.apache.cassandra.config.CFMetaData.fromSchema(CFMetaData.java:1225)
at
org.apache.cassandra.config.KSMetaData.deserializeColumnFamilies(KSMetaData.java:294)
at
org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:275)
at org.apache.cassandra.db.DefsTable.loadFromTable(DefsTable.java:158)
at
org.apache.cassandra.config.DatabaseDescriptor.loadSchemas(DatabaseDescriptor.java:535)
at
org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:182)
at
org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:353)
at
org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:106)
java.lang.NullPointerException
at
org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
at
org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77)
at
