[jira] [Updated] (CASSANDRA-4138) Add varint encoding to Serializing Cache
[ https://issues.apache.org/jira/browse/CASSANDRA-4138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-4138: --- Reviewer: jbellis > Add varint encoding to Serializing Cache > > > Key: CASSANDRA-4138 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4138 > Project: Cassandra > Issue Type: Sub-task > Components: Core >Affects Versions: 1.2 >Reporter: Vijay >Assignee: Vijay >Priority: Minor > Fix For: 1.2 > > Attachments: 0001-CASSANDRA-4138-Take1.patch, > 0001-CASSANDRA-4138-V2.patch, 0001-CASSANDRA-4138-v4.patch, > 0002-sizeof-changes-on-rest-of-the-code.patch, CASSANDRA-4138-v3.patch > > -- 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-4138) Add varint encoding to Serializing Cache
[
https://issues.apache.org/jira/browse/CASSANDRA-4138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-4138:
---
Attachment: CASSANDRA-4138-v3.patch
Made some refactoring (added license headers, renamed variables etc.)
I have removed o.a.c.util package that you created and moved Encoded* clases to
o.a.c.utils.vint, done the same for tests.
Renamed DBContants to DBTypeSizes with two statics NATIVE and VINT to be used
for sizeof(type) + all related code.
Moved class EncodedDBConstant to the DBTypeSized and renamed it to
VIntEncodedDBTypeSizes, the same done for native - it's NativeDBTypeSizes now.
Changed {encode, decode}VInt methods visibility to private and renamed to
vint{Encode, Decode} + added a comment why we use single method for all
integer types.
One problem remains - CompactionsTest fails after your modifications.
> Add varint encoding to Serializing Cache
>
>
> Key: CASSANDRA-4138
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4138
> Project: Cassandra
> Issue Type: Sub-task
> Components: Core
>Affects Versions: 1.2
>Reporter: Vijay
>Assignee: Vijay
>Priority: Minor
> Fix For: 1.2
>
> Attachments: 0001-CASSANDRA-4138-Take1.patch,
> 0001-CASSANDRA-4138-V2.patch, 0002-sizeof-changes-on-rest-of-the-code.patch,
> CASSANDRA-4138-v3.patch
>
>
--
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-4134) Do not send hints before a node is fully up
[
https://issues.apache.org/jira/browse/CASSANDRA-4134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-4134:
---
Affects Version/s: 1.0.9
> Do not send hints before a node is fully up
> ---
>
> Key: CASSANDRA-4134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4134
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 1.0.9
>Reporter: Joaquin Casares
>
> After seeing this on a cluster and working with Pavel, we have seen the
> following errors disappear after all migrations have been applied:
> {noformat}
> ERROR [MutationStage:1] 2012-04-09 18:16:00,240 RowMutationVerbHandler.java
> (line 61) Error in row mutation
> org.apache.cassandra.db.UnserializableColumnFamilyException: Couldn't find
> cfId=1028
> at
> org.apache.cassandra.db.ColumnFamilySerializer.deserialize(ColumnFamilySerializer.java:129)
> at
> org.apache.cassandra.db.RowMutation$RowMutationSerializer.deserialize(RowMutation.java:401)
> at
> org.apache.cassandra.db.RowMutation$RowMutationSerializer.deserialize(RowMutation.java:409)
> at org.apache.cassandra.db.RowMutation.fromBytes(RowMutation.java:357)
> at
> org.apache.cassandra.db.RowMutationVerbHandler.doVerb(RowMutationVerbHandler.java:42)
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59)
> 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)
> and
> ERROR [ReadStage:69] 2012-04-09 18:16:01,715 AbstractCassandraDaemon.java
> (line 139) Fatal exception in thread Thread[ReadStage:69,5,main]
> java.lang.IllegalArgumentException: Unknown ColumnFamily content_indexes in
> keyspace linkcurrent
> at org.apache.cassandra.config.Schema.getComparator(Schema.java:223)
> at
> org.apache.cassandra.db.ColumnFamily.getComparatorFor(ColumnFamily.java:300)
> at
> org.apache.cassandra.db.ReadCommand.getComparator(ReadCommand.java:92)
> at
> org.apache.cassandra.db.SliceByNamesReadCommand.(SliceByNamesReadCommand.java:44)
> at
> org.apache.cassandra.db.SliceByNamesReadCommandSerializer.deserialize(SliceByNamesReadCommand.java:106)
> at
> org.apache.cassandra.db.SliceByNamesReadCommandSerializer.deserialize(SliceByNamesReadCommand.java:74)
> at
> org.apache.cassandra.db.ReadCommandSerializer.deserialize(ReadCommand.java:132)
> at
> org.apache.cassandra.db.ReadVerbHandler.doVerb(ReadVerbHandler.java:51)
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59)
> 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)
> {noformat}
> It seems as though as soon as the correct Migration is applied, the Hints are
> accepted.
--
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-4132) [patch] fix cli delete key bug by uprading to jline 1.0
[ https://issues.apache.org/jira/browse/CASSANDRA-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-4132: --- Reviewer: xedin > [patch] fix cli delete key bug by uprading to jline 1.0 > --- > > Key: CASSANDRA-4132 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4132 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Dave Brosius >Assignee: Dave Brosius >Priority: Trivial > Attachments: fix_cli_delete_key.diff > > > the delete key currently works like the backspace key which is annoying. > upgrading to jline-1.0 fixes this. -- 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-4128) stress tool hangs forever on timeout or error
[ https://issues.apache.org/jira/browse/CASSANDRA-4128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-4128: --- Fix Version/s: (was: 1.1.1) 1.1.0 > stress tool hangs forever on timeout or error > - > > Key: CASSANDRA-4128 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4128 > Project: Cassandra > Issue Type: Bug > Components: Tools > Environment: This happens in every version of the stress tool, that I > know of, including calling it from the dtests. >Reporter: Tyler Patterson >Assignee: Pavel Yaskevich >Priority: Minor > Labels: stress > Fix For: 1.1.0 > > Attachments: CASSANDRA-4128.patch > > > The stress tool hangs forever if it encounters a timeout or exception. CTRL-C > will kill it if run from a terminal, but when running it from a script (like > a dtest) it hangs the script forever. It would be great for scripting it if a > reasonable error code was returned when things go wrong. > To duplicate, clear out /var/lib/cassandra and then run "stress > --operation=READ". -- 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-4128) stress tool hangs forever on timeout or error
[ https://issues.apache.org/jira/browse/CASSANDRA-4128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-4128: --- Attachment: CASSANDRA-4128.patch > stress tool hangs forever on timeout or error > - > > Key: CASSANDRA-4128 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4128 > Project: Cassandra > Issue Type: Bug > Components: Tools > Environment: This happens in every version of the stress tool, that I > know of, including calling it from the dtests. >Reporter: Tyler Patterson >Assignee: Pavel Yaskevich >Priority: Minor > Labels: stress > Fix For: 1.1.1 > > Attachments: CASSANDRA-4128.patch > > > The stress tool hangs forever if it encounters a timeout or exception. CTRL-C > will kill it if run from a terminal, but when running it from a script (like > a dtest) it hangs the script forever. It would be great for scripting it if a > reasonable error code was returned when things go wrong. > To duplicate, clear out /var/lib/cassandra and then run "stress > --operation=READ". -- 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-4129) Cannot create keyspace with specific keywords through cli
[ https://issues.apache.org/jira/browse/CASSANDRA-4129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-4129: --- Fix Version/s: (was: 1.0.9) 1.0.10 > Cannot create keyspace with specific keywords through cli > - > > Key: CASSANDRA-4129 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4129 > Project: Cassandra > Issue Type: Bug >Affects Versions: 1.0.8 >Reporter: Manoj Kanta Mainali >Assignee: Pavel Yaskevich >Priority: Minor > Fix For: 1.0.10 > > Attachments: CASSANDRA-4129.patch > > > Keyspaces cannot be create when the keyspace name which are used as keywords > in the cli, such as 'keyspace', 'family' etc., through CLI. Even when > surrounding the keyspace with quotation does not solve the problem. However, > such keyspaces can be created through other client such as Hector. > This is similar to the issue CASSANDRA-3195, in which the column families > could not be created. Similar to the solution of CASSANDRA-3195, using String > keyspaceName = CliUtil.unescapeSQLString(statement.getChild(0).getText()) in > executeAddKeySpace would solve the problem. -- 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-4129) Cannot create keyspace with specific keywords through cli
[ https://issues.apache.org/jira/browse/CASSANDRA-4129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-4129: --- Attachment: CASSANDRA-4129.patch patch against cassandra-1.0 > Cannot create keyspace with specific keywords through cli > - > > Key: CASSANDRA-4129 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4129 > Project: Cassandra > Issue Type: Bug >Affects Versions: 1.0.8 >Reporter: Manoj Kanta Mainali >Assignee: Pavel Yaskevich >Priority: Minor > Fix For: 1.0.9 > > Attachments: CASSANDRA-4129.patch > > > Keyspaces cannot be create when the keyspace name which are used as keywords > in the cli, such as 'keyspace', 'family' etc., through CLI. Even when > surrounding the keyspace with quotation does not solve the problem. However, > such keyspaces can be created through other client such as Hector. > This is similar to the issue CASSANDRA-3195, in which the column families > could not be created. Similar to the solution of CASSANDRA-3195, using String > keyspaceName = CliUtil.unescapeSQLString(statement.getChild(0).getText()) in > executeAddKeySpace would solve the problem. -- 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-4088) Respect 1.0 cache settings as much as possible when upgrading
[ https://issues.apache.org/jira/browse/CASSANDRA-4088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-4088: --- Attachment: CASSANDRA-4088.patch > Respect 1.0 cache settings as much as possible when upgrading > - > > Key: CASSANDRA-4088 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4088 > Project: Cassandra > Issue Type: Improvement >Affects Versions: 1.1.0 >Reporter: Jonathan Ellis >Assignee: Pavel Yaskevich > Fix For: 1.1.0 > > Attachments: CASSANDRA-4088.patch > > > When converting a 1.0 schema to 1.1, we should look at the key and row caches > (just whether they are en- or dis-abled) and set the caching setting > accordingly. I think right now upgrading means all your row caching is gone > until you update it manually. -- 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-4081) Issue with cassandra-cli "assume" command and custom types
[ https://issues.apache.org/jira/browse/CASSANDRA-4081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-4081: --- Attachment: CASSANDRA-4081.patch > Issue with cassandra-cli "assume" command and custom types > -- > > Key: CASSANDRA-4081 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4081 > Project: Cassandra > Issue Type: Bug >Affects Versions: 1.0.7 > Environment: Cassandra 1.0.7 on Mac OSX Lion >Reporter: Drew Kutcharian >Assignee: Pavel Yaskevich > Fix For: 1.0.9 > > Attachments: CASSANDRA-4081.patch > > > There seems to be an issue with cassandra-cli's assume command with a custom > type. I get "Syntax error at position 35: missing EOF at '.'" > To make sure the issue is not with my custom type, I tried it with the > built-in BytesType and got the same error: > [default@test] assume UserDetails validator as > org.apache.cassandra.db.marshal.BytesType; > Syntax error at position 35: missing EOF at '.' > I also tried it with single and double quotes with no success: > [default@test] assume UserDetails validator as > 'org.apache.cassandra.db.marshal.BytesType'; > Syntax error at position 32: mismatched input > ''org.apache.cassandra.db.marshal.BytesType'' expecting Identifier > Based on the output of "help assume" I should be able to just pass a fqn of a > class. > > It is also valid to specify the fully-qualified class name to a class that > > extends org.apache.Cassandra.db.marshal.AbstractType. -- 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-4093) schema_* CFs do not respect column comparator which leads to CLI commands failure.
[
https://issues.apache.org/jira/browse/CASSANDRA-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-4093:
---
Attachment: CASSANDRA-4093-CD-changes.patch
patch makes changes to ColumnDefinition to make it CF comparator aware, CLI
`show` and `describe` commands works just as expected but it breaks
ColumnFamily related migrations with some weird NPE exceptions.
> schema_* CFs do not respect column comparator which leads to CLI commands
> failure.
> --
>
> Key: CASSANDRA-4093
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4093
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Affects Versions: 1.1.0
>Reporter: Dave Brosius
>Assignee: Sylvain Lebresne
> Fix For: 1.1.0
>
> Attachments: CASSANDRA-4093-CD-changes.patch
>
>
> ColumnDefinition.{ascii, utf8, bool, ...} static methods used to initialize
> schema_* CFs column_metadata do not respect CF comparator and use
> ByteBufferUtil.bytes(...) for column names which creates problems in CLI and
> probably in other places.
> The CompositeType validator throws exception on first column
> String columnName = columnNameValidator.getString(columnDef.name);
> Because it appears the composite type length header is wrong (25455)
> AbstractCompositeType.getWithShortLength
> java.lang.IllegalArgumentException
> at java.nio.Buffer.limit(Buffer.java:247)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:50)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:59)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getString(AbstractCompositeType.java:139)
> at
> org.apache.cassandra.cli.CliClient.describeColumnFamily(CliClient.java:2046)
> at
> org.apache.cassandra.cli.CliClient.describeKeySpace(CliClient.java:1969)
> at
> org.apache.cassandra.cli.CliClient.executeShowKeySpaces(CliClient.java:1574)
> (seen in trunk)
--
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-4093) schema_* CFs do not respect column comparator which leads to CLI commands failure.
[
https://issues.apache.org/jira/browse/CASSANDRA-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-4093:
---
Reviewer: xedin
Description:
ColumnDefinition.{ascii, utf8, bool, ...} static methods used to initialize
schema_* CFs column_metadata do not respect CF comparator and use
ByteBufferUtil.bytes(...) for column names which creates problems in CLI and
probably in other places.
The CompositeType validator throws exception on first column
String columnName = columnNameValidator.getString(columnDef.name);
Because it appears the composite type length header is wrong (25455)
AbstractCompositeType.getWithShortLength
java.lang.IllegalArgumentException
at java.nio.Buffer.limit(Buffer.java:247)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:50)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:59)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getString(AbstractCompositeType.java:139)
at
org.apache.cassandra.cli.CliClient.describeColumnFamily(CliClient.java:2046)
at
org.apache.cassandra.cli.CliClient.describeKeySpace(CliClient.java:1969)
at
org.apache.cassandra.cli.CliClient.executeShowKeySpaces(CliClient.java:1574)
(seen in trunk)
was:
the CompositeType validator throws exception on first column
String columnName = columnNameValidator.getString(columnDef.name);
Because it appears the composite type length header is wrong (25455)
AbstractCompositeType.getWithShortLength
java.lang.IllegalArgumentException
at java.nio.Buffer.limit(Buffer.java:247)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:50)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:59)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getString(AbstractCompositeType.java:139)
at
org.apache.cassandra.cli.CliClient.describeColumnFamily(CliClient.java:2046)
at
org.apache.cassandra.cli.CliClient.describeKeySpace(CliClient.java:1969)
at
org.apache.cassandra.cli.CliClient.executeShowKeySpaces(CliClient.java:1574)
(seen in trunk)
Priority: Major (was: Trivial)
Affects Version/s: 1.1.0
Fix Version/s: 1.1.0
Assignee: Sylvain Lebresne (was: Pavel Yaskevich)
Summary: schema_* CFs do not respect column comparator which
leads to CLI commands failure. (was: cli -> show keyspaces throws exception
(and swallows) on column family schema_columnfamilies)
> schema_* CFs do not respect column comparator which leads to CLI commands
> failure.
> --
>
> Key: CASSANDRA-4093
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4093
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Affects Versions: 1.1.0
>Reporter: Dave Brosius
>Assignee: Sylvain Lebresne
> Fix For: 1.1.0
>
>
> ColumnDefinition.{ascii, utf8, bool, ...} static methods used to initialize
> schema_* CFs column_metadata do not respect CF comparator and use
> ByteBufferUtil.bytes(...) for column names which creates problems in CLI and
> probably in other places.
> The CompositeType validator throws exception on first column
> String columnName = columnNameValidator.getString(columnDef.name);
> Because it appears the composite type length header is wrong (25455)
> AbstractCompositeType.getWithShortLength
> java.lang.IllegalArgumentException
> at java.nio.Buffer.limit(Buffer.java:247)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:50)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:59)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getString(AbstractCompositeType.java:139)
> at
> org.apache.cassandra.cli.CliClient.describeColumnFamily(CliClient.java:2046)
> at
> org.apache.cassandra.cli.CliClient.describeKeySpace(CliClient.java:1969)
> at
> org.apache.cassandra.cli.CliClient.executeShowKeySpaces(CliClient.java:1574)
> (seen in trunk)
--
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-4089) Typo fix: key_valiation_class -> key_validation_class
[ https://issues.apache.org/jira/browse/CASSANDRA-4089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-4089: --- Affects Version/s: (was: 1.0.8) 0.8.10 Fix Version/s: 0.8.11 > Typo fix: key_valiation_class -> key_validation_class > - > > Key: CASSANDRA-4089 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4089 > Project: Cassandra > Issue Type: Bug > Components: Documentation & website >Affects Versions: 0.8.10 >Reporter: Andrew Ash >Priority: Minor > Fix For: 0.8.11 > > Attachments: typo-fix-01.txt > > > There is a typo in the Cli help docs for the update column family command. -- 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-3996) Keys index skips results
[ https://issues.apache.org/jira/browse/CASSANDRA-3996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3996: --- Attachment: CASSANDRA-3996-v2.patch v2 with actual change to the KeysSearcher.getIndexedIterator method (no refactoring) and test-case. > Keys index skips results > > > Key: CASSANDRA-3996 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3996 > Project: Cassandra > Issue Type: Bug >Affects Versions: 1.1.0 >Reporter: Dmitry Petrashko >Assignee: Pavel Yaskevich > Fix For: 1.1.0 > > Attachments: CASSANDRA-3996-v2.patch, CASSANDRA-3996.patch, > KeysSearcher_fix_and_refactor-v2.patch, KeysSearcher_fix_and_refactor.patch > > > While scanning results page if range index meets result already seen in > previous result set it decreases columnsRead that causes next iteration to > treat columsReadhttps://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3996) Keys index skips results
[ https://issues.apache.org/jira/browse/CASSANDRA-3996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3996: --- Attachment: CASSANDRA-3996.patch This bug was introduced by (3297a96e1849f41d9c61f024282ed52d642e0794 - Merge get_indexed_slices with get_range_slices) in 1.1.0 and does not affect 1.0.x versions, attached patch adds test along side with updated code. > Keys index skips results > > > Key: CASSANDRA-3996 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3996 > Project: Cassandra > Issue Type: Bug >Affects Versions: 1.1.0 >Reporter: Dmitry Petrashko >Assignee: Pavel Yaskevich > Fix For: 1.1.0 > > Attachments: CASSANDRA-3996.patch, > KeysSearcher_fix_and_refactor-v2.patch, KeysSearcher_fix_and_refactor.patch > > > While scanning results page if range index meets result already seen in > previous result set it decreases columnsRead that causes next iteration to > treat columsReadhttps://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3996) Keys index skips results
[ https://issues.apache.org/jira/browse/CASSANDRA-3996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3996: --- Reviewer: jbellis (was: xedin) Affects Version/s: (was: 1.0.0) 1.1.0 Fix Version/s: (was: 1.0.9) Assignee: Pavel Yaskevich (was: Dmitry Petrashko) > Keys index skips results > > > Key: CASSANDRA-3996 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3996 > Project: Cassandra > Issue Type: Bug >Affects Versions: 1.1.0 >Reporter: Dmitry Petrashko >Assignee: Pavel Yaskevich > Fix For: 1.1.0 > > Attachments: KeysSearcher_fix_and_refactor-v2.patch, > KeysSearcher_fix_and_refactor.patch > > > While scanning results page if range index meets result already seen in > previous result set it decreases columnsRead that causes next iteration to > treat columsReadhttps://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4087) Improve out-of-the-box cache settings
[ https://issues.apache.org/jira/browse/CASSANDRA-4087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-4087: --- Attachment: CASSANDRA-4087.patch > Improve out-of-the-box cache settings > - > > Key: CASSANDRA-4087 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4087 > Project: Cassandra > Issue Type: Improvement >Affects Versions: 1.1.0 >Reporter: Jonathan Ellis >Assignee: Pavel Yaskevich > Fix For: 1.1.0 > > Attachments: CASSANDRA-4087.patch > > > The default key cache of 2MB is significantly smaller than <= 1.0 (200 rows > per CF) and much smaller than most production uses. How about min(5% of the > heap, 100MB)? -- 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-2975) Upgrade MurmurHash to version 3
[ https://issues.apache.org/jira/browse/CASSANDRA-2975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-2975: --- Attachment: CASSANDRA-2975-v2-additions.patch +1 with following nit - LazilyCompactedRowTest modifications are redundant and my additions patch which adds "clear()" method to the Filter class and fixes problem in the LongBloomFilterTest. > Upgrade MurmurHash to version 3 > --- > > Key: CASSANDRA-2975 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2975 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Brian Lindauer >Assignee: Vijay >Priority: Trivial > Labels: lhf > Fix For: 1.2 > > Attachments: 0001-CASSANDRA-2975-v2.patch, 0001-CASSANDRA-2975.patch, > 0001-Convert-BloomFilter-to-use-MurmurHash-v3-instead-of-.patch, > 0002-Backwards-compatibility-with-files-using-Murmur2-blo.patch, > CASSANDRA-2975-v2-additions.patch, Murmur3Benchmark.java > > > MurmurHash version 3 was finalized on June 3. It provides an enormous speedup > and increased robustness over version 2, which is implemented in Cassandra. > Information here: > http://code.google.com/p/smhasher/ > The reference implementation is here: > http://code.google.com/p/smhasher/source/browse/trunk/MurmurHash3.cpp?spec=svn136&r=136 > I have already done the work to port the (public domain) reference > implementation to Java in the MurmurHash class and updated the BloomFilter > class to use the new implementation: > https://github.com/lindauer/cassandra/commit/cea6068a4a3e5d7d9509335394f9ef3350d37e93 > Apart from the faster hash time, the new version only requires one call to > hash() rather than 2, since it returns 128 bits of hash instead of 64. -- 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-4017) Unify migrations
[ https://issues.apache.org/jira/browse/CASSANDRA-4017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-4017: --- Reviewer: xedin > Unify migrations > > > Key: CASSANDRA-4017 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4017 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 1.1.0 >Reporter: Jonathan Ellis >Assignee: Sylvain Lebresne > Fix For: 1.1.0 > > > Now that we can send a schema as a RowMutation, there's no need to keep > separate add/drop/update migration classes around. Let's just send the > schema to our counterparts and let them figure out what changed. Currently > we have "figure out what changed" code to both generate migrations on the > sender, and for application on the target, which adds complexity. -- 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-2975) Upgrade MurmurHash to version 3
[ https://issues.apache.org/jira/browse/CASSANDRA-2975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-2975: --- Reviewer: xedin (was: stuhood) > Upgrade MurmurHash to version 3 > --- > > Key: CASSANDRA-2975 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2975 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Brian Lindauer >Assignee: Vijay >Priority: Trivial > Labels: lhf > Fix For: 1.2 > > Attachments: 0001-CASSANDRA-2975.patch, > 0001-Convert-BloomFilter-to-use-MurmurHash-v3-instead-of-.patch, > 0002-Backwards-compatibility-with-files-using-Murmur2-blo.patch, > Murmur3Benchmark.java > > > MurmurHash version 3 was finalized on June 3. It provides an enormous speedup > and increased robustness over version 2, which is implemented in Cassandra. > Information here: > http://code.google.com/p/smhasher/ > The reference implementation is here: > http://code.google.com/p/smhasher/source/browse/trunk/MurmurHash3.cpp?spec=svn136&r=136 > I have already done the work to port the (public domain) reference > implementation to Java in the MurmurHash class and updated the BloomFilter > class to use the new implementation: > https://github.com/lindauer/cassandra/commit/cea6068a4a3e5d7d9509335394f9ef3350d37e93 > Apart from the faster hash time, the new version only requires one call to > hash() rather than 2, since it returns 128 bits of hash instead of 64. -- 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-3954) Exceptions during start up after schema disagreement
[
https://issues.apache.org/jira/browse/CASSANDRA-3954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-3954:
---
Attachment: CASSANDRA-3954-v2.patch
updated v2 which skips key cache read if caching is NONE or ROWS_ONLY.
> Exceptions during start up after schema disagreement
>
>
> Key: CASSANDRA-3954
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3954
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Mariusz
>Assignee: Pavel Yaskevich
> Fix For: 1.1.0
>
> Attachments: CASSANDRA-3954-v2.patch, CASSANDRA-3954.patch
>
>
> Hi,
> i`ve got schema disaggreement after dropping down keyspace,
> i`ve switched off one nodes in cluster, after starting i`ve got bunch of
> these exceptions:
> {code}
> ERROR [SSTableBatchOpen:1] 2012-02-24 14:21:00,759
> AbstractCassandraDaemon.java (line 134) Fatal exception in thread
> Thread[SSTableBatchOpen:1,5,main]
> java.lang.ClassCastException: java.math.BigInteger cannot be cast to
> java.nio.ByteBuffer
> at org.apache.cassandra.db.marshal.UTF8Type.compare(UTF8Type.java:27)
> at org.apache.cassandra.dht.LocalToken.compareTo(LocalToken.java:45)
> at
> org.apache.cassandra.db.DecoratedKey.compareTo(DecoratedKey.java:89)
> at
> org.apache.cassandra.db.DecoratedKey.compareTo(DecoratedKey.java:38)
> at java.util.TreeMap.getEntry(TreeMap.java:328)
> at java.util.TreeMap.containsKey(TreeMap.java:209)
> at java.util.TreeSet.contains(TreeSet.java:217)
> at
> org.apache.cassandra.io.sstable.SSTableReader.load(SSTableReader.java:393)
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:189)
> at
> org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:227)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 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)
> {code}
> and this one on the end of start up:
> {code}
> ERROR [MigrationStage:1] 2012-02-24 14:37:22,750 AbstractCassandraDaemon.java
> (line 134) Fatal exception in thread Thread[MigrationStage:1,5,main]
> java.lang.NullPointerException
> at
> org.apache.cassandra.db.migration.MigrationHelper.addColumnFamily(MigrationHelper.java:282)
> at
> org.apache.cassandra.db.migration.MigrationHelper.addColumnFamily(MigrationHelper.java:216)
> at
> org.apache.cassandra.db.DefsTable.mergeColumnFamilies(DefsTable.java:330)
> at
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:240)
> at
> org.apache.cassandra.service.MigrationManager$1.runMayThrow(MigrationManager.java:124)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 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)
> {code}
> Any ideas why they`ve appeared?
--
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-3954) Exceptions during start up after schema disagreement
[
https://issues.apache.org/jira/browse/CASSANDRA-3954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-3954:
---
Attachment: (was: CASSANDRA-3954-v2.patch)
> Exceptions during start up after schema disagreement
>
>
> Key: CASSANDRA-3954
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3954
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Mariusz
>Assignee: Pavel Yaskevich
> Fix For: 1.1.0
>
> Attachments: CASSANDRA-3954.patch
>
>
> Hi,
> i`ve got schema disaggreement after dropping down keyspace,
> i`ve switched off one nodes in cluster, after starting i`ve got bunch of
> these exceptions:
> {code}
> ERROR [SSTableBatchOpen:1] 2012-02-24 14:21:00,759
> AbstractCassandraDaemon.java (line 134) Fatal exception in thread
> Thread[SSTableBatchOpen:1,5,main]
> java.lang.ClassCastException: java.math.BigInteger cannot be cast to
> java.nio.ByteBuffer
> at org.apache.cassandra.db.marshal.UTF8Type.compare(UTF8Type.java:27)
> at org.apache.cassandra.dht.LocalToken.compareTo(LocalToken.java:45)
> at
> org.apache.cassandra.db.DecoratedKey.compareTo(DecoratedKey.java:89)
> at
> org.apache.cassandra.db.DecoratedKey.compareTo(DecoratedKey.java:38)
> at java.util.TreeMap.getEntry(TreeMap.java:328)
> at java.util.TreeMap.containsKey(TreeMap.java:209)
> at java.util.TreeSet.contains(TreeSet.java:217)
> at
> org.apache.cassandra.io.sstable.SSTableReader.load(SSTableReader.java:393)
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:189)
> at
> org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:227)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 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)
> {code}
> and this one on the end of start up:
> {code}
> ERROR [MigrationStage:1] 2012-02-24 14:37:22,750 AbstractCassandraDaemon.java
> (line 134) Fatal exception in thread Thread[MigrationStage:1,5,main]
> java.lang.NullPointerException
> at
> org.apache.cassandra.db.migration.MigrationHelper.addColumnFamily(MigrationHelper.java:282)
> at
> org.apache.cassandra.db.migration.MigrationHelper.addColumnFamily(MigrationHelper.java:216)
> at
> org.apache.cassandra.db.DefsTable.mergeColumnFamilies(DefsTable.java:330)
> at
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:240)
> at
> org.apache.cassandra.service.MigrationManager$1.runMayThrow(MigrationManager.java:124)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 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)
> {code}
> Any ideas why they`ve appeared?
--
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-3954) Exceptions during start up after schema disagreement
[
https://issues.apache.org/jira/browse/CASSANDRA-3954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-3954:
---
Attachment: CASSANDRA-3954-v2.patch
That is a good idea, v2 implements that.
> Exceptions during start up after schema disagreement
>
>
> Key: CASSANDRA-3954
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3954
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Mariusz
>Assignee: Pavel Yaskevich
> Fix For: 1.1.0
>
> Attachments: CASSANDRA-3954-v2.patch, CASSANDRA-3954.patch
>
>
> Hi,
> i`ve got schema disaggreement after dropping down keyspace,
> i`ve switched off one nodes in cluster, after starting i`ve got bunch of
> these exceptions:
> {code}
> ERROR [SSTableBatchOpen:1] 2012-02-24 14:21:00,759
> AbstractCassandraDaemon.java (line 134) Fatal exception in thread
> Thread[SSTableBatchOpen:1,5,main]
> java.lang.ClassCastException: java.math.BigInteger cannot be cast to
> java.nio.ByteBuffer
> at org.apache.cassandra.db.marshal.UTF8Type.compare(UTF8Type.java:27)
> at org.apache.cassandra.dht.LocalToken.compareTo(LocalToken.java:45)
> at
> org.apache.cassandra.db.DecoratedKey.compareTo(DecoratedKey.java:89)
> at
> org.apache.cassandra.db.DecoratedKey.compareTo(DecoratedKey.java:38)
> at java.util.TreeMap.getEntry(TreeMap.java:328)
> at java.util.TreeMap.containsKey(TreeMap.java:209)
> at java.util.TreeSet.contains(TreeSet.java:217)
> at
> org.apache.cassandra.io.sstable.SSTableReader.load(SSTableReader.java:393)
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:189)
> at
> org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:227)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 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)
> {code}
> and this one on the end of start up:
> {code}
> ERROR [MigrationStage:1] 2012-02-24 14:37:22,750 AbstractCassandraDaemon.java
> (line 134) Fatal exception in thread Thread[MigrationStage:1,5,main]
> java.lang.NullPointerException
> at
> org.apache.cassandra.db.migration.MigrationHelper.addColumnFamily(MigrationHelper.java:282)
> at
> org.apache.cassandra.db.migration.MigrationHelper.addColumnFamily(MigrationHelper.java:216)
> at
> org.apache.cassandra.db.DefsTable.mergeColumnFamilies(DefsTable.java:330)
> at
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:240)
> at
> org.apache.cassandra.service.MigrationManager$1.runMayThrow(MigrationManager.java:124)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 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)
> {code}
> Any ideas why they`ve appeared?
--
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-3954) Exceptions during start up after schema disagreement
[
https://issues.apache.org/jira/browse/CASSANDRA-3954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-3954:
---
Attachment: CASSANDRA-3954.patch
We don't support secondary index caching with global caches so I have added
condition to skip reading key cache for secondary index CFs.
> Exceptions during start up after schema disagreement
>
>
> Key: CASSANDRA-3954
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3954
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Mariusz
>Assignee: Pavel Yaskevich
> Fix For: 1.1.0
>
> Attachments: CASSANDRA-3954.patch
>
>
> Hi,
> i`ve got schema disaggreement after dropping down keyspace,
> i`ve switched off one nodes in cluster, after starting i`ve got bunch of
> these exceptions:
> {code}
> ERROR [SSTableBatchOpen:1] 2012-02-24 14:21:00,759
> AbstractCassandraDaemon.java (line 134) Fatal exception in thread
> Thread[SSTableBatchOpen:1,5,main]
> java.lang.ClassCastException: java.math.BigInteger cannot be cast to
> java.nio.ByteBuffer
> at org.apache.cassandra.db.marshal.UTF8Type.compare(UTF8Type.java:27)
> at org.apache.cassandra.dht.LocalToken.compareTo(LocalToken.java:45)
> at
> org.apache.cassandra.db.DecoratedKey.compareTo(DecoratedKey.java:89)
> at
> org.apache.cassandra.db.DecoratedKey.compareTo(DecoratedKey.java:38)
> at java.util.TreeMap.getEntry(TreeMap.java:328)
> at java.util.TreeMap.containsKey(TreeMap.java:209)
> at java.util.TreeSet.contains(TreeSet.java:217)
> at
> org.apache.cassandra.io.sstable.SSTableReader.load(SSTableReader.java:393)
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:189)
> at
> org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:227)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 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)
> {code}
> and this one on the end of start up:
> {code}
> ERROR [MigrationStage:1] 2012-02-24 14:37:22,750 AbstractCassandraDaemon.java
> (line 134) Fatal exception in thread Thread[MigrationStage:1,5,main]
> java.lang.NullPointerException
> at
> org.apache.cassandra.db.migration.MigrationHelper.addColumnFamily(MigrationHelper.java:282)
> at
> org.apache.cassandra.db.migration.MigrationHelper.addColumnFamily(MigrationHelper.java:216)
> at
> org.apache.cassandra.db.DefsTable.mergeColumnFamilies(DefsTable.java:330)
> at
> org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:240)
> at
> org.apache.cassandra.service.MigrationManager$1.runMayThrow(MigrationManager.java:124)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 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)
> {code}
> Any ideas why they`ve appeared?
--
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-4042) add "caching" to CQL CF options
[ https://issues.apache.org/jira/browse/CASSANDRA-4042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-4042: --- Attachment: CASSANDRA-4042.patch > add "caching" to CQL CF options > --- > > Key: CASSANDRA-4042 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4042 > Project: Cassandra > Issue Type: Bug >Affects Versions: 1.1.0 >Reporter: Pavel Yaskevich >Assignee: Pavel Yaskevich >Priority: Minor > Fix For: 1.1.0 > > Attachments: CASSANDRA-4042.patch > > > "Caching" option is missing from CQL ColumnFamily options. -- 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-4042) add "caching" to CQL CF options
[ https://issues.apache.org/jira/browse/CASSANDRA-4042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-4042: --- Fix Version/s: 1.1.0 > add "caching" to CQL CF options > --- > > Key: CASSANDRA-4042 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4042 > Project: Cassandra > Issue Type: Bug >Affects Versions: 1.1.0 >Reporter: Pavel Yaskevich >Assignee: Pavel Yaskevich >Priority: Minor > Fix For: 1.1.0 > > Attachments: CASSANDRA-4042.patch > > > "Caching" option is missing from CQL ColumnFamily options. -- 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-3996) Keys index skips results
[ https://issues.apache.org/jira/browse/CASSANDRA-3996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3996: --- Reviewer: xedin (was: tjake) > Keys index skips results > > > Key: CASSANDRA-3996 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3996 > Project: Cassandra > Issue Type: Bug >Reporter: Dmitry Petrashko > Attachments: KeysSearcher_fix_and_refactor-v2.patch, > KeysSearcher_fix_and_refactor.patch > > > While scanning results page if range index meets result already seen in > previous result set it decreases columnsRead that causes next iteration to > treat columsReadhttps://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3980) Cli should be able to define CompositeType comparators
[ https://issues.apache.org/jira/browse/CASSANDRA-3980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3980: --- Attachment: CASSANDRA-3980.patch updated docs for create/update column family. > Cli should be able to define CompositeType comparators > -- > > Key: CASSANDRA-3980 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3980 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Brandon Williams >Assignee: Pavel Yaskevich > Fix For: 1.0.9 > > Attachments: CASSANDRA-3980.patch > > > There is currently no way to define, for instance, > CompositeType(UTF8Type,Int32Type) in a CF definition. -- 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-2261) During Compaction, Corrupt SSTables with rows that cause failures should be identified and blacklisted.
[ https://issues.apache.org/jira/browse/CASSANDRA-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-2261: --- Attachment: CASSANDRA-2261-v3.patch changes in v3: # LeveledManifest now returns list with suspected SSTables filtered out if original candidates happen to have at least one suspected SSTables (originally it was just aborting compaction by returning empty list). # Blacklisting test now supportes both SizeTiered and Leveled strategies. Also for(;;) replaced with bounded loop to avoid the situation when we can get into infinite loop if forceMajorCompaction does not fail. # Styling and nits is fixed. > During Compaction, Corrupt SSTables with rows that cause failures should be > identified and blacklisted. > --- > > Key: CASSANDRA-2261 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2261 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Benjamin Coverston >Assignee: Pavel Yaskevich >Priority: Minor > Labels: not_a_pony > Fix For: 1.1.1 > > Attachments: 2261-v2.patch, 2261.patch, CASSANDRA-2261-v3.patch > > > When a compaction of a set of SSTables fails because of corruption it will > continue to try to compact that SSTable causing pending compactions to build > up. > One way to mitigate this problem would be to log the error, then identify the > specific SSTable that caused the failure, subsequently blacklisting that > SSTable and ensuring that it is no longer included in future compactions. For > this we could simply store the problematic SSTable's name in memory. > If it's not possible to identify the SSTable that caused the issue, then > perhaps blacklisting the (ordered) permutation of SSTables to be compacted > together is something that can be done to solve this problem in a more > general case, and avoid issues where two (or more) SSTables have trouble > compacting a particular row. For this option we would probably want to store > the lists of the bad combinations in the system table somewhere s.t. these > can survive a node failure (there have been a few cases where I have seen a > compaction cause a node failure). -- 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-3963) Exception durint start up after updating cassandra
[
https://issues.apache.org/jira/browse/CASSANDRA-3963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-3963:
---
Attachment: CASSANDRA-3963.patch
patch for cassandra-1.1.0 branch (latest commit
a15c35b0942f91d6f9e45139d99491e189989bde)
> Exception durint start up after updating cassandra
> --
>
> Key: CASSANDRA-3963
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3963
> Project: Cassandra
> Issue Type: Bug
>Reporter: Mariusz
>Assignee: Pavel Yaskevich
> Fix For: 1.1.0
>
> Attachments: CASSANDRA-3963.patch
>
>
> Hi,
> i`ve updated cassandra on two-nodes cluster and i`ve got this exception
> during start up:
> {code}
> INFO 09:06:06,520 Opening
> /cassandra/system/HintsColumnFamily/system-HintsColumnFamily-hc-1 (178828054
> bytes)
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.commons.daemon.support.DaemonLoader.load(DaemonLoader.java:160)
> Caused by: java.lang.NullPointerException
> at
> org.apache.cassandra.config.KSMetaData.deserializeColumnFamilies(KSMetaData.java:384)
> at
> org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:332)
> at org.apache.cassandra.db.DefsTable.loadFromTable(DefsTable.java:156)
> at
> org.apache.cassandra.config.DatabaseDescriptor.loadSchemas(DatabaseDescriptor.java:514)
> at
> org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:182)
> at
> org.apache.cassandra.service.AbstractCassandraDaemon.init(AbstractCassandraDaemon.java:254)
> ... 5 more
> Cannot load daemon
> Service exit with a return value of 3
> {code}
> we`re running 2 node cluster on snapshots from cassandra-1.1 branch:
> * old snapshot: 5f5e00bc9a83bfd701723cbc7bf2307ea53da342 + patches from
> CASSANDRA-3740
> * new snapshot: d65590ac8a5a3cfbe1529ef77346e84d6961db7d
--
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-3963) Exception durint start up after updating cassandra
[
https://issues.apache.org/jira/browse/CASSANDRA-3963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-3963:
---
Fix Version/s: 1.1.0
> Exception durint start up after updating cassandra
> --
>
> Key: CASSANDRA-3963
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3963
> Project: Cassandra
> Issue Type: Bug
>Reporter: Mariusz
>Assignee: Pavel Yaskevich
> Fix For: 1.1.0
>
>
> Hi,
> i`ve updated cassandra on two-nodes cluster and i`ve got this exception
> during start up:
> {code}
> INFO 09:06:06,520 Opening
> /cassandra/system/HintsColumnFamily/system-HintsColumnFamily-hc-1 (178828054
> bytes)
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.commons.daemon.support.DaemonLoader.load(DaemonLoader.java:160)
> Caused by: java.lang.NullPointerException
> at
> org.apache.cassandra.config.KSMetaData.deserializeColumnFamilies(KSMetaData.java:384)
> at
> org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:332)
> at org.apache.cassandra.db.DefsTable.loadFromTable(DefsTable.java:156)
> at
> org.apache.cassandra.config.DatabaseDescriptor.loadSchemas(DatabaseDescriptor.java:514)
> at
> org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:182)
> at
> org.apache.cassandra.service.AbstractCassandraDaemon.init(AbstractCassandraDaemon.java:254)
> ... 5 more
> Cannot load daemon
> Service exit with a return value of 3
> {code}
> we`re running 2 node cluster on snapshots from cassandra-1.1 branch:
> * old snapshot: 5f5e00bc9a83bfd701723cbc7bf2307ea53da342 + patches from
> CASSANDRA-3740
> * new snapshot: d65590ac8a5a3cfbe1529ef77346e84d6961db7d
--
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-3884) Intermittent SchemaDisagreementException
[ https://issues.apache.org/jira/browse/CASSANDRA-3884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3884: --- Attachment: CASSANDRA-3884-v2.patch v2 with modifications mentioned by Sylvain. > Intermittent SchemaDisagreementException > > > Key: CASSANDRA-3884 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3884 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.1.0 > Environment: using ccm on ubuntu. >Reporter: Tyler Patterson >Assignee: Pavel Yaskevich > Fix For: 1.1.0 > > Attachments: CASSANDRA-3884-v2.patch, CASSANDRA-3884.patch > > > Set up a cluster of two nodes (on cassandra-1.1), create some keyspaces and > column families, and then make several schema changes. Everything is being > done through only one of the nodes. About once every 10 times (on my setup) > I get a SchemaDisagreementException when creating and dropping keyspaces. > There is a dtest for this: schema_changes_test.py. If your environment > behaves like mine, you might need to run it 10 times to get the error. -- 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-3804) upgrade problems from 1.0 to trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-3804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-3804:
---
Attachment: CASSANDRA-3804-1.1-v2.patch
fixed the comment about migration request.
> upgrade problems from 1.0 to trunk
> --
>
> Key: CASSANDRA-3804
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3804
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.1.0
> Environment: ubuntu, cluster set up with ccm.
>Reporter: Tyler Patterson
>Assignee: Pavel Yaskevich
> Fix For: 1.1.0
>
> Attachments: CASSANDRA-3804-1.1-v2.patch, CASSANDRA-3804-1.1.patch,
> CASSANDRA-3804.patch, node1.log, node2.log
>
>
> A 3-node cluster is on version 0.8.9, 1.0.6, or 1.0.7 and then one and only
> one node is taken down, upgraded to trunk, and started again. An rpc timeout
> exception happens if counter-add operations are done. It usually takes
> between 1 and 500 add operations before the failure occurs. The failure seems
> to happen sooner if the coordinator node is NOT the one that was upgraded.
> Here is the error:
> {code}
> ==
> ERROR: counter_upgrade_test.TestCounterUpgrade.counter_upgrade_test
> --
> Traceback (most recent call last):
> File "/usr/lib/pymodules/python2.7/nose/case.py", line 187, in runTest
> self.test(*self.arg)
> File "/home/tahooie/cassandra-dtest/counter_upgrade_test.py", line 50, in
> counter_upgrade_test
> cursor.execute("UPDATE counters SET row = row+1 where key='a'")
> File "/usr/local/lib/python2.7/dist-packages/cql/cursor.py", line 96, in
> execute
> raise cql.OperationalError("Request did not complete within rpc_timeout.")
> OperationalError: Request did not complete within rpc_timeout.
> {code}
> A script has been added to cassandra-dtest (counter_upgrade_test.py) to
> demonstrate the failure. The newest version of CCM is required to run the
> test. It is available here if it hasn't yet been pulled:
> g...@github.com:tpatterson/ccm.git
--
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-3804) upgrade problems from 1.0 to trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-3804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-3804:
---
Attachment: (was: CASSANDRA-3804-1.1-v2.patch)
> upgrade problems from 1.0 to trunk
> --
>
> Key: CASSANDRA-3804
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3804
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.1.0
> Environment: ubuntu, cluster set up with ccm.
>Reporter: Tyler Patterson
>Assignee: Pavel Yaskevich
> Fix For: 1.1.0
>
> Attachments: CASSANDRA-3804-1.1.patch, CASSANDRA-3804.patch,
> node1.log, node2.log
>
>
> A 3-node cluster is on version 0.8.9, 1.0.6, or 1.0.7 and then one and only
> one node is taken down, upgraded to trunk, and started again. An rpc timeout
> exception happens if counter-add operations are done. It usually takes
> between 1 and 500 add operations before the failure occurs. The failure seems
> to happen sooner if the coordinator node is NOT the one that was upgraded.
> Here is the error:
> {code}
> ==
> ERROR: counter_upgrade_test.TestCounterUpgrade.counter_upgrade_test
> --
> Traceback (most recent call last):
> File "/usr/lib/pymodules/python2.7/nose/case.py", line 187, in runTest
> self.test(*self.arg)
> File "/home/tahooie/cassandra-dtest/counter_upgrade_test.py", line 50, in
> counter_upgrade_test
> cursor.execute("UPDATE counters SET row = row+1 where key='a'")
> File "/usr/local/lib/python2.7/dist-packages/cql/cursor.py", line 96, in
> execute
> raise cql.OperationalError("Request did not complete within rpc_timeout.")
> OperationalError: Request did not complete within rpc_timeout.
> {code}
> A script has been added to cassandra-dtest (counter_upgrade_test.py) to
> demonstrate the failure. The newest version of CCM is required to run the
> test. It is available here if it hasn't yet been pulled:
> g...@github.com:tpatterson/ccm.git
--
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-3804) upgrade problems from 1.0 to trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-3804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-3804:
---
Attachment: CASSANDRA-3804-1.1-v2.patch
yeah, it seems like I have missed the comment about that, but fact is fact it
was misinterpreted because of that. Have placed MIGRATION_REQUEST at the end of
the Verb enum in updated v2.
> upgrade problems from 1.0 to trunk
> --
>
> Key: CASSANDRA-3804
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3804
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.1.0
> Environment: ubuntu, cluster set up with ccm.
>Reporter: Tyler Patterson
>Assignee: Pavel Yaskevich
> Fix For: 1.1.0
>
> Attachments: CASSANDRA-3804-1.1-v2.patch, CASSANDRA-3804-1.1.patch,
> CASSANDRA-3804.patch, node1.log, node2.log
>
>
> A 3-node cluster is on version 0.8.9, 1.0.6, or 1.0.7 and then one and only
> one node is taken down, upgraded to trunk, and started again. An rpc timeout
> exception happens if counter-add operations are done. It usually takes
> between 1 and 500 add operations before the failure occurs. The failure seems
> to happen sooner if the coordinator node is NOT the one that was upgraded.
> Here is the error:
> {code}
> ==
> ERROR: counter_upgrade_test.TestCounterUpgrade.counter_upgrade_test
> --
> Traceback (most recent call last):
> File "/usr/lib/pymodules/python2.7/nose/case.py", line 187, in runTest
> self.test(*self.arg)
> File "/home/tahooie/cassandra-dtest/counter_upgrade_test.py", line 50, in
> counter_upgrade_test
> cursor.execute("UPDATE counters SET row = row+1 where key='a'")
> File "/usr/local/lib/python2.7/dist-packages/cql/cursor.py", line 96, in
> execute
> raise cql.OperationalError("Request did not complete within rpc_timeout.")
> OperationalError: Request did not complete within rpc_timeout.
> {code}
> A script has been added to cassandra-dtest (counter_upgrade_test.py) to
> demonstrate the failure. The newest version of CCM is required to run the
> test. It is available here if it hasn't yet been pulled:
> g...@github.com:tpatterson/ccm.git
--
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-3804) upgrade problems from 1.0 to trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-3804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-3804:
---
Attachment: (was: CASSANDRA-3804-1.1-v2.patch)
> upgrade problems from 1.0 to trunk
> --
>
> Key: CASSANDRA-3804
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3804
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.1.0
> Environment: ubuntu, cluster set up with ccm.
>Reporter: Tyler Patterson
>Assignee: Pavel Yaskevich
> Fix For: 1.1.0
>
> Attachments: CASSANDRA-3804-1.1.patch, CASSANDRA-3804.patch,
> node1.log, node2.log
>
>
> A 3-node cluster is on version 0.8.9, 1.0.6, or 1.0.7 and then one and only
> one node is taken down, upgraded to trunk, and started again. An rpc timeout
> exception happens if counter-add operations are done. It usually takes
> between 1 and 500 add operations before the failure occurs. The failure seems
> to happen sooner if the coordinator node is NOT the one that was upgraded.
> Here is the error:
> {code}
> ==
> ERROR: counter_upgrade_test.TestCounterUpgrade.counter_upgrade_test
> --
> Traceback (most recent call last):
> File "/usr/lib/pymodules/python2.7/nose/case.py", line 187, in runTest
> self.test(*self.arg)
> File "/home/tahooie/cassandra-dtest/counter_upgrade_test.py", line 50, in
> counter_upgrade_test
> cursor.execute("UPDATE counters SET row = row+1 where key='a'")
> File "/usr/local/lib/python2.7/dist-packages/cql/cursor.py", line 96, in
> execute
> raise cql.OperationalError("Request did not complete within rpc_timeout.")
> OperationalError: Request did not complete within rpc_timeout.
> {code}
> A script has been added to cassandra-dtest (counter_upgrade_test.py) to
> demonstrate the failure. The newest version of CCM is required to run the
> test. It is available here if it hasn't yet been pulled:
> g...@github.com:tpatterson/ccm.git
--
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-2963) Add a convenient way to reset a node's schema
[ https://issues.apache.org/jira/browse/CASSANDRA-2963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-2963: --- Fix Version/s: (was: 1.1.1) 1.1.0 > Add a convenient way to reset a node's schema > - > > Key: CASSANDRA-2963 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2963 > Project: Cassandra > Issue Type: New Feature > Components: Tools >Reporter: Brandon Williams >Assignee: Yuki Morishita >Priority: Minor > Labels: lhf > Fix For: 1.1.0 > > Attachments: CASSANDRA-2963-v3.patch, cassandra-1.1-2963-v2.txt, > cassandra-1.1-2963.txt, system_reset_schema.txt > > > People often encounter a schema disagreement where just one node is out of > sync. To get it back in sync, they shutdown the node, move the Schema* and > Migration* files out of the system ks, and then start it back up. Rather > than go through this process, it would be nice if you could just tell the > node to reset its schema. -- 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-3884) Intermittent SchemaDisagreementException
[ https://issues.apache.org/jira/browse/CASSANDRA-3884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3884: --- Attachment: CASSANDRA-3884.patch I have localized and fixed the problem which was that coordinator wasn't sending the mutations used to change schema but a snapshot of the schema itself after each of the migrations. > Intermittent SchemaDisagreementException > > > Key: CASSANDRA-3884 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3884 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.1.0 > Environment: using ccm on ubuntu. >Reporter: Tyler Patterson >Assignee: Pavel Yaskevich > Fix For: 1.1.0 > > Attachments: CASSANDRA-3884.patch > > > Set up a cluster of two nodes (on cassandra-1.1), create some keyspaces and > column families, and then make several schema changes. Everything is being > done through only one of the nodes. About once every 10 times (on my setup) > I get a SchemaDisagreementException when creating and dropping keyspaces. > There is a dtest for this: schema_changes_test.py. If your environment > behaves like mine, you might need to run it 10 times to get the error. -- 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-3933) ./bin/cqlsh `describe keyspace ` command doesn't work when ColumnFamily row_cache_provider wasn't specified.
[
https://issues.apache.org/jira/browse/CASSANDRA-3933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-3933:
---
Priority: Minor (was: Major)
> ./bin/cqlsh `describe keyspace ` command doesn't work when
> ColumnFamily row_cache_provider wasn't specified.
> --
>
> Key: CASSANDRA-3933
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3933
> Project: Cassandra
> Issue Type: Bug
>Affects Versions: 1.0.7
>Reporter: Pavel Yaskevich
>Assignee: paul cannon
>Priority: Minor
> Labels: cqlsh
> Fix For: 1.0.8
>
>
> I have created Keyspace and ColumnFamily using CLI
> {noformat}
> /bin/cassandra-cli --host localhost
> Connected to: "Test Cluster" on localhost/9160
> Welcome to Cassandra CLI version 1.0.7-SNAPSHOT
> Type 'help;' or '?' for help.
> Type 'quit;' or 'exit;' to quit.
> [default@unknown] create keyspace ks;
> f89384f0-5bd3-11e1--242d50cf1fff
> Waiting for schema agreement...
> ... schemas agree across the cluster
> [default@unknown] use ks;
> Authenticated to keyspace: ks
> [default@ks] create column family cf;
> fc807690-5bd3-11e1--242d50cf1fff
> Waiting for schema agreement...
> ... schemas agree across the cluster
> [default@ks] quit;
> {noformat}
> and then I have tried to describe keyspace using CQLsh
> {noformat}
> ./bin/cqlsh
> Connected to Test Cluster at localhost:9160.
> [cqlsh 2.0.0 | Cassandra 1.0.7-SNAPSHOT | CQL spec 2.0.0 | Thrift protocol
> 19.20.0]
> Use HELP for help.
> cqlsh> describe keyspace ks;
> CREATE KEYSPACE ks WITH strategy_class = 'NetworkTopologyStrategy'
> AND strategy_options:datacenter1 = '1';
> USE ks;
> CREATE COLUMNFAMILY cf (
> CfDef instance has no attribute 'row_cache_provider'
> KEY blob PRIMARY KEYcqlsh>
> {noformat}
--
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-3804) upgrade problems from 1.0 to trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-3804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-3804:
---
Attachment: CASSANDRA-3804-1.1-v2.patch
I have found the problem with EOFException in Truncate - it was caused by
MIGRATION_REQUEST misinterpreted by 1.0 as TRUNCATE message, I have added a
check into MM.rectifySchema(UUID, InetAddress) to skip that request if node
with changed schema is older than 1.1. Two patches in combination now return no
exceptions but node 1.0 without patch would still throw
UnsupportedOperationException because Gossiper always propagates passive schema
announce.
> upgrade problems from 1.0 to trunk
> --
>
> Key: CASSANDRA-3804
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3804
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.1.0
> Environment: ubuntu, cluster set up with ccm.
>Reporter: Tyler Patterson
>Assignee: Pavel Yaskevich
> Fix For: 1.1.0
>
> Attachments: CASSANDRA-3804-1.1-v2.patch, CASSANDRA-3804-1.1.patch,
> CASSANDRA-3804.patch, node1.log, node2.log
>
>
> A 3-node cluster is on version 0.8.9, 1.0.6, or 1.0.7 and then one and only
> one node is taken down, upgraded to trunk, and started again. An rpc timeout
> exception happens if counter-add operations are done. It usually takes
> between 1 and 500 add operations before the failure occurs. The failure seems
> to happen sooner if the coordinator node is NOT the one that was upgraded.
> Here is the error:
> {code}
> ==
> ERROR: counter_upgrade_test.TestCounterUpgrade.counter_upgrade_test
> --
> Traceback (most recent call last):
> File "/usr/lib/pymodules/python2.7/nose/case.py", line 187, in runTest
> self.test(*self.arg)
> File "/home/tahooie/cassandra-dtest/counter_upgrade_test.py", line 50, in
> counter_upgrade_test
> cursor.execute("UPDATE counters SET row = row+1 where key='a'")
> File "/usr/local/lib/python2.7/dist-packages/cql/cursor.py", line 96, in
> execute
> raise cql.OperationalError("Request did not complete within rpc_timeout.")
> OperationalError: Request did not complete within rpc_timeout.
> {code}
> A script has been added to cassandra-dtest (counter_upgrade_test.py) to
> demonstrate the failure. The newest version of CCM is required to run the
> test. It is available here if it hasn't yet been pulled:
> g...@github.com:tpatterson/ccm.git
--
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-2963) Add a convenient way to reset a node's schema
[ https://issues.apache.org/jira/browse/CASSANDRA-2963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-2963: --- Attachment: CASSANDRA-2963-v3.patch I have made some styling improvements and changed MigrationManager.resetLocalSchema() to reset local schema even if there no nodes around (because when the new nodes will come up it will request schema from them anyway) + I have made sure that if there any nodes schema is requested from the first node with version >= 1.1. > Add a convenient way to reset a node's schema > - > > Key: CASSANDRA-2963 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2963 > Project: Cassandra > Issue Type: New Feature > Components: Tools >Reporter: Brandon Williams >Assignee: Yuki Morishita >Priority: Minor > Labels: lhf > Fix For: 1.1.1 > > Attachments: CASSANDRA-2963-v3.patch, cassandra-1.1-2963-v2.txt, > cassandra-1.1-2963.txt, system_reset_schema.txt > > > People often encounter a schema disagreement where just one node is out of > sync. To get it back in sync, they shutdown the node, move the Schema* and > Migration* files out of the system ks, and then start it back up. Rather > than go through this process, it would be nice if you could just tell the > node to reset its schema. -- 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-3804) upgrade problems from 1.0 to trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-3804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-3804:
---
Affects Version/s: (was: 1.0.7)
1.1.0
Fix Version/s: (was: 1.0.8)
1.1.0
> upgrade problems from 1.0 to trunk
> --
>
> Key: CASSANDRA-3804
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3804
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.1.0
> Environment: ubuntu, cluster set up with ccm.
>Reporter: Tyler Patterson
>Assignee: Pavel Yaskevich
> Fix For: 1.1.0
>
> Attachments: CASSANDRA-3804-1.1.patch, CASSANDRA-3804.patch
>
>
> A 3-node cluster is on version 0.8.9, 1.0.6, or 1.0.7 and then one and only
> one node is taken down, upgraded to trunk, and started again. An rpc timeout
> exception happens if counter-add operations are done. It usually takes
> between 1 and 500 add operations before the failure occurs. The failure seems
> to happen sooner if the coordinator node is NOT the one that was upgraded.
> Here is the error:
> {code}
> ==
> ERROR: counter_upgrade_test.TestCounterUpgrade.counter_upgrade_test
> --
> Traceback (most recent call last):
> File "/usr/lib/pymodules/python2.7/nose/case.py", line 187, in runTest
> self.test(*self.arg)
> File "/home/tahooie/cassandra-dtest/counter_upgrade_test.py", line 50, in
> counter_upgrade_test
> cursor.execute("UPDATE counters SET row = row+1 where key='a'")
> File "/usr/local/lib/python2.7/dist-packages/cql/cursor.py", line 96, in
> execute
> raise cql.OperationalError("Request did not complete within rpc_timeout.")
> OperationalError: Request did not complete within rpc_timeout.
> {code}
> A script has been added to cassandra-dtest (counter_upgrade_test.py) to
> demonstrate the failure. The newest version of CCM is required to run the
> test. It is available here if it hasn't yet been pulled:
> g...@github.com:tpatterson/ccm.git
--
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-3804) upgrade problems from 1.0 to trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-3804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-3804:
---
Attachment: CASSANDRA-3804-1.1.patch
changes the MigrationManager.announce to skip the nodes with versions older
than 1.1
> upgrade problems from 1.0 to trunk
> --
>
> Key: CASSANDRA-3804
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3804
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.0.7
> Environment: ubuntu, cluster set up with ccm.
>Reporter: Tyler Patterson
>Assignee: Pavel Yaskevich
> Fix For: 1.0.8
>
> Attachments: CASSANDRA-3804-1.1.patch, CASSANDRA-3804.patch
>
>
> A 3-node cluster is on version 0.8.9, 1.0.6, or 1.0.7 and then one and only
> one node is taken down, upgraded to trunk, and started again. An rpc timeout
> exception happens if counter-add operations are done. It usually takes
> between 1 and 500 add operations before the failure occurs. The failure seems
> to happen sooner if the coordinator node is NOT the one that was upgraded.
> Here is the error:
> {code}
> ==
> ERROR: counter_upgrade_test.TestCounterUpgrade.counter_upgrade_test
> --
> Traceback (most recent call last):
> File "/usr/lib/pymodules/python2.7/nose/case.py", line 187, in runTest
> self.test(*self.arg)
> File "/home/tahooie/cassandra-dtest/counter_upgrade_test.py", line 50, in
> counter_upgrade_test
> cursor.execute("UPDATE counters SET row = row+1 where key='a'")
> File "/usr/local/lib/python2.7/dist-packages/cql/cursor.py", line 96, in
> execute
> raise cql.OperationalError("Request did not complete within rpc_timeout.")
> OperationalError: Request did not complete within rpc_timeout.
> {code}
> A script has been added to cassandra-dtest (counter_upgrade_test.py) to
> demonstrate the failure. The newest version of CCM is required to run the
> test. It is available here if it hasn't yet been pulled:
> g...@github.com:tpatterson/ccm.git
--
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-3371) Cassandra inferred schema and actual data don't match
[
https://issues.apache.org/jira/browse/CASSANDRA-3371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-3371:
---
Attachment: 3371-v6-cleanup.patch
+1 on the v6 with cleanup patch attached - replaced ArrayList, HashMap with
interfaces, added generic description to reader/writer so no more blind casts,
changed thrift {Super}Column to user setX(...) methods and removed whitespaces.
> Cassandra inferred schema and actual data don't match
> -
>
> Key: CASSANDRA-3371
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3371
> Project: Cassandra
> Issue Type: Bug
> Components: Hadoop
>Affects Versions: 0.8.7
>Reporter: Pete Warden
>Assignee: Brandon Williams
> Attachments: 0001-Rework-pig-schema.txt,
> 0002-Output-support-to-match-input.txt, 3371-v2.txt, 3371-v3.txt,
> 3371-v4.txt, 3371-v5-rebased.txt, 3371-v5.txt, 3371-v6-cleanup.patch,
> 3371-v6.txt, pig.diff, smoke_test.txt
>
>
> It's looking like there may be a mismatch between the schema that's being
> reported by the latest CassandraStorage.java, and the data that's actually
> returned. Here's an example:
> rows = LOAD 'cassandra://Frap/PhotoVotes' USING CassandraStorage();
> DESCRIBE rows;
> rows: {key: chararray,columns: {(name: chararray,value:
> bytearray,photo_owner: chararray,value_photo_owner: bytearray,pid:
> chararray,value_pid: bytearray,matched_string:
> chararray,value_matched_string: bytearray,src_big: chararray,value_src_big:
> bytearray,time: chararray,value_time: bytearray,vote_type:
> chararray,value_vote_type: bytearray,voter: chararray,value_voter:
> bytearray)}}
> DUMP rows;
> (691831038_1317937188.48955,{(photo_owner,1596090180),(pid,6855155124568798560),(matched_string,),(src_big,),(time,Thu
> Oct 06 14:39:48 -0700 2011),(vote_type,album_dislike),(voter,691831038)})
> getSchema() is reporting the columns as an inner bag of tuples, each of which
> contains 16 values. In fact, getNext() seems to return an inner bag
> containing 7 tuples, each of which contains two values.
> It appears that things got out of sync with this change:
> http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/contrib/pig/src/java/org/apache/cassandra/hadoop/pig/CassandraStorage.java?r1=1177083&r2=1177082&pathrev=1177083
> See more discussion at:
> http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/pig-cassandra-problem-quot-Incompatible-field-schema-quot-error-tc6882703.html
--
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-3804) upgrade problems from 1.0 to trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-3804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-3804:
---
Attachment: CASSANDRA-3804.patch
patch for cassandra-1.0 branch, which does a UUID version check in
MigrationManager.rectify(UUID, InetAddress) to determine if version is
time-based UUID if not it would log an error and return.
> upgrade problems from 1.0 to trunk
> --
>
> Key: CASSANDRA-3804
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3804
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.0.7
> Environment: ubuntu, cluster set up with ccm.
>Reporter: Tyler Patterson
>Assignee: Pavel Yaskevich
> Fix For: 1.0.8
>
> Attachments: CASSANDRA-3804.patch
>
>
> A 3-node cluster is on version 0.8.9, 1.0.6, or 1.0.7 and then one and only
> one node is taken down, upgraded to trunk, and started again. An rpc timeout
> exception happens if counter-add operations are done. It usually takes
> between 1 and 500 add operations before the failure occurs. The failure seems
> to happen sooner if the coordinator node is NOT the one that was upgraded.
> Here is the error:
> {code}
> ==
> ERROR: counter_upgrade_test.TestCounterUpgrade.counter_upgrade_test
> --
> Traceback (most recent call last):
> File "/usr/lib/pymodules/python2.7/nose/case.py", line 187, in runTest
> self.test(*self.arg)
> File "/home/tahooie/cassandra-dtest/counter_upgrade_test.py", line 50, in
> counter_upgrade_test
> cursor.execute("UPDATE counters SET row = row+1 where key='a'")
> File "/usr/local/lib/python2.7/dist-packages/cql/cursor.py", line 96, in
> execute
> raise cql.OperationalError("Request did not complete within rpc_timeout.")
> OperationalError: Request did not complete within rpc_timeout.
> {code}
> A script has been added to cassandra-dtest (counter_upgrade_test.py) to
> demonstrate the failure. The newest version of CCM is required to run the
> test. It is available here if it hasn't yet been pulled:
> g...@github.com:tpatterson/ccm.git
--
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-3871) Turn compression on by default
[ https://issues.apache.org/jira/browse/CASSANDRA-3871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3871: --- Attachment: CASSANDRA-3871-v2.patch Overlooked that I can do that in CompressionParameters, fixed. Check for "null" as 'sstable_compression' is removed, users can use 'sstable_compression' set to '' to disable compression. > Turn compression on by default > -- > > Key: CASSANDRA-3871 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3871 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jonathan Ellis >Assignee: Pavel Yaskevich > Fix For: 1.1 > > Attachments: CASSANDRA-3871-v1.patch, CASSANDRA-3871-v2.patch, > CASSANDRA-3871.patch > > > Compression has been available but off by default since 1.0.0. It's enabled > in a lot of production environments now, with no major problems found. (Some > problems with customizing the block size were found and fixed in the 1.0 > releases.) -- 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-3871) Turn compression on by default
[ https://issues.apache.org/jira/browse/CASSANDRA-3871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3871: --- Attachment: CASSANDRA-3871-v1.patch I forgot about CQL, v1 turns compression on by default if CF is created using CQL (cql, cql3) and also adds a check to 'create columnfamily' and 'alter table' to disable compression if 'compression_parameters:sstable_compression' was set to 'null'. > Turn compression on by default > -- > > Key: CASSANDRA-3871 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3871 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jonathan Ellis >Assignee: Pavel Yaskevich > Fix For: 1.1 > > Attachments: CASSANDRA-3871-v1.patch, CASSANDRA-3871.patch > > > Compression has been available but off by default since 1.0.0. It's enabled > in a lot of production environments now, with no major problems found. (Some > problems with customizing the block size were found and fixed in the 1.0 > releases.) -- 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-3871) Turn compression on by default
[ https://issues.apache.org/jira/browse/CASSANDRA-3871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3871: --- Attachment: CASSANDRA-3871.patch > Turn compression on by default > -- > > Key: CASSANDRA-3871 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3871 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jonathan Ellis >Assignee: Pavel Yaskevich > Fix For: 1.1 > > Attachments: CASSANDRA-3871.patch > > > Compression has been available but off by default since 1.0.0. It's enabled > in a lot of production environments now, with no major problems found. (Some > problems with customizing the block size were found and fixed in the 1.0 > releases.) -- 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-3842) Make CLI `show schema` output data into the file as well is display it to user.
[ https://issues.apache.org/jira/browse/CASSANDRA-3842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3842: --- Attachment: CASSANDRA-3842-v1.patch original command is `show schema ' so I decided to better hook it out with sessionState.out to be able to use --file to output command to the file. > Make CLI `show schema` output data into the file as well is display it to > user. > --- > > Key: CASSANDRA-3842 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3842 > Project: Cassandra > Issue Type: Improvement >Reporter: Pavel Yaskevich >Assignee: Pavel Yaskevich >Priority: Minor > Fix For: 1.0.8 > > Attachments: CASSANDRA-3842-v1.patch, CASSANDRA-3842.patch > > > Primary use-case for `show schema` is to persist current schema to load it > later (possibly on the other machines), so if we output it into timestamped > file this would make a good bonus in usability. -- 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-3842) Make CLI `show schema` output data into the file as well is display it to user.
[ https://issues.apache.org/jira/browse/CASSANDRA-3842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3842: --- Reviewer: brandon.williams (was: tjake) > Make CLI `show schema` output data into the file as well is display it to > user. > --- > > Key: CASSANDRA-3842 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3842 > Project: Cassandra > Issue Type: Improvement >Reporter: Pavel Yaskevich >Assignee: Pavel Yaskevich >Priority: Minor > Fix For: 1.0.8 > > Attachments: CASSANDRA-3842.patch > > > Primary use-case for `show schema` is to persist current schema to load it > later (possibly on the other machines), so if we output it into timestamped > file this would make a good bonus in usability. -- 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-3827) nosetests / system tests fail
[
https://issues.apache.org/jira/browse/CASSANDRA-3827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-3827:
---
Reviewer: brandon.williams (was: jbellis)
Description:
CQL Driver version used: 1.0.8.
{code}
==
ERROR: system.test_thrift_server.TestMutations.test_bad_batch_calls
--
Traceback (most recent call last):
File "/usr/local/lib/python2.7/site-packages/nose/case.py", line 381, in setUp
try_run(self.inst, ('setup', 'setUp'))
File "/usr/local/lib/python2.7/site-packages/nose/util.py", line 478, in
try_run
return func()
File "/var/lib/jenkins/jobs/Cassandra/workspace/test/system/__init__.py",
line 113, in setUp
self.define_schema()
File "/var/lib/jenkins/jobs/Cassandra/workspace/test/system/__init__.py",
line 158, in define_schema
Cassandra.CfDef('Keyspace1', 'Super1', column_type='Super',
subcomparator_type='LongType', row_cache_size=1000, key_cache_size=0),
TypeError: __init__() got an unexpected keyword argument 'key_cache_size'
{code}
was:
CQL Driver version used: 1.0.8.
{code}
==
ERROR: system.test_thrift_server.TestMutations.test_bad_batch_calls
--
Traceback (most recent call last):
File "/usr/local/lib/python2.7/site-packages/nose/case.py", line 381, in setUp
try_run(self.inst, ('setup', 'setUp'))
File "/usr/local/lib/python2.7/site-packages/nose/util.py", line 478, in
try_run
return func()
File "/var/lib/jenkins/jobs/Cassandra/workspace/test/system/__init__.py",
line 113, in setUp
self.define_schema()
File "/var/lib/jenkins/jobs/Cassandra/workspace/test/system/__init__.py",
line 158, in define_schema
Cassandra.CfDef('Keyspace1', 'Super1', column_type='Super',
subcomparator_type='LongType', row_cache_size=1000, key_cache_size=0),
TypeError: __init__() got an unexpected keyword argument 'key_cache_size'
{code}
> nosetests / system tests fail
> -
>
> Key: CASSANDRA-3827
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3827
> Project: Cassandra
> Issue Type: Bug
> Components: Tests
>Affects Versions: 1.1
>Reporter: Michael Allen
>Assignee: Pavel Yaskevich
> Fix For: 1.1
>
> Attachments: CASSANDRA-3827.patch
>
>
> CQL Driver version used: 1.0.8.
> {code}
>
> ==
> ERROR: system.test_thrift_server.TestMutations.test_bad_batch_calls
> --
> Traceback (most recent call last):
> File "/usr/local/lib/python2.7/site-packages/nose/case.py", line 381, in
> setUp
> try_run(self.inst, ('setup', 'setUp'))
> File "/usr/local/lib/python2.7/site-packages/nose/util.py", line 478, in
> try_run
> return func()
> File "/var/lib/jenkins/jobs/Cassandra/workspace/test/system/__init__.py",
> line 113, in setUp
> self.define_schema()
> File "/var/lib/jenkins/jobs/Cassandra/workspace/test/system/__init__.py",
> line 158, in define_schema
> Cassandra.CfDef('Keyspace1', 'Super1', column_type='Super',
> subcomparator_type='LongType', row_cache_size=1000, key_cache_size=0),
> TypeError: __init__() got an unexpected keyword argument 'key_cache_size'
> {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-3844) Truncate leaves behind non-CFS backed secondary indexes
[ https://issues.apache.org/jira/browse/CASSANDRA-3844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3844: --- Attachment: (was: CASSANDRA-3844.patch) > Truncate leaves behind non-CFS backed secondary indexes > --- > > Key: CASSANDRA-3844 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3844 > Project: Cassandra > Issue Type: Bug >Affects Versions: 1.0.7 >Reporter: T Jake Luciani >Assignee: Pavel Yaskevich >Priority: Minor > Fix For: 1.0.8 > > Attachments: CASSANDRA-3844.patch > > > If you setup a CF with a non-cfs backed secondary index then trucate it, > nothing happens to the secondary index. we need a hook for CFStore to clean > these 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] [Updated] (CASSANDRA-3844) Truncate leaves behind non-CFS backed secondary indexes
[ https://issues.apache.org/jira/browse/CASSANDRA-3844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3844: --- Attachment: CASSANDRA-3844.patch uses IdentityHashMap in SecondaryIndexManager.getIndexes() > Truncate leaves behind non-CFS backed secondary indexes > --- > > Key: CASSANDRA-3844 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3844 > Project: Cassandra > Issue Type: Bug >Affects Versions: 1.0.7 >Reporter: T Jake Luciani >Assignee: Pavel Yaskevich >Priority: Minor > Fix For: 1.0.8 > > Attachments: CASSANDRA-3844.patch > > > If you setup a CF with a non-cfs backed secondary index then trucate it, > nothing happens to the secondary index. we need a hook for CFStore to clean > these 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] [Updated] (CASSANDRA-3844) Truncate leaves behind non-CFS backed secondary indexes
[ https://issues.apache.org/jira/browse/CASSANDRA-3844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3844: --- Attachment: CASSANDRA-3844.patch renamed CFS.truncateSSTables(long) to CFS.discardSSTables(long). > Truncate leaves behind non-CFS backed secondary indexes > --- > > Key: CASSANDRA-3844 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3844 > Project: Cassandra > Issue Type: Bug >Affects Versions: 1.0.7 >Reporter: T Jake Luciani >Assignee: Pavel Yaskevich >Priority: Minor > Fix For: 1.0.8 > > Attachments: CASSANDRA-3844.patch > > > If you setup a CF with a non-cfs backed secondary index then trucate it, > nothing happens to the secondary index. we need a hook for CFStore to clean > these 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] [Updated] (CASSANDRA-3844) Truncate leaves behind non-CFS backed secondary indexes
[ https://issues.apache.org/jira/browse/CASSANDRA-3844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3844: --- Attachment: (was: CASSANDRA-3844.patch) > Truncate leaves behind non-CFS backed secondary indexes > --- > > Key: CASSANDRA-3844 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3844 > Project: Cassandra > Issue Type: Bug >Affects Versions: 1.0.7 >Reporter: T Jake Luciani >Assignee: Pavel Yaskevich >Priority: Minor > Fix For: 1.0.8 > > > If you setup a CF with a non-cfs backed secondary index then trucate it, > nothing happens to the secondary index. we need a hook for CFStore to clean > these 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] [Updated] (CASSANDRA-3844) Truncate leaves behind non-CFS backed secondary indexes
[ https://issues.apache.org/jira/browse/CASSANDRA-3844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3844: --- Attachment: CASSANDRA-3844.patch This patch encapsulates truncate logic into SecondaryIndex.truncate(long) abstract method so every type of indices would be able to implement desired logic (currently implemented for KeysIndex), which also removes a good bit of code from CompactionManager.submitTruncate(...). > Truncate leaves behind non-CFS backed secondary indexes > --- > > Key: CASSANDRA-3844 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3844 > Project: Cassandra > Issue Type: Bug >Affects Versions: 1.0.7 >Reporter: T Jake Luciani >Assignee: Pavel Yaskevich >Priority: Minor > Fix For: 1.0.8 > > Attachments: CASSANDRA-3844.patch > > > If you setup a CF with a non-cfs backed secondary index then trucate it, > nothing happens to the secondary index. we need a hook for CFStore to clean > these 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] [Updated] (CASSANDRA-3849) Saved CF row cache breaks when upgrading to 1.1
[
https://issues.apache.org/jira/browse/CASSANDRA-3849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-3849:
---
Attachment: CASSANDRA-3849.patch
> Saved CF row cache breaks when upgrading to 1.1
> ---
>
> Key: CASSANDRA-3849
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3849
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.1
> Environment: 1 node cluster running on branch cassandra-1.0. Ubuntu.
> both key and row caching were enabled.
>Reporter: Tyler Patterson
>Assignee: Pavel Yaskevich
> Attachments: CASSANDRA-3849.patch
>
>
> Enabled row and key caching. Used stress to insert some data. ran nodetool
> flush, then nodetool compact. Then read the data back to populate the cache.
> Turned row_cache_save_period and key_cache_save_period really low to force
> saving the cache data. I verified that the row and key cache files existed in
> /var/lib/cassandra/saved_caches/.
> I then killed cassandra, checked out branch cassandra-1.1, compiled and tried
> to start the node. The node failed to start, and I got this error:
> {code}
> INFO 01:33:30,893 reading saved cache
> /var/lib/cassandra/saved_caches/Keyspace1-Standard1-RowCache
> ERROR 01:33:31,009 Exception encountered during startup
> java.lang.AssertionError: Row cache is not enabled on column family
> [Standard1]
> at
> org.apache.cassandra.db.ColumnFamilyStore.cacheRow(ColumnFamilyStore.java:1050)
> at
> org.apache.cassandra.db.ColumnFamilyStore.initRowCache(ColumnFamilyStore.java:383)
> at org.apache.cassandra.db.Table.open(Table.java:122)
> at org.apache.cassandra.db.Table.open(Table.java:100)
> at
> org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:204)
> at
> org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:353)
> at
> org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:107)
> java.lang.AssertionError: Row cache is not enabled on column family
> [Standard1]
> at
> org.apache.cassandra.db.ColumnFamilyStore.cacheRow(ColumnFamilyStore.java:1050)
> at
> org.apache.cassandra.db.ColumnFamilyStore.initRowCache(ColumnFamilyStore.java:383)
> at org.apache.cassandra.db.Table.open(Table.java:122)
> at org.apache.cassandra.db.Table.open(Table.java:100)
> at
> org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:204)
> at
> org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:353)
> at
> org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:107)
> Exception encountered during startup: Row cache is not enabled on column
> family [Standard1]
> {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-3849) Saved CF row cache breaks when upgrading to 1.1
[
https://issues.apache.org/jira/browse/CASSANDRA-3849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-3849:
---
Reviewer: slebresne
Assignee: Pavel Yaskevich (was: Sylvain Lebresne)
> Saved CF row cache breaks when upgrading to 1.1
> ---
>
> Key: CASSANDRA-3849
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3849
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.1
> Environment: 1 node cluster running on branch cassandra-1.0. Ubuntu.
> both key and row caching were enabled.
>Reporter: Tyler Patterson
>Assignee: Pavel Yaskevich
>
> Enabled row and key caching. Used stress to insert some data. ran nodetool
> flush, then nodetool compact. Then read the data back to populate the cache.
> Turned row_cache_save_period and key_cache_save_period really low to force
> saving the cache data. I verified that the row and key cache files existed in
> /var/lib/cassandra/saved_caches/.
> I then killed cassandra, checked out branch cassandra-1.1, compiled and tried
> to start the node. The node failed to start, and I got this error:
> {code}
> INFO 01:33:30,893 reading saved cache
> /var/lib/cassandra/saved_caches/Keyspace1-Standard1-RowCache
> ERROR 01:33:31,009 Exception encountered during startup
> java.lang.AssertionError: Row cache is not enabled on column family
> [Standard1]
> at
> org.apache.cassandra.db.ColumnFamilyStore.cacheRow(ColumnFamilyStore.java:1050)
> at
> org.apache.cassandra.db.ColumnFamilyStore.initRowCache(ColumnFamilyStore.java:383)
> at org.apache.cassandra.db.Table.open(Table.java:122)
> at org.apache.cassandra.db.Table.open(Table.java:100)
> at
> org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:204)
> at
> org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:353)
> at
> org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:107)
> java.lang.AssertionError: Row cache is not enabled on column family
> [Standard1]
> at
> org.apache.cassandra.db.ColumnFamilyStore.cacheRow(ColumnFamilyStore.java:1050)
> at
> org.apache.cassandra.db.ColumnFamilyStore.initRowCache(ColumnFamilyStore.java:383)
> at org.apache.cassandra.db.Table.open(Table.java:122)
> at org.apache.cassandra.db.Table.open(Table.java:100)
> at
> org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:204)
> at
> org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:353)
> at
> org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:107)
> Exception encountered during startup: Row cache is not enabled on column
> family [Standard1]
> {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-3842) Make CLI `show schema` output data into the file as well is display it to user.
[ https://issues.apache.org/jira/browse/CASSANDRA-3842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3842: --- Attachment: CASSANDRA-3842.patch saves the file with CLI schema definitions and then just displays it's contents to the user + prints the name of the file for later use. Format of the file name "schema[-]-.cli" [-keyspace] part is only added when `show schema` was executed while one of the keyspaces was selected using `use ` command. > Make CLI `show schema` output data into the file as well is display it to > user. > --- > > Key: CASSANDRA-3842 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3842 > Project: Cassandra > Issue Type: Improvement >Reporter: Pavel Yaskevich >Assignee: Pavel Yaskevich >Priority: Minor > Fix For: 1.0.8 > > Attachments: CASSANDRA-3842.patch > > > Primary use-case for `show schema` is to persist current schema to load it > later (possibly on the other machines), so if we output it into timestamped > file this would make a good bonus in usability. -- 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-3827) nosetests / system tests fail
[
https://issues.apache.org/jira/browse/CASSANDRA-3827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-3827:
---
Attachment: CASSANDRA-3827.patch
removed {row,key}_cache_size as deprecated from
ThriftTester.define_schema(self) and fixed removed FilterClause to KeyRange for
index tests. Now all tests pass for me:
{noformat}
PYTHONPATH=test nosetests --tests=system.test_thrift_server
--
Ran 92 tests in 626.972s
OK
{noformat}
> nosetests / system tests fail
> -
>
> Key: CASSANDRA-3827
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3827
> Project: Cassandra
> Issue Type: Bug
> Components: Tests
>Affects Versions: 1.1
>Reporter: Michael Allen
>Assignee: Pavel Yaskevich
> Fix For: 1.1
>
> Attachments: CASSANDRA-3827.patch
>
>
> CQL Driver version used: 1.0.8.
> {code}
>
> ==
> ERROR: system.test_thrift_server.TestMutations.test_bad_batch_calls
> --
> Traceback (most recent call last):
> File "/usr/local/lib/python2.7/site-packages/nose/case.py", line 381, in
> setUp
> try_run(self.inst, ('setup', 'setUp'))
> File "/usr/local/lib/python2.7/site-packages/nose/util.py", line 478, in
> try_run
> return func()
> File "/var/lib/jenkins/jobs/Cassandra/workspace/test/system/__init__.py",
> line 113, in setUp
> self.define_schema()
> File "/var/lib/jenkins/jobs/Cassandra/workspace/test/system/__init__.py",
> line 158, in define_schema
> Cassandra.CfDef('Keyspace1', 'Super1', column_type='Super',
> subcomparator_type='LongType', row_cache_size=1000, key_cache_size=0),
> TypeError: __init__() got an unexpected keyword argument 'key_cache_size'
> {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-3251) CassandraStorage uses comparator for both super column names and sub column names.
[ https://issues.apache.org/jira/browse/CASSANDRA-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3251: --- Attachment: CASSANDRA-3251-v3.patch v3 with implements proposed parameter change to AbstractType comparator and removes unnecessary 'ByteBuffer name' parameter. > CassandraStorage uses comparator for both super column names and sub column > names. > -- > > Key: CASSANDRA-3251 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3251 > Project: Cassandra > Issue Type: Bug > Components: Contrib, Hadoop >Affects Versions: 0.8.6 >Reporter: Dana H. P'Simer, Jr. >Assignee: Brandon Williams > Labels: cassandra, hadoop, pig > Fix For: 0.8.10 > > Attachments: 3251-v2.txt, CASSANDRA-3251-v3.patch, > CASSANDRA-3251.patch > > > The CassandraStorage class uses the same comparator for super and sub column > names. > This is because it calls columnsToTuple recursively without any indication > that the subsequent call is for sub columns. Also, the getDefaultMarshallers > method does not return the sub column name comparator. -- 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-3371) Cassandra inferred schema and actual data don't match
[
https://issues.apache.org/jira/browse/CASSANDRA-3371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-3371:
---
Reviewer: xedin
> Cassandra inferred schema and actual data don't match
> -
>
> Key: CASSANDRA-3371
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3371
> Project: Cassandra
> Issue Type: Bug
> Components: Hadoop
>Affects Versions: 0.8.7
>Reporter: Pete Warden
>Assignee: Brandon Williams
> Attachments: 3371-v2.txt, 3371-v3.txt, 3371-v4.txt, pig.diff
>
>
> It's looking like there may be a mismatch between the schema that's being
> reported by the latest CassandraStorage.java, and the data that's actually
> returned. Here's an example:
> rows = LOAD 'cassandra://Frap/PhotoVotes' USING CassandraStorage();
> DESCRIBE rows;
> rows: {key: chararray,columns: {(name: chararray,value:
> bytearray,photo_owner: chararray,value_photo_owner: bytearray,pid:
> chararray,value_pid: bytearray,matched_string:
> chararray,value_matched_string: bytearray,src_big: chararray,value_src_big:
> bytearray,time: chararray,value_time: bytearray,vote_type:
> chararray,value_vote_type: bytearray,voter: chararray,value_voter:
> bytearray)}}
> DUMP rows;
> (691831038_1317937188.48955,{(photo_owner,1596090180),(pid,6855155124568798560),(matched_string,),(src_big,),(time,Thu
> Oct 06 14:39:48 -0700 2011),(vote_type,album_dislike),(voter,691831038)})
> getSchema() is reporting the columns as an inner bag of tuples, each of which
> contains 16 values. In fact, getNext() seems to return an inner bag
> containing 7 tuples, each of which contains two values.
> It appears that things got out of sync with this change:
> http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/contrib/pig/src/java/org/apache/cassandra/hadoop/pig/CassandraStorage.java?r1=1177083&r2=1177082&pathrev=1177083
> See more discussion at:
> http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/pig-cassandra-problem-quot-Incompatible-field-schema-quot-error-tc6882703.html
--
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-3809) Show Index Options in CLI
[ https://issues.apache.org/jira/browse/CASSANDRA-3809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3809: --- Attachment: CASSANDRA-3809.patch > Show Index Options in CLI > - > > Key: CASSANDRA-3809 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3809 > Project: Cassandra > Issue Type: Improvement >Reporter: Pavel Yaskevich >Assignee: Pavel Yaskevich >Priority: Minor > Fix For: 1.0.8 > > Attachments: CASSANDRA-3809.patch > > > It's useful to show actual index options if any on `describe ` or > `show keyspaces`, that was already added to `show schema`. -- 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-3374) CQL can't create column with compression or that use leveled compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-3374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3374: --- Attachment: CASSANDRA-3374-compaction_strategy_class.patch it had that option but never actually bothered to set it :) > CQL can't create column with compression or that use leveled compaction > --- > > Key: CASSANDRA-3374 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3374 > Project: Cassandra > Issue Type: Bug > Components: API >Affects Versions: 1.0.0 >Reporter: Sylvain Lebresne >Assignee: Pavel Yaskevich >Priority: Minor > Labels: cql > Fix For: 1.0.8 > > Attachments: CASSANDRA-3374-compaction_strategy_class.patch, > CASSANDRA-3374.patch > > > Looking at CreateColumnFamilyStatement.java, it doesn't seem CQL can create > compressed column families, nor define a compaction strategy. -- 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-3794) Change ColumnFamily identifiers to be UUIDs instead of sequential Integers.
[ https://issues.apache.org/jira/browse/CASSANDRA-3794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3794: --- Comment: was deleted (was: Seems like it but description of that one is ambiguous so we can equally change the description there and close this one or close CASSANDRA-1983 and work on this.) > Change ColumnFamily identifiers to be UUIDs instead of sequential Integers. > --- > > Key: CASSANDRA-3794 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3794 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Pavel Yaskevich >Assignee: Pavel Yaskevich >Priority: Minor > Fix For: 1.2 > > > Change ColumnFamily identifiers to be UUIDs instead of sequential Integers. > Would be useful in the situation when nodes simultaneously trying to create > ColumnFamilies. -- 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-3559) CFMetaData conversions to Thrift/Avro should probably be inverse one of the other
[
https://issues.apache.org/jira/browse/CASSANDRA-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-3559:
---
Attachment: CASSANDRA-3559-v2.patch
rebased and removed avro test.
> CFMetaData conversions to Thrift/Avro should probably be inverse one of the
> other
> -
>
> Key: CASSANDRA-3559
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3559
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
>Priority: Minor
> Labels: avro, thrift
> Fix For: 1.1
>
> Attachments: 3559.patch, CASSANDRA-3559-v2.patch
>
>
> In other word, it would probably be a idea to have:
> {noformat}
> cfm == CFMetadata.fromThrift(cfm.toThrift())
> cfm == CFMetadata.fromAvro(cfm.toAvro())
> {noformat}
> In particular, we could have unit tests to check that, which would avoid
> things like CASSANDRA-3558.
> It is not the case today for thrift because of the keyAlias. For some reason,
> if the keyAlias is not set, we return with toThrift() the default alias. I
> don't think this serves any purpose though.
> The goal of this ticket is to both fix that (unless there is a compelling
> reason not to) and add unit tests for this.
--
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-2392) Saving IndexSummaries to disk
[
https://issues.apache.org/jira/browse/CASSANDRA-2392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-2392:
---
Attachment: CASSANDRA-2392-v5.patch
changed SUMMARIES to SUMMARY, {load, save}Summaries to {load, save}Summary,
changed few variable names, added/extended comments and log messages, added
condition to skip IndexSummary re-population while primary_index is read and
IndexSummary was already successfully loaded in SSTableReader.load(...), please
test and let me know what you think.
> Saving IndexSummaries to disk
> -
>
> Key: CASSANDRA-2392
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2392
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Chris Goffinet
>Assignee: Vijay
>Priority: Minor
> Fix For: 1.2
>
> Attachments: 0001-re-factor-first-and-last.patch,
> 0001-save-summaries-to-disk-v4.patch, 0001-save-summaries-to-disk.patch,
> 0002-save-summaries-to-disk-v2.patch, 0002-save-summaries-to-disk-v3.patch,
> 0002-save-summaries-to-disk.patch, CASSANDRA-2392-v5.patch
>
>
> For nodes with millions of keys, doing rolling restarts that take over 10
> minutes per node can be painful if you have 100 node cluster. All of our time
> is spent on doing index summary computations on startup. It would be great if
> we could save those to disk as well. Our indexes are quite large.
--
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-3759) [patch] don't allow dropping the system keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3759: --- Attachment: CASSANDRA-3759-fix-create-update-drop-keyspaces.patch removed validation from ClientState.hasKeyspaceSchemaAccess(...) and placed it to the dedicated ThriftValidation.validateKeyspaceNotSystem(String), fixes create/drop/update keyspaces different from system when inside of that keyspace. > [patch] don't allow dropping the system keyspace > > > Key: CASSANDRA-3759 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3759 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Dave Brosius >Assignee: Dave Brosius >Priority: Trivial > Fix For: 1.0.8 > > Attachments: CASSANDRA-3759-fix-create-update-drop-keyspaces.patch, > CASSANDRA-3759-npe-fix.patch, no_drop_system.diff > > > throw an IRE if user attempts to drop system keyspace -- 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-1391) Allow Concurrent Schema Migrations
[ https://issues.apache.org/jira/browse/CASSANDRA-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-1391: --- Attachment: CASSANDRA-1391-v2.patch squashed previous two comments in one and added schema differentiation between schema_keyspaces, schema_columnfamilies and schema_columns. > Allow Concurrent Schema Migrations > -- > > Key: CASSANDRA-1391 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1391 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 0.7.0 >Reporter: Stu Hood >Assignee: Pavel Yaskevich >Priority: Critical > Fix For: 1.1 > > Attachments: 0001-CASSANDRA-1391-main.patch, > 0002-CASSANDRA-1391-fixes.patch, 1391-rebased.txt, CASSANDRA-1391-v2.patch, > CASSANDRA-1391.patch > > > CASSANDRA-1292 fixed multiple migrations started from the same node to > properly queue themselves, but it is still possible for migrations initiated > on different nodes to conflict and leave the cluster in a bad state. Since > the system_add/drop/rename methods are accessible directly from the client > API, they should be completely safe for concurrent use. > It should be possible to allow for most types of concurrent migrations by > converting the UUID schema ID into a VersionVectorClock (as provided by > CASSANDRA-580). -- 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-3759) [patch] don't allow dropping the system keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3759: --- Attachment: CASSANDRA-3759-npe-fix.patch fixes NPE exception in hasKeyspaceSchemaAccess(...) because keyspace is not required to be always set. > [patch] don't allow dropping the system keyspace > > > Key: CASSANDRA-3759 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3759 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Dave Brosius >Assignee: Dave Brosius >Priority: Trivial > Fix For: 1.0.8 > > Attachments: CASSANDRA-3759-npe-fix.patch, no_drop_system.diff > > > throw an IRE if user attempts to drop system keyspace -- 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-1391) Allow Concurrent Schema Migrations
[ https://issues.apache.org/jira/browse/CASSANDRA-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-1391: --- Attachment: 0002-CASSANDRA-1391-fixes.patch 0001-CASSANDRA-1391-main.patch Rebased main patch and fixes from Jonathan's previous comment: dropped unused method from SystemTable - dropOldSchemaTables, added KEYSPACES_CF layout information to DefsTable class header (made comment about that in the SystemTable), combined all low-level methods from Schema and DefsTable into SystemTable. > Allow Concurrent Schema Migrations > -- > > Key: CASSANDRA-1391 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1391 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 0.7.0 >Reporter: Stu Hood >Assignee: Pavel Yaskevich >Priority: Critical > Fix For: 1.1 > > Attachments: 0001-CASSANDRA-1391-main.patch, > 0002-CASSANDRA-1391-fixes.patch, 1391-rebased.txt, CASSANDRA-1391.patch > > > CASSANDRA-1292 fixed multiple migrations started from the same node to > properly queue themselves, but it is still possible for migrations initiated > on different nodes to conflict and leave the cluster in a bad state. Since > the system_add/drop/rename methods are accessible directly from the client > API, they should be completely safe for concurrent use. > It should be possible to allow for most types of concurrent migrations by > converting the UUID schema ID into a VersionVectorClock (as provided by > CASSANDRA-580). -- 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-1391) Allow Concurrent Schema Migrations
[ https://issues.apache.org/jira/browse/CASSANDRA-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-1391: --- Attachment: CASSANDRA-1391.patch Migrations are made one-time local thing, serialization/deserialization and save to system cfs are removed. Schema is propagated in from of row mutations to be applied on the system 'keyspaces' cf (apply/diff strategy), upon local user-initiated migration node uses push tactic (sends updated schema state to all alive nodes in the cluster), pull tactic (when node requests schema from remote node) is enabled only when node detects schema disagreement by means of Gossip e.g. when new node joins the ring or push was lost due to network or other circumstances. Supports automatic schema migration from old storage (after migration deprecated system 'schema' and 'migrations' column families are dropped). toAvro() methods are removed as no longer needed, fromAvro(...) methods are kept as @Deprecated to support schema migration from schema cf to new cf. 'Keyspaces' CF contain data in the human-readable JSON format. > Allow Concurrent Schema Migrations > -- > > Key: CASSANDRA-1391 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1391 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 0.7.0 >Reporter: Stu Hood >Assignee: Pavel Yaskevich >Priority: Critical > Fix For: 1.1 > > Attachments: CASSANDRA-1391.patch > > > CASSANDRA-1292 fixed multiple migrations started from the same node to > properly queue themselves, but it is still possible for migrations initiated > on different nodes to conflict and leave the cluster in a bad state. Since > the system_add/drop/rename methods are accessible directly from the client > API, they should be completely safe for concurrent use. > It should be possible to allow for most types of concurrent migrations by > converting the UUID schema ID into a VersionVectorClock (as provided by > CASSANDRA-580). -- 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-1391) Allow Concurrent Schema Migrations
[ https://issues.apache.org/jira/browse/CASSANDRA-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-1391: --- Attachment: (was: CASSANDRA-1391.patch) > Allow Concurrent Schema Migrations > -- > > Key: CASSANDRA-1391 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1391 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 0.7.0 >Reporter: Stu Hood >Assignee: Pavel Yaskevich >Priority: Critical > Fix For: 1.1 > > > CASSANDRA-1292 fixed multiple migrations started from the same node to > properly queue themselves, but it is still possible for migrations initiated > on different nodes to conflict and leave the cluster in a bad state. Since > the system_add/drop/rename methods are accessible directly from the client > API, they should be completely safe for concurrent use. > It should be possible to allow for most types of concurrent migrations by > converting the UUID schema ID into a VersionVectorClock (as provided by > CASSANDRA-580). -- 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-1391) Allow Concurrent Schema Migrations
[ https://issues.apache.org/jira/browse/CASSANDRA-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-1391: --- Attachment: (was: 0001-new-migration-schema-and-avro-methods-cleanup.patch) > Allow Concurrent Schema Migrations > -- > > Key: CASSANDRA-1391 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1391 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 0.7.0 >Reporter: Stu Hood >Assignee: Pavel Yaskevich >Priority: Critical > Fix For: 1.1 > > > CASSANDRA-1292 fixed multiple migrations started from the same node to > properly queue themselves, but it is still possible for migrations initiated > on different nodes to conflict and leave the cluster in a bad state. Since > the system_add/drop/rename methods are accessible directly from the client > API, they should be completely safe for concurrent use. > It should be possible to allow for most types of concurrent migrations by > converting the UUID schema ID into a VersionVectorClock (as provided by > CASSANDRA-580). -- 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-1391) Allow Concurrent Schema Migrations
[ https://issues.apache.org/jira/browse/CASSANDRA-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-1391: --- Attachment: (was: 0003-oldVersion-removed-new-migration-distribution-schema.patch) > Allow Concurrent Schema Migrations > -- > > Key: CASSANDRA-1391 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1391 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 0.7.0 >Reporter: Stu Hood >Assignee: Pavel Yaskevich >Priority: Critical > Fix For: 1.1 > > > CASSANDRA-1292 fixed multiple migrations started from the same node to > properly queue themselves, but it is still possible for migrations initiated > on different nodes to conflict and leave the cluster in a bad state. Since > the system_add/drop/rename methods are accessible directly from the client > API, they should be completely safe for concurrent use. > It should be possible to allow for most types of concurrent migrations by > converting the UUID schema ID into a VersionVectorClock (as provided by > CASSANDRA-580). -- 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-1391) Allow Concurrent Schema Migrations
[ https://issues.apache.org/jira/browse/CASSANDRA-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-1391: --- Attachment: (was: 0002-avro-removal.patch) > Allow Concurrent Schema Migrations > -- > > Key: CASSANDRA-1391 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1391 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 0.7.0 >Reporter: Stu Hood >Assignee: Pavel Yaskevich >Priority: Critical > Fix For: 1.1 > > > CASSANDRA-1292 fixed multiple migrations started from the same node to > properly queue themselves, but it is still possible for migrations initiated > on different nodes to conflict and leave the cluster in a bad state. Since > the system_add/drop/rename methods are accessible directly from the client > API, they should be completely safe for concurrent use. > It should be possible to allow for most types of concurrent migrations by > converting the UUID schema ID into a VersionVectorClock (as provided by > CASSANDRA-580). -- 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-3727) Fix unit tests failure
[
https://issues.apache.org/jira/browse/CASSANDRA-3727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-3727:
---
Attachment: CASSANDRA-3727-CliTest-timeout-fix.patch
fixed CliTest timeout by correctly closing transport connection which allows
Cassandra shutdown hook to proceed without waiting for RPC connections to close.
> Fix unit tests failure
> --
>
> Key: CASSANDRA-3727
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3727
> Project: Cassandra
> Issue Type: Bug
> Components: Tests
>Affects Versions: 1.0.7
>Reporter: Sylvain Lebresne
>Priority: Blocker
> Fix For: 1.0.7
>
> Attachments: CASSANDRA-3727-CliTest-timeout-fix.patch
>
>
> On current 1.0 branch (and on my machine: Linux), I have the following unit
> test failures:
> * CliTest and EmbeddedCassandraTest: they both first kind of pass (JUnit
> first prints a message with no failures in it), then hang until JUnit timeout
> and fails with a 'Timeout occurred'. In other word, the tests themselves are
> passing, but something they do prevents the process to exit cleanly leading
> to a JUnit timeout. I don't want to discard that as not a problem, because if
> something can make the process not exit cleanly, this can be a pain for
> restarts (and in particular upgrades) and hence would be basically a
> regression. I'm marking the ticket as blocker (for the release of 1.0.7)
> mostly because of this one.
> * SystemTableTest: throws an assertionError. I haven't checked yet, so that
> could be an easy one to fix.
> * RemoveTest: it fails, saying that '/127.0.0.1:7010 is in use by another
> process' (consistently). But I have no other process running on port 7010.
> It's likely just of problem of the test, but it's new and in the meantime
> removes are not tested.
> * I also see a bunch of stack trace with errors like:
> {noformat}
> [junit] ERROR 10:01:59,007 Fatal exception in thread
> Thread[NonPeriodicTasks:1,5,main]
> [junit] java.lang.RuntimeException: java.io.IOException: Unable to create
> hard link from build/test/cassandra/data/Keyspace1/Indexed1-hc-1-Index.db to
> /home/mcmanus/Git/cassandra/build/test/cassandra/data/Keyspace1/backups/Indexed1-hc-1-Index.db
> (errno 17)
> {noformat}
> (with SSTableReaderTest). This does not make the tests fail, but it is still
> worth investigating. It may be due to CASSANDRA-3101.
--
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-3700) SelectStatement start/end key are not set correctly when a key alias is involved
[ https://issues.apache.org/jira/browse/CASSANDRA-3700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3700: --- Attachment: CASSANDRA-3700.patch > SelectStatement start/end key are not set correctly when a key alias is > involved > > > Key: CASSANDRA-3700 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3700 > Project: Cassandra > Issue Type: Bug > Components: API >Affects Versions: 0.8.1 >Reporter: Jonathan Ellis >Assignee: Pavel Yaskevich > Labels: cql > Fix For: 1.0.8 > > Attachments: CASSANDRA-3700.patch > > > start/end key are set by antlr in WhereClause, but this depends on the "KEY" > keyword. -- 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-3700) SelectStatement start/end key are not set correctly when a key alias is involved
[ https://issues.apache.org/jira/browse/CASSANDRA-3700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3700: --- Attachment: (was: CASSANDRA-3700.patch) > SelectStatement start/end key are not set correctly when a key alias is > involved > > > Key: CASSANDRA-3700 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3700 > Project: Cassandra > Issue Type: Bug > Components: API >Affects Versions: 0.8.1 >Reporter: Jonathan Ellis >Assignee: Pavel Yaskevich > Labels: cql > Fix For: 1.0.8 > > Attachments: CASSANDRA-3700.patch > > > start/end key are set by antlr in WhereClause, but this depends on the "KEY" > keyword. -- 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-3700) SelectStatement start/end key are not set correctly when a key alias is involved
[ https://issues.apache.org/jira/browse/CASSANDRA-3700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3700: --- Attachment: CASSANDRA-3700.patch > SelectStatement start/end key are not set correctly when a key alias is > involved > > > Key: CASSANDRA-3700 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3700 > Project: Cassandra > Issue Type: Bug > Components: API >Affects Versions: 0.8.1 >Reporter: Jonathan Ellis >Assignee: Pavel Yaskevich > Labels: cql > Fix For: 1.0.8 > > Attachments: CASSANDRA-3700.patch > > > start/end key are set by antlr in WhereClause, but this depends on the "KEY" > keyword. -- 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-1391) Allow Concurrent Schema Migrations
[ https://issues.apache.org/jira/browse/CASSANDRA-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-1391: --- Attachment: (was: 0003-oldVersion-removed-new-migration-distribution-schema.patch) > Allow Concurrent Schema Migrations > -- > > Key: CASSANDRA-1391 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1391 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 0.7.0 >Reporter: Stu Hood >Assignee: Pavel Yaskevich > Fix For: 1.1 > > Attachments: > 0001-new-migration-schema-and-avro-methods-cleanup.patch, > 0002-avro-removal.patch, > 0003-oldVersion-removed-new-migration-distribution-schema.patch, > CASSANDRA-1391.patch > > > CASSANDRA-1292 fixed multiple migrations started from the same node to > properly queue themselves, but it is still possible for migrations initiated > on different nodes to conflict and leave the cluster in a bad state. Since > the system_add/drop/rename methods are accessible directly from the client > API, they should be completely safe for concurrent use. > It should be possible to allow for most types of concurrent migrations by > converting the UUID schema ID into a VersionVectorClock (as provided by > CASSANDRA-580). -- 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-1391) Allow Concurrent Schema Migrations
[ https://issues.apache.org/jira/browse/CASSANDRA-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-1391: --- Attachment: 0003-oldVersion-removed-new-migration-distribution-schema.patch 0003 properly rebased > Allow Concurrent Schema Migrations > -- > > Key: CASSANDRA-1391 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1391 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 0.7.0 >Reporter: Stu Hood >Assignee: Pavel Yaskevich > Fix For: 1.1 > > Attachments: > 0001-new-migration-schema-and-avro-methods-cleanup.patch, > 0002-avro-removal.patch, > 0003-oldVersion-removed-new-migration-distribution-schema.patch, > CASSANDRA-1391.patch > > > CASSANDRA-1292 fixed multiple migrations started from the same node to > properly queue themselves, but it is still possible for migrations initiated > on different nodes to conflict and leave the cluster in a bad state. Since > the system_add/drop/rename methods are accessible directly from the client > API, they should be completely safe for concurrent use. > It should be possible to allow for most types of concurrent migrations by > converting the UUID schema ID into a VersionVectorClock (as provided by > CASSANDRA-580). -- 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-1391) Allow Concurrent Schema Migrations
[ https://issues.apache.org/jira/browse/CASSANDRA-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-1391: --- Attachment: 0003-oldVersion-removed-new-migration-distribution-schema.patch 0002-avro-removal.patch 0001-new-migration-schema-and-avro-methods-cleanup.patch rebased with the lastest trunk (last commit 38c04fef0a431bf29010074bad1d35d87a739c02) > Allow Concurrent Schema Migrations > -- > > Key: CASSANDRA-1391 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1391 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 0.7.0 >Reporter: Stu Hood >Assignee: Pavel Yaskevich > Fix For: 1.1 > > Attachments: > 0001-new-migration-schema-and-avro-methods-cleanup.patch, > 0002-avro-removal.patch, > 0003-oldVersion-removed-new-migration-distribution-schema.patch, > CASSANDRA-1391.patch > > > CASSANDRA-1292 fixed multiple migrations started from the same node to > properly queue themselves, but it is still possible for migrations initiated > on different nodes to conflict and leave the cluster in a bad state. Since > the system_add/drop/rename methods are accessible directly from the client > API, they should be completely safe for concurrent use. > It should be possible to allow for most types of concurrent migrations by > converting the UUID schema ID into a VersionVectorClock (as provided by > CASSANDRA-580). -- 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-1391) Allow Concurrent Schema Migrations
[ https://issues.apache.org/jira/browse/CASSANDRA-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-1391: --- Attachment: (was: 0002-avro-removal.patch) > Allow Concurrent Schema Migrations > -- > > Key: CASSANDRA-1391 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1391 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 0.7.0 >Reporter: Stu Hood >Assignee: Pavel Yaskevich > Fix For: 1.1 > > Attachments: > 0001-new-migration-schema-and-avro-methods-cleanup.patch, > 0002-avro-removal.patch, > 0003-oldVersion-removed-new-migration-distribution-schema.patch, > CASSANDRA-1391.patch > > > CASSANDRA-1292 fixed multiple migrations started from the same node to > properly queue themselves, but it is still possible for migrations initiated > on different nodes to conflict and leave the cluster in a bad state. Since > the system_add/drop/rename methods are accessible directly from the client > API, they should be completely safe for concurrent use. > It should be possible to allow for most types of concurrent migrations by > converting the UUID schema ID into a VersionVectorClock (as provided by > CASSANDRA-580). -- 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-1391) Allow Concurrent Schema Migrations
[ https://issues.apache.org/jira/browse/CASSANDRA-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-1391: --- Attachment: (was: 0001-new-migration-schema-and-avro-methods-cleanup.patch) > Allow Concurrent Schema Migrations > -- > > Key: CASSANDRA-1391 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1391 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 0.7.0 >Reporter: Stu Hood >Assignee: Pavel Yaskevich > Fix For: 1.1 > > Attachments: > 0001-new-migration-schema-and-avro-methods-cleanup.patch, > 0002-avro-removal.patch, > 0003-oldVersion-removed-new-migration-distribution-schema.patch, > CASSANDRA-1391.patch > > > CASSANDRA-1292 fixed multiple migrations started from the same node to > properly queue themselves, but it is still possible for migrations initiated > on different nodes to conflict and leave the cluster in a bad state. Since > the system_add/drop/rename methods are accessible directly from the client > API, they should be completely safe for concurrent use. > It should be possible to allow for most types of concurrent migrations by > converting the UUID schema ID into a VersionVectorClock (as provided by > CASSANDRA-580). -- 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-1391) Allow Concurrent Schema Migrations
[ https://issues.apache.org/jira/browse/CASSANDRA-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-1391: --- Attachment: (was: 0003-oldVersion-removed-new-migration-distribution-schema.patch) > Allow Concurrent Schema Migrations > -- > > Key: CASSANDRA-1391 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1391 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 0.7.0 >Reporter: Stu Hood >Assignee: Pavel Yaskevich > Fix For: 1.1 > > Attachments: > 0001-new-migration-schema-and-avro-methods-cleanup.patch, > 0002-avro-removal.patch, > 0003-oldVersion-removed-new-migration-distribution-schema.patch, > CASSANDRA-1391.patch > > > CASSANDRA-1292 fixed multiple migrations started from the same node to > properly queue themselves, but it is still possible for migrations initiated > on different nodes to conflict and leave the cluster in a bad state. Since > the system_add/drop/rename methods are accessible directly from the client > API, they should be completely safe for concurrent use. > It should be possible to allow for most types of concurrent migrations by > converting the UUID schema ID into a VersionVectorClock (as provided by > CASSANDRA-580). -- 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-3667) We need a way to deactivate row/key caching on a per-cf basis.
[ https://issues.apache.org/jira/browse/CASSANDRA-3667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3667: --- Attachment: CASSANDRA-3667-v2-with-nits-fixed.patch v2 - nits fixed and rebased with the latest trunk (last commit 329dd758e8b07368c4bab5451c42dc04b0bb48ae) > We need a way to deactivate row/key caching on a per-cf basis. > -- > > Key: CASSANDRA-3667 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3667 > Project: Cassandra > Issue Type: Improvement >Reporter: Pavel Yaskevich >Assignee: Pavel Yaskevich > Fix For: 1.1 > > Attachments: CASSANDRA-3667-v2-with-nits-fixed.patch, > CASSANDRA-3667.patch > > > Initial idea would be to either have a boolean flag if we only want to allow > disabling row cache, or some multi-value caches option that could be "none", > "key_only", "row_only" or "all". -- 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-3667) We need a way to deactivate row/key caching on a per-cf basis.
[ https://issues.apache.org/jira/browse/CASSANDRA-3667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3667: --- Attachment: CASSANDRA-3667.patch > We need a way to deactivate row/key caching on a per-cf basis. > -- > > Key: CASSANDRA-3667 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3667 > Project: Cassandra > Issue Type: Improvement >Reporter: Pavel Yaskevich >Assignee: Pavel Yaskevich > Attachments: CASSANDRA-3667.patch > > > Initial idea would be to either have a boolean flag if we only want to allow > disabling row cache, or some multi-value caches option that could be "none", > "key_only", "row_only" or "all". -- 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-1391) Allow Concurrent Schema Migrations
[ https://issues.apache.org/jira/browse/CASSANDRA-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-1391: --- Attachment: 0003-oldVersion-removed-new-migration-distribution-schema.patch 0002-avro-removal.patch 0001-new-migration-schema-and-avro-methods-cleanup.patch rebased parts 1-2 and part 3 handles the new way of schema distribution, now each node after applying migration locally calculates a content-based schema version (calculated from system.keyspaces CF) and gossips it, others listen on onChange and onAlive methods and when schema update is received them match version to their and in case it does not equal node requests migrations but sending MIGRATION_REQUEST message with serialized list of the local migration ids, coordinator sends serialized migrations in response. After migrations received by requesting node it applies them locally one by one. > Allow Concurrent Schema Migrations > -- > > Key: CASSANDRA-1391 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1391 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 0.7.0 >Reporter: Stu Hood >Assignee: Pavel Yaskevich > Fix For: 1.1 > > Attachments: > 0001-new-migration-schema-and-avro-methods-cleanup.patch, > 0002-avro-removal.patch, > 0003-oldVersion-removed-new-migration-distribution-schema.patch, > CASSANDRA-1391.patch > > > CASSANDRA-1292 fixed multiple migrations started from the same node to > properly queue themselves, but it is still possible for migrations initiated > on different nodes to conflict and leave the cluster in a bad state. Since > the system_add/drop/rename methods are accessible directly from the client > API, they should be completely safe for concurrent use. > It should be possible to allow for most types of concurrent migrations by > converting the UUID schema ID into a VersionVectorClock (as provided by > CASSANDRA-580). -- 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-1391) Allow Concurrent Schema Migrations
[ https://issues.apache.org/jira/browse/CASSANDRA-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-1391: --- Attachment: (was: 0001-new-migration-schema-and-avro-methods-cleanup.patch) > Allow Concurrent Schema Migrations > -- > > Key: CASSANDRA-1391 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1391 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 0.7.0 >Reporter: Stu Hood >Assignee: Pavel Yaskevich > Fix For: 1.1 > > Attachments: CASSANDRA-1391.patch > > > CASSANDRA-1292 fixed multiple migrations started from the same node to > properly queue themselves, but it is still possible for migrations initiated > on different nodes to conflict and leave the cluster in a bad state. Since > the system_add/drop/rename methods are accessible directly from the client > API, they should be completely safe for concurrent use. > It should be possible to allow for most types of concurrent migrations by > converting the UUID schema ID into a VersionVectorClock (as provided by > CASSANDRA-580). -- 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-1391) Allow Concurrent Schema Migrations
[ https://issues.apache.org/jira/browse/CASSANDRA-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-1391: --- Attachment: (was: 0002-avro-removal.patch) > Allow Concurrent Schema Migrations > -- > > Key: CASSANDRA-1391 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1391 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 0.7.0 >Reporter: Stu Hood >Assignee: Pavel Yaskevich > Fix For: 1.1 > > Attachments: CASSANDRA-1391.patch > > > CASSANDRA-1292 fixed multiple migrations started from the same node to > properly queue themselves, but it is still possible for migrations initiated > on different nodes to conflict and leave the cluster in a bad state. Since > the system_add/drop/rename methods are accessible directly from the client > API, they should be completely safe for concurrent use. > It should be possible to allow for most types of concurrent migrations by > converting the UUID schema ID into a VersionVectorClock (as provided by > CASSANDRA-580). -- 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-3611) Make checksum on a compressed blocks optional
[ https://issues.apache.org/jira/browse/CASSANDRA-3611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3611: --- Attachment: CASSANDRA-3611-v4.patch here is v4 which fixes bug in the validate(), bug was "when there are no chunkLength supplied validate method would just return without checking validating other parameters" . I will commit it when svn -> git transition is complete. > Make checksum on a compressed blocks optional > - > > Key: CASSANDRA-3611 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3611 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 1.1 >Reporter: Vijay >Assignee: Vijay >Priority: Minor > Labels: compression > Fix For: 1.1 > > Attachments: 0001-crc-check-chance-v2.patch, > 0001-crc-check-chance-v3.patch, 0001-crc-check-chance.patch, > CASSANDRA-3611-v4.patch > > > Currently every uncompressed block is run against checksum algo, there is cpu > overhead in doing same... We might want to make it configurable/optional for > some use cases which might not require checksum all the time. -- 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-3143) Global caches (key/row)
[ https://issues.apache.org/jira/browse/CASSANDRA-3143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3143: --- Attachment: 0003-final-fixes.patch 0002-fixes.patch 0001-CASSANDRA-3143-squashed.patch rebased 0001 and 0002 + 0003 with final fixes > Global caches (key/row) > --- > > Key: CASSANDRA-3143 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3143 > Project: Cassandra > Issue Type: Improvement >Reporter: Pavel Yaskevich >Assignee: Pavel Yaskevich >Priority: Minor > Labels: Core > Fix For: 1.1 > > Attachments: 0001-CASSANDRA-3143-squashed.patch, 0002-fixes.patch, > 0003-final-fixes.patch > > > Caches are difficult to configure well as ColumnFamilies are added, similar > to how memtables were difficult pre-CASSANDRA-2006. -- 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-3143) Global caches (key/row)
[ https://issues.apache.org/jira/browse/CASSANDRA-3143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3143: --- Attachment: (was: CASSANDRA-3143-squashed.patch) > Global caches (key/row) > --- > > Key: CASSANDRA-3143 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3143 > Project: Cassandra > Issue Type: Improvement >Reporter: Pavel Yaskevich >Assignee: Pavel Yaskevich >Priority: Minor > Labels: Core > Fix For: 1.1 > > > Caches are difficult to configure well as ColumnFamilies are added, similar > to how memtables were difficult pre-CASSANDRA-2006. -- 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-3143) Global caches (key/row)
[ https://issues.apache.org/jira/browse/CASSANDRA-3143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3143: --- Attachment: (was: 0002-fixes.patch) > Global caches (key/row) > --- > > Key: CASSANDRA-3143 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3143 > Project: Cassandra > Issue Type: Improvement >Reporter: Pavel Yaskevich >Assignee: Pavel Yaskevich >Priority: Minor > Labels: Core > Fix For: 1.1 > > > Caches are difficult to configure well as ColumnFamilies are added, similar > to how memtables were difficult pre-CASSANDRA-2006. -- 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-3374) CQL can't create column with compression or that use leveled compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-3374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3374: --- Attachment: CASSANDRA-3374.patch patch adds update to CQL.doc > CQL can't create column with compression or that use leveled compaction > --- > > Key: CASSANDRA-3374 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3374 > Project: Cassandra > Issue Type: Bug > Components: API >Affects Versions: 1.0.0 >Reporter: Sylvain Lebresne >Assignee: Pavel Yaskevich >Priority: Minor > Labels: cql > Fix For: 1.0.7 > > Attachments: CASSANDRA-3374.patch > > > Looking at CreateColumnFamilyStatement.java, it doesn't seem CQL can create > compressed column families, nor define a compaction strategy. -- 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-3374) CQL can't create column with compression or that use leveled compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-3374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3374: --- Attachment: (was: CASSANDRA-3374.patch) > CQL can't create column with compression or that use leveled compaction > --- > > Key: CASSANDRA-3374 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3374 > Project: Cassandra > Issue Type: Bug > Components: API >Affects Versions: 1.0.0 >Reporter: Sylvain Lebresne >Assignee: Pavel Yaskevich >Priority: Minor > Labels: cql > Fix For: 1.0.7 > > > Looking at CreateColumnFamilyStatement.java, it doesn't seem CQL can create > compressed column families, nor define a compaction strategy. -- 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-3374) CQL can't create column with compression or that use leveled compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-3374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3374: --- Reviewer: thepaul (was: jbellis) > CQL can't create column with compression or that use leveled compaction > --- > > Key: CASSANDRA-3374 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3374 > Project: Cassandra > Issue Type: Bug > Components: API >Affects Versions: 1.0.0 >Reporter: Sylvain Lebresne >Assignee: Pavel Yaskevich >Priority: Minor > Labels: cql > Fix For: 1.0.7 > > Attachments: CASSANDRA-3374.patch > > > Looking at CreateColumnFamilyStatement.java, it doesn't seem CQL can create > compressed column families, nor define a compaction strategy. -- 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-3374) CQL can't create column with compression or that use leveled compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-3374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3374: --- Reviewer: jbellis (was: xedin) Assignee: Pavel Yaskevich (was: paul cannon) > CQL can't create column with compression or that use leveled compaction > --- > > Key: CASSANDRA-3374 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3374 > Project: Cassandra > Issue Type: Bug > Components: API >Affects Versions: 1.0.0 >Reporter: Sylvain Lebresne >Assignee: Pavel Yaskevich >Priority: Minor > Labels: cql > Fix For: 1.0.7 > > Attachments: CASSANDRA-3374.patch > > > Looking at CreateColumnFamilyStatement.java, it doesn't seem CQL can create > compressed column families, nor define a compaction strategy. -- 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-3374) CQL can't create column with compression or that use leveled compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-3374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3374: --- Attachment: CASSANDRA-3374.patch rebased patch. everything works as expected with cql fixed! > CQL can't create column with compression or that use leveled compaction > --- > > Key: CASSANDRA-3374 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3374 > Project: Cassandra > Issue Type: Bug > Components: API >Affects Versions: 1.0.0 >Reporter: Sylvain Lebresne >Assignee: paul cannon >Priority: Minor > Labels: cql > Fix For: 1.0.7 > > Attachments: CASSANDRA-3374.patch > > > Looking at CreateColumnFamilyStatement.java, it doesn't seem CQL can create > compressed column families, nor define a compaction strategy. -- 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
