date:20140210

Ilya Kramer created CASSANDRA-6684:
--

 Summary: Count fails with Illegal Capacity: -1
 Key: CASSANDRA-6684
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6684
 Project: Cassandra
  Issue Type: Bug
 Environment: Ubuntu(multiple versions, 12.04 LTS and 13.04)
Reporter: Ilya Kramer


Whenever I try to count a row key which has exactly 3072(don't have a clue what 
special about that number) columns, I get the exception 'Illegal Capacity: -1'

When I remove or add a single column the count work as expected.

I'll attach a small script to replicate, as well as the data of the failed to 
count row.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (CASSANDRA-6684) Count fails with Illegal Capacity: -1


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-6684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ilya Kramer updated CASSANDRA-6684:
---

Attachment: import.py
prow2

 Count fails with Illegal Capacity: -1
 -

 Key: CASSANDRA-6684
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6684
 Project: Cassandra
  Issue Type: Bug
 Environment: Ubuntu(multiple versions, 12.04 LTS and 13.04)
Reporter: Ilya Kramer
 Attachments: import.py, prow2


 Whenever I try to count a row key which has exactly 3072(don't have a clue 
 what special about that number) columns, I get the exception 'Illegal 
 Capacity: -1'
 When I remove or add a single column the count work as expected.
 I'll attach a small script to replicate, as well as the data of the failed to 
 count row.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CASSANDRA-6684) Count fails with Illegal Capacity: -1


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896311#comment-13896311
 ] 

Ilya Kramer commented on CASSANDRA-6684:


Sorry the script is in python(pycassa) it was the easiest way for me to 
replicate that issue, but I also see it on astyanax and cassandra-cli, so I 
doubt the bug is on pycassa.

If you don't want to run the script to replicate, just create the following cf:
CREATE COLUMN FAMILY cw_last
WITH comparator = 'CompositeType(UTF8Type,UTF8Type,UTF8Type,UTF8Type)'
AND key_validation_class = TimeUUIDType;

and put every line of the csv(prow2) as a column in the CF, with blank value.

Thanks


 Count fails with Illegal Capacity: -1
 -

 Key: CASSANDRA-6684
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6684
 Project: Cassandra
  Issue Type: Bug
 Environment: Ubuntu(multiple versions, 12.04 LTS and 13.04)
Reporter: Ilya Kramer
 Attachments: import.py, prow2


 Whenever I try to count a row key which has exactly 3072(don't have a clue 
 what special about that number) columns, I get the exception 'Illegal 
 Capacity: -1'
 When I remove or add a single column the count work as expected.
 I'll attach a small script to replicate, as well as the data of the failed to 
 count row.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (CASSANDRA-6684) Count fails with Illegal Capacity: -1

2014-02-10 Thread Sylvain Lebresne (JIRA)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-6684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sylvain Lebresne resolved CASSANDRA-6684.
-

Resolution: Duplicate

As it happens, this is almost surely a duplicate of CASSANDRA-6555. Please 
check C* 2.0.5.

 Count fails with Illegal Capacity: -1
 -

 Key: CASSANDRA-6684
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6684
 Project: Cassandra
  Issue Type: Bug
 Environment: Ubuntu(multiple versions, 12.04 LTS and 13.04)
Reporter: Ilya Kramer
 Attachments: import.py, prow2


 Whenever I try to count a row key which has exactly 3072(don't have a clue 
 what special about that number) columns, I get the exception 'Illegal 
 Capacity: -1'
 When I remove or add a single column the count work as expected.
 I'll attach a small script to replicate, as well as the data of the failed to 
 count row.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CASSANDRA-6684) Count fails with Illegal Capacity: -1


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896318#comment-13896318
 ] 

Ilya Kramer commented on CASSANDRA-6684:


I'll check it when 2.0.5 deb will be available, thanks for the quick response

 Count fails with Illegal Capacity: -1
 -

 Key: CASSANDRA-6684
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6684
 Project: Cassandra
  Issue Type: Bug
 Environment: Ubuntu(multiple versions, 12.04 LTS and 13.04)
Reporter: Ilya Kramer
 Attachments: import.py, prow2


 Whenever I try to count a row key which has exactly 3072(don't have a clue 
 what special about that number) columns, I get the exception 'Illegal 
 Capacity: -1'
 When I remove or add a single column the count work as expected.
 I'll attach a small script to replicate, as well as the data of the failed to 
 count row.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CASSANDRA-6684) Count fails with Illegal Capacity: -1

2014-02-10 Thread Sylvain Lebresne (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896327#comment-13896327
 ] 

Sylvain Lebresne commented on CASSANDRA-6684:
-

bq. I'll check it when 2.0.5 deb will be available

It is available, at least on the main mirror: 
http://www.apache.org/dist/cassandra/debian/dists/20x/main/binary-amd64/Packages

 Count fails with Illegal Capacity: -1
 -

 Key: CASSANDRA-6684
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6684
 Project: Cassandra
  Issue Type: Bug
 Environment: Ubuntu(multiple versions, 12.04 LTS and 13.04)
Reporter: Ilya Kramer
 Attachments: import.py, prow2


 Whenever I try to count a row key which has exactly 3072(don't have a clue 
 what special about that number) columns, I get the exception 'Illegal 
 Capacity: -1'
 When I remove or add a single column the count work as expected.
 I'll attach a small script to replicate, as well as the data of the failed to 
 count row.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Comment Edited] (CASSANDRA-6332) Cassandra startup failure: java.util.concurrent.ExecutionException: java.lang.RuntimeException: 706167655f74616773 is not defined as a collection

2014-02-10 Thread Mck SembWever (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13895873#comment-13895873
 ] 

Mck SembWever edited comment on CASSANDRA-6332 at 2/10/14 9:06 AM:
---

being a dev environment it's pretty much an open playground so it could well 
have been that without us knowing about it.
  (i've been away the past 2 months but will try and chase up if this was the 
case…)


update:
yes a table of the same name was dropped and then created again with a 
different definition.
this happened in a timeframe of 15 minutes or less…


was (Author: michaelsembwever):
being a dev environment it's pretty much an open playground so it could well 
have been that without us knowing about it.
  (i've been away the past 2 months but will try and chase up if this was the 
case…)

 Cassandra startup failure:  java.util.concurrent.ExecutionException: 
 java.lang.RuntimeException: 706167655f74616773 is not defined as a collection
 --

 Key: CASSANDRA-6332
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6332
 Project: Cassandra
  Issue Type: Bug
 Environment: Ubuntu 12.04
 Cassandra 2.0.1
Reporter: Prateek
Priority: Critical

 The cassandra node fails to startup with the following error message. This is 
 currently impacting availability of our production cluster so your quick 
 response is highly appreciated.
 ERROR 22:58:26,046 Exception encountered during startup
 java.lang.RuntimeException: java.util.concurrent.ExecutionException: 
 java.lang.RuntimeException: 706167655f74616773 is not defined as a collection
 at 
 org.apache.cassandra.utils.FBUtilities.waitOnFuture(FBUtilities.java:411)
 at 
 org.apache.cassandra.utils.FBUtilities.waitOnFutures(FBUtilities.java:400)
 at 
 org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:273)
 at 
 org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:96)
 at 
 org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:146)
 at 
 org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:126)
 at 
 org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:299)
 at 
 org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:442)
 at 
 org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:485)
 Caused by: java.util.concurrent.ExecutionException: 
 java.lang.RuntimeException: 706167655f74616773 is not defined as a collection
 at java.util.concurrent.FutureTask.report(FutureTask.java:122)
 at java.util.concurrent.FutureTask.get(FutureTask.java:188)
 at 
 org.apache.cassandra.utils.FBUtilities.waitOnFuture(FBUtilities.java:407)
 ... 8 more
 Caused by: java.lang.RuntimeException: 706167655f74616773 is not defined as a 
 collection
 at 
 org.apache.cassandra.db.marshal.ColumnToCollectionType.compareCollectionMembers(ColumnToCollectionType.java:72)
 at 
 org.apache.cassandra.db.marshal.AbstractCompositeType.compare(AbstractCompositeType.java:85)
 at 
 org.apache.cassandra.db.marshal.AbstractCompositeType.compare(AbstractCompositeType.java:35)
 at 
 edu.stanford.ppl.concurrent.SnapTreeMap$1.compareTo(SnapTreeMap.java:538)
 at 
 edu.stanford.ppl.concurrent.SnapTreeMap.attemptUpdate(SnapTreeMap.java:1108)
 at 
 edu.stanford.ppl.concurrent.SnapTreeMap.attemptUpdate(SnapTreeMap.java:1192)
 at 
 edu.stanford.ppl.concurrent.SnapTreeMap.updateUnderRoot(SnapTreeMap.java:1059)
 at 
 edu.stanford.ppl.concurrent.SnapTreeMap.update(SnapTreeMap.java:1023)
 at 
 edu.stanford.ppl.concurrent.SnapTreeMap.putIfAbsent(SnapTreeMap.java:985)
 at 
 org.apache.cassandra.db.AtomicSortedColumns$Holder.addColumn(AtomicSortedColumns.java:323)
 at 
 org.apache.cassandra.db.AtomicSortedColumns.addAllWithSizeDelta(AtomicSortedColumns.java:195)
 at org.apache.cassandra.db.Memtable.resolve(Memtable.java:196)
 at org.apache.cassandra.db.Memtable.put(Memtable.java:160)
 at 
 org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:842)
 at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:373)
 at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:338)
 at 
 org.apache.cassandra.db.commitlog.CommitLogReplayer$1.runMayThrow(CommitLogReplayer.java:265)



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CASSANDRA-6684) Count fails with Illegal Capacity: -1


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896340#comment-13896340
 ] 

Ilya Kramer commented on CASSANDRA-6684:


I can confirm, this is fixed on 2.0.5, thanks

 Count fails with Illegal Capacity: -1
 -

 Key: CASSANDRA-6684
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6684
 Project: Cassandra
  Issue Type: Bug
 Environment: Ubuntu(multiple versions, 12.04 LTS and 13.04)
Reporter: Ilya Kramer
 Fix For: 2.0.5

 Attachments: import.py, prow2


 Whenever I try to count a row key which has exactly 3072(don't have a clue 
 what special about that number) columns, I get the exception 'Illegal 
 Capacity: -1'
 When I remove or add a single column the count work as expected.
 I'll attach a small script to replicate, as well as the data of the failed to 
 count row.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (CASSANDRA-6684) Count fails with Illegal Capacity: -1


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-6684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ilya Kramer updated CASSANDRA-6684:
---

Fix Version/s: 2.0.5

 Count fails with Illegal Capacity: -1
 -

 Key: CASSANDRA-6684
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6684
 Project: Cassandra
  Issue Type: Bug
 Environment: Ubuntu(multiple versions, 12.04 LTS and 13.04)
Reporter: Ilya Kramer
 Fix For: 2.0.5

 Attachments: import.py, prow2


 Whenever I try to count a row key which has exactly 3072(don't have a clue 
 what special about that number) columns, I get the exception 'Illegal 
 Capacity: -1'
 When I remove or add a single column the count work as expected.
 I'll attach a small script to replicate, as well as the data of the failed to 
 count row.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CASSANDRA-6467) Hadoop CQL3 example is throwing an Exception

2014-02-10 Thread Mark Moes (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896377#comment-13896377
 ] 

Mark Moes commented on CASSANDRA-6467:
--

I would like to know more about the status of this Bug. Seeing that it was 
moved from 2.0.3 to 2.0.5 and there does not appear to be progression in 
solving it, is it likely that it will be fixed in the 2.0.6 release?

 Hadoop CQL3 example is throwing an Exception
 

 Key: CASSANDRA-6467
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6467
 Project: Cassandra
  Issue Type: Bug
  Components: Hadoop
 Environment: Ubuntu 12.04
Reporter: Parth Patil
 Fix For: 2.0.6


 I am trying to run the Hadoop CQL3 example as per the instructions on this 
 page 
 https://github.com/apache/cassandra/tree/trunk/examples/hadoop_cql3_word_count
 I cloned the cassandra repo from gihub, switched to branch cassandra-2.0 and 
 followed the instructions for building and running cassandra. Then I built 
 and ran the hadoop cql3 example and I am getting an exception as shown the 
 gist below. I did not make any changes to the code after cloning the repo.
 https://gist.github.com/parth-patil/7864738



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CASSANDRA-5732) Can not query secondary index

2014-02-10 Thread Jeremy Hanna (JIRA)

[
https://issues.apache.org/jira/browse/CASSANDRA-5732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896378#comment-13896378
]

Jeremy Hanna commented on CASSANDRA-5732:
-

FWIW, appears to also be a problem in Cassandra 1.1.

Can not query secondary index
-

Key: CASSANDRA-5732
URL: https://issues.apache.org/jira/browse/CASSANDRA-5732
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.5
Environment: Windows 8, Jre 1.6.0_45 32-bit
Reporter: Tony Anecito
Assignee: Sam Tunnicliffe
Fix For: 1.2.11, 2.0.2

Attachments: 5732-1.2, 5732-v2.txt, 5732-v3.txt

Noticed after taking a column family that already existed and assigning to an
IntegerType index_type:KEYS and the caching was already set to 'ALL' that the
prepared statement do not return rows neither did it throw an exception. Here
is the sequence.
1. Starting state query running with caching off for a Column Family with the
query using the secondary index for te WHERE clause.
2, Set Column Family caching to ALL using Cassandra-CLI and update CQL.
Cassandra-cli Describe shows column family caching set to ALL
3. Rerun query and it works.
4. Restart Cassandra and run query and no rows returned. Cassandra-cli
Describe shows column family caching set to ALL
5. Set Column Family caching to NONE using Cassandra-cli and update CQL.
Rerun query and no rows returned. Cassandra-cli Describe for column family
shows caching set to NONE.
6. Restart Cassandra. Rerun query and it is working again. We are now back to
the starting state.
Best Regards,
-Tony

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (CASSANDRA-5732) Can not query secondary index

2014-02-10 Thread Jeremy Hanna (JIRA)

[
https://issues.apache.org/jira/browse/CASSANDRA-5732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Jeremy Hanna updated CASSANDRA-5732:

Reproduced In: 1.1.9

Can not query secondary index
-

Attachments: 5732-1.2, 5732-v2.txt, 5732-v3.txt

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Comment Edited] (CASSANDRA-6467) Hadoop CQL3 example is throwing an Exception

2014-02-10 Thread Mark Moes (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896377#comment-13896377
 ] 

Mark Moes edited comment on CASSANDRA-6467 at 2/10/14 10:10 AM:


I would like to know more about the status of this Bug. Seeing that it was 
moved from 2.0.3 to 2.0.5 and there does not appear to be progression in 
solving it, is it likely that it will be fixed in the 2.0.6 release?

Edit: experiencing the problem in CentOS 6


was (Author: mark moes):
I would like to know more about the status of this Bug. Seeing that it was 
moved from 2.0.3 to 2.0.5 and there does not appear to be progression in 
solving it, is it likely that it will be fixed in the 2.0.6 release?

 Hadoop CQL3 example is throwing an Exception
 

 Key: CASSANDRA-6467
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6467
 Project: Cassandra
  Issue Type: Bug
  Components: Hadoop
 Environment: Ubuntu 12.04
Reporter: Parth Patil
 Fix For: 2.0.6


 I am trying to run the Hadoop CQL3 example as per the instructions on this 
 page 
 https://github.com/apache/cassandra/tree/trunk/examples/hadoop_cql3_word_count
 I cloned the cassandra repo from gihub, switched to branch cassandra-2.0 and 
 followed the instructions for building and running cassandra. Then I built 
 and ran the hadoop cql3 example and I am getting an exception as shown the 
 gist below. I did not make any changes to the code after cloning the repo.
 https://gist.github.com/parth-patil/7864738



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CASSANDRA-6475) Control nodetool history logging directory

2014-02-10 Thread JIRA


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896419#comment-13896419
 ] 

Clément Lardeur commented on CASSANDRA-6475:


Why the user_home is setted on the root directory '/' ?

Have you just tried to launch the CLI or Nodetool with :
{{./nodetool -Duser.home=dir_path ...}}

For example  {{-Duser.home=/tmp}}.

 Control nodetool history logging directory
 --

 Key: CASSANDRA-6475
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6475
 Project: Cassandra
  Issue Type: New Feature
  Components: Tools
Reporter: Brian Nixon
Priority: Trivial
  Labels: lhf

 Nodetool history is logged to a directory based on the current user home. 
 This leads to splintering of history with more than one user and, in one 
 case, a failure to run any nodetool commands as the user did not have write 
 access to their home directory.
 Suggested fix is to make the base directory for the history logging (both 
 nodetool and cli) configurable. A way to disable the logging of these tools 
 would also help.
 Reference:
 https://issues.apache.org/jira/browse/CASSANDRA-5823



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (CASSANDRA-6679) CleanupTest occasional failure in 1.2

2014-02-10 Thread Marcus Eriksson (JIRA)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-6679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcus Eriksson updated CASSANDRA-6679:
---

Attachment: 0001-Fix-CleanupTest.patch

With Java7, testCleanupWithIndexes() is run before testCleanup(), putting 
tokens in TokenMetadata making the local range [01,02), testCleanup then adds a 
random token, making the local range [01, random), and sometimes the new 
local range does not cover the data inserted.

Fix attached to clear TMD before running the test.

 CleanupTest occasional failure in 1.2
 -

 Key: CASSANDRA-6679
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6679
 Project: Cassandra
  Issue Type: Test
  Components: Tests
 Environment: Debian Stable (Wheezy) amd64
 Oracle JVM 1.7.0_51-b13
Reporter: Michael Shuler
Assignee: Marcus Eriksson
Priority: Minor
 Attachments: 0001-Fix-CleanupTest.patch, system.log


 {noformat}
 test:
  [echo] running unit tests
 [junit] WARNING: multiple versions of ant detected in path for junit
 [junit]  
 jar:file:/usr/share/ant/lib/ant.jar!/org/apache/tools/ant/Project.class
 [junit]  and 
 jar:file:/home/mshuler/git/cassandra/build/lib/jars/ant-1.6.5.jar!/org/apache/tools/ant/Project.class
 [junit] Testsuite: org.apache.cassandra.db.CleanupTest
 [junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 6.508 sec
 [junit]
 [junit] - Standard Error -
 [junit]  WARN 15:27:11,566 No host ID found, created 
 e8a8a37c-56c5-49d5-8260-7a3dfc2174a7 (Note: This should happen exactly once 
 per node).
 [junit]  WARN 15:27:11,655 Generated random token 
 [0850c6b26994617235bec220dd17a6d6]. Random tokens will result in an 
 unbalanced ring; see http://wiki.apache.org/cassandra/Operations
 [junit] -  ---
 [junit] Testcase: testCleanup(org.apache.cassandra.db.CleanupTest): FAILED
 [junit] null
 [junit] junit.framework.AssertionFailedError
 [junit] at 
 org.apache.cassandra.db.CleanupTest.testCleanup(CleanupTest.java:87)
 [junit]
 [junit]
 [junit] Test org.apache.cassandra.db.CleanupTest FAILED
 BUILD FAILED
 {noformat}
 - loop through CleanupTest unit test 
 (https://issues.apache.org/jira/secure/attachment/12627493/test.sh)
 - system.log from failed test attached



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (CASSANDRA-6685) Nodes never bootstrap if schema is empty


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-6685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard Low updated CASSANDRA-6685:
---

Description: 
Since 1.2.15, bootstrap never completes if the schema is empty. The 
bootstrapping node endlessly prints:

bq. {{INFO 12:37:44,863 JOINING: waiting for schema information to complete}}

until you add something to the schema (i.e. create a keyspace).

The problem looks to be caused by CASSANDRA-6648, where 
MigrationManager.isReadForBootstrap() was changed to:

bq. {{return Schema.instance.getVersion() != null  
!Schema.emptyVersion.equals(Schema.instance.getVersion());}}

This is wrong since 
{{Schema.emptyVersion.equals(Schema.instance.getVersion())}} is always true if 
there is no schema.

We need some different logic for determining when the schema is propagated.

I haven't tested, but I expect this issue appears in 2.0.5 too.

  was:
Since 1.2.15, bootstrap never completes if the schema is empty. The 
bootstrapping node endlessly prints:

 INFO 12:37:44,863 JOINING: waiting for schema information to complete

until you add something to the schema (i.e. create a keyspace).

The problem looks to be caused by CASSANDRA-6648, where 
MigrationManager.isReadForBootstrap() was changed to:

{{return Schema.instance.getVersion() != null  
!Schema.emptyVersion.equals(Schema.instance.getVersion());}}

This is wrong since 
{{Schema.emptyVersion.equals(Schema.instance.getVersion())}} is always true if 
there is no schema.

We need some different logic for determining when the schema is propagated.

I haven't tested, but I expect this issue appears in 2.0.5 too.


 Nodes never bootstrap if schema is empty
 

 Key: CASSANDRA-6685
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6685
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Richard Low

 Since 1.2.15, bootstrap never completes if the schema is empty. The 
 bootstrapping node endlessly prints:
 bq. {{INFO 12:37:44,863 JOINING: waiting for schema information to complete}}
 until you add something to the schema (i.e. create a keyspace).
 The problem looks to be caused by CASSANDRA-6648, where 
 MigrationManager.isReadForBootstrap() was changed to:
 bq. {{return Schema.instance.getVersion() != null  
 !Schema.emptyVersion.equals(Schema.instance.getVersion());}}
 This is wrong since 
 {{Schema.emptyVersion.equals(Schema.instance.getVersion())}} is always true 
 if there is no schema.
 We need some different logic for determining when the schema is propagated.
 I haven't tested, but I expect this issue appears in 2.0.5 too.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (CASSANDRA-6685) Nodes never bootstrap if schema is empty

Richard Low created CASSANDRA-6685:
--

 Summary: Nodes never bootstrap if schema is empty
 Key: CASSANDRA-6685
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6685
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Richard Low


Since 1.2.15, bootstrap never completes if the schema is empty. The 
bootstrapping node endlessly prints:

 INFO 12:37:44,863 JOINING: waiting for schema information to complete

until you add something to the schema (i.e. create a keyspace).

The problem looks to be caused by CASSANDRA-6648, where 
MigrationManager.isReadForBootstrap() was changed to:

{{return Schema.instance.getVersion() != null  
!Schema.emptyVersion.equals(Schema.instance.getVersion());}}

This is wrong since 
{{Schema.emptyVersion.equals(Schema.instance.getVersion())}} is always true if 
there is no schema.

We need some different logic for determining when the schema is propagated.

I haven't tested, but I expect this issue appears in 2.0.5 too.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CASSANDRA-6683) BADNESS_THRESHOLD does not working correctly with DynamicEndpointSnitch

2014-02-10 Thread Chris Burroughs (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896462#comment-13896462
 ] 

Chris Burroughs commented on CASSANDRA-6683:


Earlier DES problems reported in CASSANDRA-6465

 BADNESS_THRESHOLD does not working correctly with DynamicEndpointSnitch
 ---

 Key: CASSANDRA-6683
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6683
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: Linux 3.8.0-33-generic
Reporter: Kirill Bogdanov
  Labels: snitch
 Fix For: 2.0.5


 There is a problem in *DynamicEndpointSnitch.java* in 
 sortByProximityWithBadness()
 Before calling sortByProximityWithScore we comparing each nodes score ratios 
 to the badness threshold.
 {code}
 if ((first - next) / first   BADNESS_THRESHOLD)
 {
 sortByProximityWithScore(address, addresses);
 return;
 }
 {code}
 This is not always the correct comparison because *first* score can be less 
 than *next*  score and in that case we will compare a negative number with 
 positive.
 The solution is to compute absolute value of the ratio:
 {code}
 if (Math.abs((first - next) / first)  BADNESS_THRESHOLD)
 {code}
 This issue causing an incorrect sorting of DCs based on their performance and 
 affects performance of the snitch.
 Thanks.
  



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CASSANDRA-6572) Workload recording / playback

2014-02-10 Thread Lyuben Todorov (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896580#comment-13896580
 ] 

Lyuben Todorov commented on CASSANDRA-6572:
---

Just a though, do we want to ignore queries on system/trace tables? Such 
queries might make users wonder users as to why they did 30 inserts (assuming 
they record every query) but their log shows 34 queries. It will be fairly 
clear when they look at the log, but its worth considering. 

 Workload recording / playback
 -

 Key: CASSANDRA-6572
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6572
 Project: Cassandra
  Issue Type: New Feature
  Components: Core, Tools
Reporter: Jonathan Ellis
Assignee: Lyuben Todorov
 Fix For: 2.0.6


 Write sample mode gets us part way to testing new versions against a real 
 world workload, but we need an easy way to test the query side as well.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (CASSANDRA-4911) Lift limitation that order by columns must be selected for IN queries


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-4911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Ellis updated CASSANDRA-4911:
--

   Reviewer: Aleksey Yeschenko
Component/s: API

 Lift limitation that order by columns must be selected for IN queries
 -

 Key: CASSANDRA-4911
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4911
 Project: Cassandra
  Issue Type: Improvement
  Components: API
Affects Versions: 1.2.0 beta 1
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
 Fix For: 2.1

 Attachments: 4911.txt


 This is the followup of CASSANDRA-4645. We should remove the limitation that 
 for IN queries, you must have columns on which you have an ORDER BY in the 
 select clause.
 For that, we'll need to automatically add the columns on which we have an 
 ORDER BY to the one queried internally, and remove it afterwards (once the 
 sorting is done) from the resultSet.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (CASSANDRA-6663) Connecting to a Raspberry PI Cassandra Cluster crashes the node being connected to

2014-02-10 Thread Aleksey Yeschenko (JIRA)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-6663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksey Yeschenko resolved CASSANDRA-6663.
--

Resolution: Invalid

 Connecting to a Raspberry PI Cassandra Cluster crashes the node being 
 connected to
 --

 Key: CASSANDRA-6663
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6663
 Project: Cassandra
  Issue Type: Bug
  Components: Drivers (now out of tree)
 Environment: 4x node Raspberry PI cluster
 Macbook running Idle 2.7
Reporter: ian mccrae
 Attachments: Python Client Log.txt, hs_err_pid6327.log


 I have a working 4x node Raspberry Pi cluster and
 # DevCenter happily connects to this (...which has an option to turn Snappy 
 compression off)
 # ...however the Python Driver fails to connect and crashes the node being 
 connected to with the errors in the error-log below.
 There appears to be a problem with Snappy compression (not supported on the 
 Raspberry Pi).  So I also tried compression = None with the same result.
 How might I fix this?
 *Python Code*
 {noformat}
  from cassandra.cluster import Cluster
  cluster = Cluster(['192.168.200.151'], compression = None)
  session = cluster.connect()
 {noformat}
 *Error Log*
 {noformat}
 Traceback (most recent call last):
   File pyshell#58, line 1, in module
 session = cluster.connect()
   File 
 /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/cassandra/cluster.py,
  line 471, in connect
 self.control_connection.connect()
   File 
 /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/cassandra/cluster.py,
  line 1351, in connect
 self._set_new_connection(self._reconnect_internal())
   File 
 /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/cassandra/cluster.py,
  line 1386, in _reconnect_internal
 raise NoHostAvailable(Unable to connect to any servers, errors)
 NoHostAvailable: ('Unable to connect to any servers', {'192.168.200.151': 
 ConnectionShutdown('Connection to 192.168.200.151 is closed',))
 {noformat}
 *A Dump of the cluster class attributes*
 {noformat}
  pprint(vars(cluster))
 {'_core_connections_per_host': {0: 2, 1: 1},
  '_is_setup': True,
  '_is_shutdown': True,
  '_listener_lock': thread.lock object at 0x10616d230,
  '_listeners': set([]),
  '_lock': _RLock owner=None count=0,
  '_max_connections_per_host': {0: 8, 1: 2},
  '_max_requests_per_connection': {0: 100, 1: 100},
  '_min_requests_per_connection': {0: 5, 1: 5},
  '_prepared_statements': WeakValueDictionary at 4396942904,
  'compression': None,
  'contact_points': ['192.168.200.151'],
  'control_connection': cassandra.cluster.ControlConnection object at 
 0x106168cd0,
  'control_connection_timeout': 2.0,
  'cql_version': None,
  'executor': concurrent.futures.thread.ThreadPoolExecutor object at 
 0x106148410,
  'load_balancing_policy': cassandra.policies.RoundRobinPolicy object at 
 0x104adae50,
  'max_schema_agreement_wait': 10,
  'metadata': cassandra.metadata.Metadata object at 0x1061481d0,
  'metrics_enabled': False,
  'port': 9042,
  'scheduler': cassandra.cluster._Scheduler object at 0x106148550,
  'sessions': _weakrefset.WeakSet object at 0x106148750,
  'sockopts': None,
  'ssl_options': None}
 
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CASSANDRA-6685) Nodes never bootstrap if schema is empty


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896621#comment-13896621
 ] 

Brandon Williams commented on CASSANDRA-6685:
-

Luckily bootstrapping without schema isn't a huge problem or very common, but I 
propose fixing this by reverting the change in question, since that puts 
everything back the way it was except for moving the MM events, which solved 
CASSANDRA-6648.

 Nodes never bootstrap if schema is empty
 

 Key: CASSANDRA-6685
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6685
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Richard Low

 Since 1.2.15, bootstrap never completes if the schema is empty. The 
 bootstrapping node endlessly prints:
 bq. {{INFO 12:37:44,863 JOINING: waiting for schema information to complete}}
 until you add something to the schema (i.e. create a keyspace).
 The problem looks to be caused by CASSANDRA-6648, where 
 MigrationManager.isReadForBootstrap() was changed to:
 bq. {{return Schema.instance.getVersion() != null  
 !Schema.emptyVersion.equals(Schema.instance.getVersion());}}
 This is wrong since 
 {{Schema.emptyVersion.equals(Schema.instance.getVersion())}} is always true 
 if there is no schema.
 We need some different logic for determining when the schema is propagated.
 I haven't tested, but I expect this issue appears in 2.0.5 too.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CASSANDRA-6685) Nodes never bootstrap if schema is empty


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896624#comment-13896624
 ] 

Richard Low commented on CASSANDRA-6685:


I tested and this isn't reproduced in 2.0.5, because the system_traces keyspace 
is added to the schema, but it appears to be added differently in 1.2.x so 
doesn't modify the schema ID.

 Nodes never bootstrap if schema is empty
 

 Key: CASSANDRA-6685
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6685
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Richard Low

 Since 1.2.15, bootstrap never completes if the schema is empty. The 
 bootstrapping node endlessly prints:
 bq. {{INFO 12:37:44,863 JOINING: waiting for schema information to complete}}
 until you add something to the schema (i.e. create a keyspace).
 The problem looks to be caused by CASSANDRA-6648, where 
 MigrationManager.isReadForBootstrap() was changed to:
 bq. {{return Schema.instance.getVersion() != null  
 !Schema.emptyVersion.equals(Schema.instance.getVersion());}}
 This is wrong since 
 {{Schema.emptyVersion.equals(Schema.instance.getVersion())}} is always true 
 if there is no schema.
 We need some different logic for determining when the schema is propagated.
 I haven't tested, but I expect this issue appears in 2.0.5 too.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CASSANDRA-6332) Cassandra startup failure: java.util.concurrent.ExecutionException: java.lang.RuntimeException: 706167655f74616773 is not defined as a collection


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896625#comment-13896625
 ] 

Jonathan Ellis commented on CASSANDRA-6332:
---

Thanks for the followup.  That will be fixed by CASSANDRA-5202.

 Cassandra startup failure:  java.util.concurrent.ExecutionException: 
 java.lang.RuntimeException: 706167655f74616773 is not defined as a collection
 --

 Key: CASSANDRA-6332
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6332
 Project: Cassandra
  Issue Type: Bug
 Environment: Ubuntu 12.04
 Cassandra 2.0.1
Reporter: Prateek
Priority: Critical

 The cassandra node fails to startup with the following error message. This is 
 currently impacting availability of our production cluster so your quick 
 response is highly appreciated.
 ERROR 22:58:26,046 Exception encountered during startup
 java.lang.RuntimeException: java.util.concurrent.ExecutionException: 
 java.lang.RuntimeException: 706167655f74616773 is not defined as a collection
 at 
 org.apache.cassandra.utils.FBUtilities.waitOnFuture(FBUtilities.java:411)
 at 
 org.apache.cassandra.utils.FBUtilities.waitOnFutures(FBUtilities.java:400)
 at 
 org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:273)
 at 
 org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:96)
 at 
 org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:146)
 at 
 org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:126)
 at 
 org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:299)
 at 
 org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:442)
 at 
 org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:485)
 Caused by: java.util.concurrent.ExecutionException: 
 java.lang.RuntimeException: 706167655f74616773 is not defined as a collection
 at java.util.concurrent.FutureTask.report(FutureTask.java:122)
 at java.util.concurrent.FutureTask.get(FutureTask.java:188)
 at 
 org.apache.cassandra.utils.FBUtilities.waitOnFuture(FBUtilities.java:407)
 ... 8 more
 Caused by: java.lang.RuntimeException: 706167655f74616773 is not defined as a 
 collection
 at 
 org.apache.cassandra.db.marshal.ColumnToCollectionType.compareCollectionMembers(ColumnToCollectionType.java:72)
 at 
 org.apache.cassandra.db.marshal.AbstractCompositeType.compare(AbstractCompositeType.java:85)
 at 
 org.apache.cassandra.db.marshal.AbstractCompositeType.compare(AbstractCompositeType.java:35)
 at 
 edu.stanford.ppl.concurrent.SnapTreeMap$1.compareTo(SnapTreeMap.java:538)
 at 
 edu.stanford.ppl.concurrent.SnapTreeMap.attemptUpdate(SnapTreeMap.java:1108)
 at 
 edu.stanford.ppl.concurrent.SnapTreeMap.attemptUpdate(SnapTreeMap.java:1192)
 at 
 edu.stanford.ppl.concurrent.SnapTreeMap.updateUnderRoot(SnapTreeMap.java:1059)
 at 
 edu.stanford.ppl.concurrent.SnapTreeMap.update(SnapTreeMap.java:1023)
 at 
 edu.stanford.ppl.concurrent.SnapTreeMap.putIfAbsent(SnapTreeMap.java:985)
 at 
 org.apache.cassandra.db.AtomicSortedColumns$Holder.addColumn(AtomicSortedColumns.java:323)
 at 
 org.apache.cassandra.db.AtomicSortedColumns.addAllWithSizeDelta(AtomicSortedColumns.java:195)
 at org.apache.cassandra.db.Memtable.resolve(Memtable.java:196)
 at org.apache.cassandra.db.Memtable.put(Memtable.java:160)
 at 
 org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:842)
 at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:373)
 at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:338)
 at 
 org.apache.cassandra.db.commitlog.CommitLogReplayer$1.runMayThrow(CommitLogReplayer.java:265)



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CASSANDRA-6679) CleanupTest occasional failure in 1.2


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896628#comment-13896628
 ] 

Jonathan Ellis commented on CASSANDRA-6679:
---

+1

 CleanupTest occasional failure in 1.2
 -

 Key: CASSANDRA-6679
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6679
 Project: Cassandra
  Issue Type: Test
  Components: Tests
 Environment: Debian Stable (Wheezy) amd64
 Oracle JVM 1.7.0_51-b13
Reporter: Michael Shuler
Assignee: Marcus Eriksson
Priority: Minor
 Attachments: 0001-Fix-CleanupTest.patch, system.log


 {noformat}
 test:
  [echo] running unit tests
 [junit] WARNING: multiple versions of ant detected in path for junit
 [junit]  
 jar:file:/usr/share/ant/lib/ant.jar!/org/apache/tools/ant/Project.class
 [junit]  and 
 jar:file:/home/mshuler/git/cassandra/build/lib/jars/ant-1.6.5.jar!/org/apache/tools/ant/Project.class
 [junit] Testsuite: org.apache.cassandra.db.CleanupTest
 [junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 6.508 sec
 [junit]
 [junit] - Standard Error -
 [junit]  WARN 15:27:11,566 No host ID found, created 
 e8a8a37c-56c5-49d5-8260-7a3dfc2174a7 (Note: This should happen exactly once 
 per node).
 [junit]  WARN 15:27:11,655 Generated random token 
 [0850c6b26994617235bec220dd17a6d6]. Random tokens will result in an 
 unbalanced ring; see http://wiki.apache.org/cassandra/Operations
 [junit] -  ---
 [junit] Testcase: testCleanup(org.apache.cassandra.db.CleanupTest): FAILED
 [junit] null
 [junit] junit.framework.AssertionFailedError
 [junit] at 
 org.apache.cassandra.db.CleanupTest.testCleanup(CleanupTest.java:87)
 [junit]
 [junit]
 [junit] Test org.apache.cassandra.db.CleanupTest FAILED
 BUILD FAILED
 {noformat}
 - loop through CleanupTest unit test 
 (https://issues.apache.org/jira/secure/attachment/12627493/test.sh)
 - system.log from failed test attached



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CASSANDRA-6683) BADNESS_THRESHOLD does not working correctly with DynamicEndpointSnitch


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896632#comment-13896632
 ] 

Brandon Williams commented on CASSANDRA-6683:
-

I don't think this should happen after CASSANDRA-6465, wdyt [~thobbs]?

 BADNESS_THRESHOLD does not working correctly with DynamicEndpointSnitch
 ---

 Key: CASSANDRA-6683
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6683
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: Linux 3.8.0-33-generic
Reporter: Kirill Bogdanov
  Labels: snitch
 Fix For: 2.0.5


 There is a problem in *DynamicEndpointSnitch.java* in 
 sortByProximityWithBadness()
 Before calling sortByProximityWithScore we comparing each nodes score ratios 
 to the badness threshold.
 {code}
 if ((first - next) / first   BADNESS_THRESHOLD)
 {
 sortByProximityWithScore(address, addresses);
 return;
 }
 {code}
 This is not always the correct comparison because *first* score can be less 
 than *next*  score and in that case we will compare a negative number with 
 positive.
 The solution is to compute absolute value of the ratio:
 {code}
 if (Math.abs((first - next) / first)  BADNESS_THRESHOLD)
 {code}
 This issue causing an incorrect sorting of DCs based on their performance and 
 affects performance of the snitch.
 Thanks.
  



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CASSANDRA-6572) Workload recording / playback


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896631#comment-13896631
 ] 

Jonathan Ellis commented on CASSANDRA-6572:
---

Yes, we should ignore those (because replaying the log at the same trace 
settings should result in the same load).

 Workload recording / playback
 -

 Key: CASSANDRA-6572
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6572
 Project: Cassandra
  Issue Type: New Feature
  Components: Core, Tools
Reporter: Jonathan Ellis
Assignee: Lyuben Todorov
 Fix For: 2.0.6


 Write sample mode gets us part way to testing new versions against a real 
 world workload, but we need an easy way to test the query side as well.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CASSANDRA-6685) Nodes never bootstrap if schema is empty


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896637#comment-13896637
 ] 

Richard Low commented on CASSANDRA-6685:


Wasn't this change made to guard against the case when schema messages get 
delayed and responses aren't received before bootstrap begins?

 Nodes never bootstrap if schema is empty
 

 Key: CASSANDRA-6685
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6685
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Richard Low

 Since 1.2.15, bootstrap never completes if the schema is empty. The 
 bootstrapping node endlessly prints:
 bq. {{INFO 12:37:44,863 JOINING: waiting for schema information to complete}}
 until you add something to the schema (i.e. create a keyspace).
 The problem looks to be caused by CASSANDRA-6648, where 
 MigrationManager.isReadForBootstrap() was changed to:
 bq. {{return Schema.instance.getVersion() != null  
 !Schema.emptyVersion.equals(Schema.instance.getVersion());}}
 This is wrong since 
 {{Schema.emptyVersion.equals(Schema.instance.getVersion())}} is always true 
 if there is no schema.
 We need some different logic for determining when the schema is propagated.
 I haven't tested, but I expect this issue appears in 2.0.5 too.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CASSANDRA-6685) Nodes never bootstrap if schema is empty


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896648#comment-13896648
 ] 

Richard Low commented on CASSANDRA-6685:


Also I think the use case of bootstrapping without a schema is quite common 
when setting up a new cluster. For more than a few nodes, people won't list all 
nodes as a seed and, with this issue, non-seed nodes won't join until a 
keyspace is created.

 Nodes never bootstrap if schema is empty
 

 Key: CASSANDRA-6685
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6685
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Richard Low

 Since 1.2.15, bootstrap never completes if the schema is empty. The 
 bootstrapping node endlessly prints:
 bq. {{INFO 12:37:44,863 JOINING: waiting for schema information to complete}}
 until you add something to the schema (i.e. create a keyspace).
 The problem looks to be caused by CASSANDRA-6648, where 
 MigrationManager.isReadForBootstrap() was changed to:
 bq. {{return Schema.instance.getVersion() != null  
 !Schema.emptyVersion.equals(Schema.instance.getVersion());}}
 This is wrong since 
 {{Schema.emptyVersion.equals(Schema.instance.getVersion())}} is always true 
 if there is no schema.
 We need some different logic for determining when the schema is propagated.
 I haven't tested, but I expect this issue appears in 2.0.5 too.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CASSANDRA-6685) Nodes never bootstrap if schema is empty


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896657#comment-13896657
 ] 

Brandon Williams commented on CASSANDRA-6685:
-

bq. Wasn't this change made to guard against the case when schema messages get 
delayed and responses aren't received before bootstrap begins?

It was an extra guard, which is apparently slightly flawed.  The heart of the 
problem in 6648 was the event to check if pulling was needing firing too early, 
and not pulling because the remote node was known to be part of the ring yet 
and thus considered a fat client.

bq. For more than a few nodes, people won't list all nodes as a seed and, with 
this issue, non-seed nodes won't join until a keyspace is created.

{noformat}auto_bootstrap = false{noformat} will not only solve this, but also 
skip the ring delay sleep and be much faster.


 Nodes never bootstrap if schema is empty
 

 Key: CASSANDRA-6685
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6685
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Richard Low

 Since 1.2.15, bootstrap never completes if the schema is empty. The 
 bootstrapping node endlessly prints:
 bq. {{INFO 12:37:44,863 JOINING: waiting for schema information to complete}}
 until you add something to the schema (i.e. create a keyspace).
 The problem looks to be caused by CASSANDRA-6648, where 
 MigrationManager.isReadForBootstrap() was changed to:
 bq. {{return Schema.instance.getVersion() != null  
 !Schema.emptyVersion.equals(Schema.instance.getVersion());}}
 This is wrong since 
 {{Schema.emptyVersion.equals(Schema.instance.getVersion())}} is always true 
 if there is no schema.
 We need some different logic for determining when the schema is propagated.
 I haven't tested, but I expect this issue appears in 2.0.5 too.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CASSANDRA-6685) Nodes never bootstrap if schema is empty


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896685#comment-13896685
 ] 

Richard Low commented on CASSANDRA-6685:


OK, +1 on your proposed fix then.

Agreed auto_bootstrap is a workaround for the new cluster case.

 Nodes never bootstrap if schema is empty
 

 Key: CASSANDRA-6685
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6685
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Richard Low

 Since 1.2.15, bootstrap never completes if the schema is empty. The 
 bootstrapping node endlessly prints:
 bq. {{INFO 12:37:44,863 JOINING: waiting for schema information to complete}}
 until you add something to the schema (i.e. create a keyspace).
 The problem looks to be caused by CASSANDRA-6648, where 
 MigrationManager.isReadForBootstrap() was changed to:
 bq. {{return Schema.instance.getVersion() != null  
 !Schema.emptyVersion.equals(Schema.instance.getVersion());}}
 This is wrong since 
 {{Schema.emptyVersion.equals(Schema.instance.getVersion())}} is always true 
 if there is no schema.
 We need some different logic for determining when the schema is propagated.
 I haven't tested, but I expect this issue appears in 2.0.5 too.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Comment Edited] (CASSANDRA-6685) Nodes never bootstrap if schema is empty


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896657#comment-13896657
 ] 

Brandon Williams edited comment on CASSANDRA-6685 at 2/10/14 3:26 PM:
--

bq. Wasn't this change made to guard against the case when schema messages get 
delayed and responses aren't received before bootstrap begins?

It was an extra guard, which is apparently slightly flawed.  The heart of the 
problem in 6648 was the event to check if pulling was needed firing too early, 
and not pulling because the remote node was not known to be part of the ring 
yet and thus considered a fat client.

bq. For more than a few nodes, people won't list all nodes as a seed and, with 
this issue, non-seed nodes won't join until a keyspace is created.

{noformat}auto_bootstrap = false{noformat} will not only solve this, but also 
skip the ring delay sleep and be much faster.



was (Author: brandon.williams):
bq. Wasn't this change made to guard against the case when schema messages get 
delayed and responses aren't received before bootstrap begins?

It was an extra guard, which is apparently slightly flawed.  The heart of the 
problem in 6648 was the event to check if pulling was needing firing too early, 
and not pulling because the remote node was known to be part of the ring yet 
and thus considered a fat client.

bq. For more than a few nodes, people won't list all nodes as a seed and, with 
this issue, non-seed nodes won't join until a keyspace is created.

{noformat}auto_bootstrap = false{noformat} will not only solve this, but also 
skip the ring delay sleep and be much faster.


 Nodes never bootstrap if schema is empty
 

 Key: CASSANDRA-6685
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6685
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Richard Low

 Since 1.2.15, bootstrap never completes if the schema is empty. The 
 bootstrapping node endlessly prints:
 bq. {{INFO 12:37:44,863 JOINING: waiting for schema information to complete}}
 until you add something to the schema (i.e. create a keyspace).
 The problem looks to be caused by CASSANDRA-6648, where 
 MigrationManager.isReadForBootstrap() was changed to:
 bq. {{return Schema.instance.getVersion() != null  
 !Schema.emptyVersion.equals(Schema.instance.getVersion());}}
 This is wrong since 
 {{Schema.emptyVersion.equals(Schema.instance.getVersion())}} is always true 
 if there is no schema.
 We need some different logic for determining when the schema is propagated.
 I haven't tested, but I expect this issue appears in 2.0.5 too.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[2/6] git commit: Partially revert MM.isReadyForBootstrap change from 6648 Patch by brandonwilliams, reviewed by Richard Low for CASSANDRA-6685

Partially revert MM.isReadyForBootstrap change from 6648
Patch by brandonwilliams, reviewed by Richard Low for CASSANDRA-6685


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/c5627008
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/c5627008
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/c5627008

Branch: refs/heads/cassandra-2.0
Commit: c5627008a2c87ab960da98f4d5b8ca4aca6eebdd
Parents: 887558f
Author: Brandon Williams brandonwilli...@apache.org
Authored: Mon Feb 10 09:36:42 2014 -0600
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Mon Feb 10 09:36:42 2014 -0600

--
 src/java/org/apache/cassandra/service/MigrationManager.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/c5627008/src/java/org/apache/cassandra/service/MigrationManager.java
--
diff --git a/src/java/org/apache/cassandra/service/MigrationManager.java 
b/src/java/org/apache/cassandra/service/MigrationManager.java
index fd9eeda..5a02e3b 100644
--- a/src/java/org/apache/cassandra/service/MigrationManager.java
+++ b/src/java/org/apache/cassandra/service/MigrationManager.java
@@ -146,7 +146,7 @@ public class MigrationManager
 
 public static boolean isReadyForBootstrap()
 {
-return Schema.instance.getVersion() != null  
!Schema.emptyVersion.equals(Schema.instance.getVersion());
+return ((ThreadPoolExecutor) 
StageManager.getStage(Stage.MIGRATION)).getActiveCount() == 0;
 }
 
 public void notifyCreateKeyspace(KSMetaData ksm)

[4/6] git commit: Merge branch 'cassandra-1.2' into cassandra-2.0

Merge branch 'cassandra-1.2' into cassandra-2.0


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/b5321d50
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/b5321d50
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/b5321d50

Branch: refs/heads/trunk
Commit: b5321d50bba3733e9dc359714eb658c191ca2975
Parents: 16f99c5 c562700
Author: Brandon Williams brandonwilli...@apache.org
Authored: Mon Feb 10 09:37:43 2014 -0600
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Mon Feb 10 09:37:43 2014 -0600

--
 src/java/org/apache/cassandra/service/MigrationManager.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/b5321d50/src/java/org/apache/cassandra/service/MigrationManager.java
--

[1/6] git commit: Partially revert MM.isReadyForBootstrap change from 6648 Patch by brandonwilliams, reviewed by Richard Low for CASSANDRA-6685

Updated Branches:
  refs/heads/cassandra-1.2 887558f7a - c5627008a
  refs/heads/cassandra-2.0 16f99c5a2 - b5321d50b
  refs/heads/trunk de9be79d5 - 861d9960d


Partially revert MM.isReadyForBootstrap change from 6648
Patch by brandonwilliams, reviewed by Richard Low for CASSANDRA-6685


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/c5627008
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/c5627008
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/c5627008

Branch: refs/heads/cassandra-1.2
Commit: c5627008a2c87ab960da98f4d5b8ca4aca6eebdd
Parents: 887558f
Author: Brandon Williams brandonwilli...@apache.org
Authored: Mon Feb 10 09:36:42 2014 -0600
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Mon Feb 10 09:36:42 2014 -0600

--
 src/java/org/apache/cassandra/service/MigrationManager.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/c5627008/src/java/org/apache/cassandra/service/MigrationManager.java
--
diff --git a/src/java/org/apache/cassandra/service/MigrationManager.java 
b/src/java/org/apache/cassandra/service/MigrationManager.java
index fd9eeda..5a02e3b 100644
--- a/src/java/org/apache/cassandra/service/MigrationManager.java
+++ b/src/java/org/apache/cassandra/service/MigrationManager.java
@@ -146,7 +146,7 @@ public class MigrationManager
 
 public static boolean isReadyForBootstrap()
 {
-return Schema.instance.getVersion() != null  
!Schema.emptyVersion.equals(Schema.instance.getVersion());
+return ((ThreadPoolExecutor) 
StageManager.getStage(Stage.MIGRATION)).getActiveCount() == 0;
 }
 
 public void notifyCreateKeyspace(KSMetaData ksm)

[6/6] git commit: Merge branch 'cassandra-2.0' into trunk

Merge branch 'cassandra-2.0' into trunk


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/861d9960
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/861d9960
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/861d9960

Branch: refs/heads/trunk
Commit: 861d9960d0659a8b77734d448a777c982ff9030b
Parents: de9be79 b5321d5
Author: Brandon Williams brandonwilli...@apache.org
Authored: Mon Feb 10 09:37:56 2014 -0600
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Mon Feb 10 09:37:56 2014 -0600

--
 src/java/org/apache/cassandra/service/MigrationManager.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/861d9960/src/java/org/apache/cassandra/service/MigrationManager.java
--

[5/6] git commit: Merge branch 'cassandra-1.2' into cassandra-2.0

Merge branch 'cassandra-1.2' into cassandra-2.0


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/b5321d50
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/b5321d50
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/b5321d50

Branch: refs/heads/cassandra-2.0
Commit: b5321d50bba3733e9dc359714eb658c191ca2975
Parents: 16f99c5 c562700
Author: Brandon Williams brandonwilli...@apache.org
Authored: Mon Feb 10 09:37:43 2014 -0600
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Mon Feb 10 09:37:43 2014 -0600

--
 src/java/org/apache/cassandra/service/MigrationManager.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/b5321d50/src/java/org/apache/cassandra/service/MigrationManager.java
--

[3/6] git commit: Partially revert MM.isReadyForBootstrap change from 6648 Patch by brandonwilliams, reviewed by Richard Low for CASSANDRA-6685

Partially revert MM.isReadyForBootstrap change from 6648
Patch by brandonwilliams, reviewed by Richard Low for CASSANDRA-6685


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/c5627008
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/c5627008
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/c5627008

Branch: refs/heads/trunk
Commit: c5627008a2c87ab960da98f4d5b8ca4aca6eebdd
Parents: 887558f
Author: Brandon Williams brandonwilli...@apache.org
Authored: Mon Feb 10 09:36:42 2014 -0600
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Mon Feb 10 09:36:42 2014 -0600

--
 src/java/org/apache/cassandra/service/MigrationManager.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/c5627008/src/java/org/apache/cassandra/service/MigrationManager.java
--
diff --git a/src/java/org/apache/cassandra/service/MigrationManager.java 
b/src/java/org/apache/cassandra/service/MigrationManager.java
index fd9eeda..5a02e3b 100644
--- a/src/java/org/apache/cassandra/service/MigrationManager.java
+++ b/src/java/org/apache/cassandra/service/MigrationManager.java
@@ -146,7 +146,7 @@ public class MigrationManager
 
 public static boolean isReadyForBootstrap()
 {
-return Schema.instance.getVersion() != null  
!Schema.emptyVersion.equals(Schema.instance.getVersion());
+return ((ThreadPoolExecutor) 
StageManager.getStage(Stage.MIGRATION)).getActiveCount() == 0;
 }
 
 public void notifyCreateKeyspace(KSMetaData ksm)

[jira] [Resolved] (CASSANDRA-6685) Nodes never bootstrap if schema is empty


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-6685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams resolved CASSANDRA-6685.
-

Resolution: Fixed
  Assignee: Brandon Williams

Committed.

 Nodes never bootstrap if schema is empty
 

 Key: CASSANDRA-6685
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6685
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Richard Low
Assignee: Brandon Williams

 Since 1.2.15, bootstrap never completes if the schema is empty. The 
 bootstrapping node endlessly prints:
 bq. {{INFO 12:37:44,863 JOINING: waiting for schema information to complete}}
 until you add something to the schema (i.e. create a keyspace).
 The problem looks to be caused by CASSANDRA-6648, where 
 MigrationManager.isReadForBootstrap() was changed to:
 bq. {{return Schema.instance.getVersion() != null  
 !Schema.emptyVersion.equals(Schema.instance.getVersion());}}
 This is wrong since 
 {{Schema.emptyVersion.equals(Schema.instance.getVersion())}} is always true 
 if there is no schema.
 We need some different logic for determining when the schema is propagated.
 I haven't tested, but I expect this issue appears in 2.0.5 too.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (CASSANDRA-6685) Nodes never bootstrap if schema is empty


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-6685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-6685:


 Reviewer: Richard Low
Fix Version/s: 1.2.16

 Nodes never bootstrap if schema is empty
 

 Key: CASSANDRA-6685
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6685
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Richard Low
Assignee: Brandon Williams
 Fix For: 1.2.16


 Since 1.2.15, bootstrap never completes if the schema is empty. The 
 bootstrapping node endlessly prints:
 bq. {{INFO 12:37:44,863 JOINING: waiting for schema information to complete}}
 until you add something to the schema (i.e. create a keyspace).
 The problem looks to be caused by CASSANDRA-6648, where 
 MigrationManager.isReadForBootstrap() was changed to:
 bq. {{return Schema.instance.getVersion() != null  
 !Schema.emptyVersion.equals(Schema.instance.getVersion());}}
 This is wrong since 
 {{Schema.emptyVersion.equals(Schema.instance.getVersion())}} is always true 
 if there is no schema.
 We need some different logic for determining when the schema is propagated.
 I haven't tested, but I expect this issue appears in 2.0.5 too.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[1/2] git commit: Fix CleanupTest

Updated Branches:
  refs/heads/cassandra-2.0 b5321d50b - 9a6ae96af


Fix CleanupTest

patch by marcuse, reviewed by jbellis for CASSANDRA-6679


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/4b83a6f9
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/4b83a6f9
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/4b83a6f9

Branch: refs/heads/cassandra-2.0
Commit: 4b83a6f9d9c00fe662ddb9db4533df8b9b96883d
Parents: 887558f
Author: Marcus Eriksson marc...@apache.org
Authored: Mon Feb 10 18:32:06 2014 +0100
Committer: Marcus Eriksson marc...@apache.org
Committed: Mon Feb 10 18:32:06 2014 +0100

--
 test/unit/org/apache/cassandra/db/CleanupTest.java | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/4b83a6f9/test/unit/org/apache/cassandra/db/CleanupTest.java
--
diff --git a/test/unit/org/apache/cassandra/db/CleanupTest.java 
b/test/unit/org/apache/cassandra/db/CleanupTest.java
index 5872407..d5c2b07 100644
--- a/test/unit/org/apache/cassandra/db/CleanupTest.java
+++ b/test/unit/org/apache/cassandra/db/CleanupTest.java
@@ -64,8 +64,7 @@ public class CleanupTest extends SchemaLoader
 @Test
 public void testCleanup() throws IOException, ExecutionException, 
InterruptedException, ConfigurationException
 {
-StorageService.instance.initServer(0);
-
+StorageService.instance.getTokenMetadata().clearUnsafe();
 Table table = Table.open(TABLE1);
 ColumnFamilyStore cfs = table.getColumnFamilyStore(CF2);

[3/3] git commit: Merge branch 'cassandra-2.0' into trunk

Merge branch 'cassandra-2.0' into trunk


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/503a8a86
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/503a8a86
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/503a8a86

Branch: refs/heads/trunk
Commit: 503a8a865ed60b08e6c512c206a295a6a78f2848
Parents: 861d996 9a6ae96
Author: Marcus Eriksson marc...@apache.org
Authored: Mon Feb 10 18:35:41 2014 +0100
Committer: Marcus Eriksson marc...@apache.org
Committed: Mon Feb 10 18:35:41 2014 +0100

--
 test/unit/org/apache/cassandra/db/CleanupTest.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/503a8a86/test/unit/org/apache/cassandra/db/CleanupTest.java
--

git commit: Fix CleanupTest

Updated Branches:
  refs/heads/cassandra-1.2 c5627008a - 1b8b7b540


Fix CleanupTest

patch by marcuse, reviewed by jbellis for CASSANDRA-6679


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/1b8b7b54
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/1b8b7b54
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/1b8b7b54

Branch: refs/heads/cassandra-1.2
Commit: 1b8b7b54087dd2dc2aeb2b9a0b06fbb4f13030be
Parents: c562700
Author: Marcus Eriksson marc...@apache.org
Authored: Mon Feb 10 18:32:06 2014 +0100
Committer: Marcus Eriksson marc...@apache.org
Committed: Mon Feb 10 18:36:28 2014 +0100

--
 test/unit/org/apache/cassandra/db/CleanupTest.java | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/1b8b7b54/test/unit/org/apache/cassandra/db/CleanupTest.java
--
diff --git a/test/unit/org/apache/cassandra/db/CleanupTest.java 
b/test/unit/org/apache/cassandra/db/CleanupTest.java
index 5872407..d5c2b07 100644
--- a/test/unit/org/apache/cassandra/db/CleanupTest.java
+++ b/test/unit/org/apache/cassandra/db/CleanupTest.java
@@ -64,8 +64,7 @@ public class CleanupTest extends SchemaLoader
 @Test
 public void testCleanup() throws IOException, ExecutionException, 
InterruptedException, ConfigurationException
 {
-StorageService.instance.initServer(0);
-
+StorageService.instance.getTokenMetadata().clearUnsafe();
 Table table = Table.open(TABLE1);
 ColumnFamilyStore cfs = table.getColumnFamilyStore(CF2);

[2/3] git commit: Merge branch 'cassandra-1.2' into cassandra-2.0

Merge branch 'cassandra-1.2' into cassandra-2.0

Conflicts:
test/unit/org/apache/cassandra/db/CleanupTest.java


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9a6ae96a
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9a6ae96a
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9a6ae96a

Branch: refs/heads/trunk
Commit: 9a6ae96af725e307d05332554f221c97e10647d1
Parents: b5321d5 4b83a6f
Author: Marcus Eriksson marc...@apache.org
Authored: Mon Feb 10 18:34:43 2014 +0100
Committer: Marcus Eriksson marc...@apache.org
Committed: Mon Feb 10 18:34:43 2014 +0100

--
 test/unit/org/apache/cassandra/db/CleanupTest.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/9a6ae96a/test/unit/org/apache/cassandra/db/CleanupTest.java
--
diff --cc test/unit/org/apache/cassandra/db/CleanupTest.java
index 562df1e,d5c2b07..9914c90
--- a/test/unit/org/apache/cassandra/db/CleanupTest.java
+++ b/test/unit/org/apache/cassandra/db/CleanupTest.java
@@@ -64,10 -64,9 +64,10 @@@ public class CleanupTest extends Schema
  @Test
  public void testCleanup() throws IOException, ExecutionException, 
InterruptedException, ConfigurationException
  {
- StorageService.instance.initServer(0);
+ StorageService.instance.getTokenMetadata().clearUnsafe();
 -Table table = Table.open(TABLE1);
 -ColumnFamilyStore cfs = table.getColumnFamilyStore(CF2);
 +
 +Keyspace keyspace = Keyspace.open(KEYSPACE1);
 +ColumnFamilyStore cfs = keyspace.getColumnFamilyStore(CF2);
  
  ListRow rows;

[1/3] git commit: Fix CleanupTest

Updated Branches:
  refs/heads/trunk 861d9960d - 503a8a865


Fix CleanupTest

patch by marcuse, reviewed by jbellis for CASSANDRA-6679


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/4b83a6f9
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/4b83a6f9
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/4b83a6f9

Branch: refs/heads/trunk
Commit: 4b83a6f9d9c00fe662ddb9db4533df8b9b96883d
Parents: 887558f
Author: Marcus Eriksson marc...@apache.org
Authored: Mon Feb 10 18:32:06 2014 +0100
Committer: Marcus Eriksson marc...@apache.org
Committed: Mon Feb 10 18:32:06 2014 +0100

--
 test/unit/org/apache/cassandra/db/CleanupTest.java | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/4b83a6f9/test/unit/org/apache/cassandra/db/CleanupTest.java
--
diff --git a/test/unit/org/apache/cassandra/db/CleanupTest.java 
b/test/unit/org/apache/cassandra/db/CleanupTest.java
index 5872407..d5c2b07 100644
--- a/test/unit/org/apache/cassandra/db/CleanupTest.java
+++ b/test/unit/org/apache/cassandra/db/CleanupTest.java
@@ -64,8 +64,7 @@ public class CleanupTest extends SchemaLoader
 @Test
 public void testCleanup() throws IOException, ExecutionException, 
InterruptedException, ConfigurationException
 {
-StorageService.instance.initServer(0);
-
+StorageService.instance.getTokenMetadata().clearUnsafe();
 Table table = Table.open(TABLE1);
 ColumnFamilyStore cfs = table.getColumnFamilyStore(CF2);

[2/2] git commit: Merge branch 'cassandra-1.2' into cassandra-2.0

Merge branch 'cassandra-1.2' into cassandra-2.0

Conflicts:
test/unit/org/apache/cassandra/db/CleanupTest.java


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9a6ae96a
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9a6ae96a
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9a6ae96a

Branch: refs/heads/cassandra-2.0
Commit: 9a6ae96af725e307d05332554f221c97e10647d1
Parents: b5321d5 4b83a6f
Author: Marcus Eriksson marc...@apache.org
Authored: Mon Feb 10 18:34:43 2014 +0100
Committer: Marcus Eriksson marc...@apache.org
Committed: Mon Feb 10 18:34:43 2014 +0100

--
 test/unit/org/apache/cassandra/db/CleanupTest.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/9a6ae96a/test/unit/org/apache/cassandra/db/CleanupTest.java
--
diff --cc test/unit/org/apache/cassandra/db/CleanupTest.java
index 562df1e,d5c2b07..9914c90
--- a/test/unit/org/apache/cassandra/db/CleanupTest.java
+++ b/test/unit/org/apache/cassandra/db/CleanupTest.java
@@@ -64,10 -64,9 +64,10 @@@ public class CleanupTest extends Schema
  @Test
  public void testCleanup() throws IOException, ExecutionException, 
InterruptedException, ConfigurationException
  {
- StorageService.instance.initServer(0);
+ StorageService.instance.getTokenMetadata().clearUnsafe();
 -Table table = Table.open(TABLE1);
 -ColumnFamilyStore cfs = table.getColumnFamilyStore(CF2);
 +
 +Keyspace keyspace = Keyspace.open(KEYSPACE1);
 +ColumnFamilyStore cfs = keyspace.getColumnFamilyStore(CF2);
  
  ListRow rows;

[jira] [Assigned] (CASSANDRA-6654) Droppable tombstones are not being removed from LCS table despite being above 20%

2014-02-10 Thread Ryan McGuire (JIRA)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-6654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan McGuire reassigned CASSANDRA-6654:
---

Assignee: Russ Hatch  (was: Ryan McGuire)

 Droppable tombstones are not being removed from LCS table despite being above 
 20%
 -

 Key: CASSANDRA-6654
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6654
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: 1.2.13 VNodes with murmur3
Reporter: Keith Wright
Assignee: Russ Hatch
 Attachments: Screen Shot 2014-02-05 at 9.38.20 AM.png


 JMX is showing that one of our CQL3 LCS tables has a droppable tombstone 
 ratio above 20% and increasing (currently at 28%).  Compactions are not 
 falling behind and we are using the OOTB setting for this feature so I would 
 expect not to go above 20% (will attach screen shot from JMX).   Table 
 description:
 CREATE TABLE global_user (
   user_id timeuuid,
   app_id int,
   type text,
   name text,
   extra_param maptext, text,
   last timestamp,
   paid boolean,
   sku_time maptext, timestamp,
   values maptimestamp, float,
   PRIMARY KEY (user_id, app_id, type, name)
 ) WITH
   bloom_filter_fp_chance=0.10 AND
   caching='KEYS_ONLY' AND
   comment='' AND
   dclocal_read_repair_chance=0.00 AND
   gc_grace_seconds=86400 AND
   read_repair_chance=0.10 AND
   replicate_on_write='true' AND
   populate_io_cache_on_flush='false' AND
   compaction={'sstable_size_in_mb': '160', 'class': 
 'LeveledCompactionStrategy'} AND
   compression={'chunk_length_kb': '8', 'crc_check_chance': '0.1', 
 'sstable_compression': 'LZ4Compressor'}; 



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (CASSANDRA-5201) Cassandra/Hadoop does not support current Hadoop releases


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-5201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Ellis updated CASSANDRA-5201:
--

Assignee: Benjamin Coverston  (was: Dave Brosius)

Are we good here [~brandon.williams]?

 Cassandra/Hadoop does not support current Hadoop releases
 -

 Key: CASSANDRA-5201
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5201
 Project: Cassandra
  Issue Type: Bug
  Components: Hadoop
Affects Versions: 1.2.0
Reporter: Brian Jeltema
Assignee: Benjamin Coverston
 Attachments: 5201_a.txt, hadoopCompat.patch


 Using Hadoop 0.22.0 with Cassandra results in the stack trace below.
 It appears that version 0.21+ changed org.apache.hadoop.mapreduce.JobContext
 from a class to an interface.
 Exception in thread main java.lang.IncompatibleClassChangeError: Found 
 interface org.apache.hadoop.mapreduce.JobContext, but class was expected
   at 
 org.apache.cassandra.hadoop.ColumnFamilyInputFormat.getSplits(ColumnFamilyInputFormat.java:103)
   at 
 org.apache.hadoop.mapreduce.JobSubmitter.writeNewSplits(JobSubmitter.java:445)
   at 
 org.apache.hadoop.mapreduce.JobSubmitter.writeSplits(JobSubmitter.java:462)
   at 
 org.apache.hadoop.mapreduce.JobSubmitter.submitJobInternal(JobSubmitter.java:357)
   at org.apache.hadoop.mapreduce.Job$2.run(Job.java:1045)
   at org.apache.hadoop.mapreduce.Job$2.run(Job.java:1042)
   at java.security.AccessController.doPrivileged(Native Method)
   at javax.security.auth.Subject.doAs(Subject.java:415)
   at 
 org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1153)
   at org.apache.hadoop.mapreduce.Job.submit(Job.java:1042)
   at org.apache.hadoop.mapreduce.Job.waitForCompletion(Job.java:1062)
   at MyHadoopApp.run(MyHadoopApp.java:163)
   at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:69)
   at MyHadoopApp.main(MyHadoopApp.java:82)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:601)
   at org.apache.hadoop.util.RunJar.main(RunJar.java:192)



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (CASSANDRA-6686) Update download page with snapshot build links

2014-02-10 Thread Michael Shuler (JIRA)

Michael Shuler created CASSANDRA-6686:
-

 Summary: Update download page with snapshot build links
 Key: CASSANDRA-6686
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6686
 Project: Cassandra
  Issue Type: Task
  Components: Documentation  website
Reporter: Michael Shuler
Priority: Trivial


Jenkins is now configured to build snapshot artifacts.  Please, update 
http://cassandra.apache.org/download/ to include the following links for the 
branch artifacts (or just trunk, if you only want to list that still)(trunk/1.2 
will show up after the next build):
- trunk:  http://cassci.datastax.com/job/trunk/lastSuccessfulBuild/
- cassandra-2.0:  
http://cassci.datastax.com/job/cassandra-2.0/lastSuccessfulBuild/
- cassandra-1.2:  
http://cassci.datastax.com/job/cassandra-1.2/lastSuccessfulBuild/



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (CASSANDRA-6357) Flush memtables to separate directory

[
https://issues.apache.org/jira/browse/CASSANDRA-6357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Jonathan Ellis updated CASSANDRA-6357:
--

Fix Version/s: (was: 2.0.6)
2.1

v3 pushed to https://github.com/jbellis/cassandra/commits/6357-3, with some
renaming pulled into a separate commit.

bit messier than I was hoping so retargetting for 2.1.

Flush memtables to separate directory
-

Key: CASSANDRA-6357
URL: https://issues.apache.org/jira/browse/CASSANDRA-6357
Project: Cassandra
Issue Type: New Feature
Components: Core
Reporter: Patrick McFadin
Assignee: Jonathan Ellis
Priority: Minor
Fix For: 2.1

Attachments: 6357-v2.txt, 6357.txt,
c6357-stress-write-latency-99th-1.png

Flush writers are a critical element for keeping a node healthy. When several
compactions run on systems with low performing data directories, IO becomes a
premium. Once the disk subsystem is saturated, write IO is blocked which will
cause flush writer threads to backup. Since memtables are large blocks of
memory in the JVM, too much blocking can cause excessive GC over time
degrading performance. In the worst case causing an OOM.
Since compaction is running on the data directories. My proposal is to create
a separate directory for flushing memtables. Potentially we can use the same
methodology of keeping the commit log separate and minimize disk contention
against the critical function of the flushwriter.

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (CASSANDRA-6686) Update download page with snapshot build links


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-6686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Ellis resolved CASSANDRA-6686.
---

Resolution: Fixed

linked 2.0 and trunk.  thanks!

 Update download page with snapshot build links
 --

 Key: CASSANDRA-6686
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6686
 Project: Cassandra
  Issue Type: Task
  Components: Documentation  website
Reporter: Michael Shuler
Priority: Trivial

 Jenkins is now configured to build snapshot artifacts.  Please, update 
 http://cassandra.apache.org/download/ to include the following links for the 
 branch artifacts (or just trunk, if you only want to list that 
 still)(trunk/1.2 will show up after the next build):
 - trunk:  http://cassci.datastax.com/job/trunk/lastSuccessfulBuild/
 - cassandra-2.0:  
 http://cassci.datastax.com/job/cassandra-2.0/lastSuccessfulBuild/
 - cassandra-1.2:  
 http://cassci.datastax.com/job/cassandra-1.2/lastSuccessfulBuild/



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (CASSANDRA-4911) Lift limitation that order by columns must be selected for IN queries


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-4911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Ellis updated CASSANDRA-4911:
--

Reviewer: Tyler Hobbs  (was: Aleksey Yeschenko)

[~thobbs] can you review?  would like to get this into 2.1b1

 Lift limitation that order by columns must be selected for IN queries
 -

 Key: CASSANDRA-4911
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4911
 Project: Cassandra
  Issue Type: Improvement
  Components: API
Affects Versions: 1.2.0 beta 1
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
 Fix For: 2.1

 Attachments: 4911.txt


 This is the followup of CASSANDRA-4645. We should remove the limitation that 
 for IN queries, you must have columns on which you have an ORDER BY in the 
 select clause.
 For that, we'll need to automatically add the columns on which we have an 
 ORDER BY to the one queried internally, and remove it afterwards (once the 
 sorting is done) from the resultSet.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CASSANDRA-6475) Control nodetool history logging directory

2014-02-10 Thread Brian Nixon (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13897025#comment-13897025
 ] 

Brian Nixon commented on CASSANDRA-6475:


Yes, we can and do hand the logging directory to the nodetool command as 
-Duser.home. It's simply awkward, unintuitive, and inconvenient when 
coordinating the access of multiple users to a single Cassandra instance.

Is there a compelling reason to (1) leave nodetool and cli history logging 
rooted at user_home or (2) not have a property to turn off history logging 
completely if it is not desired?


 Control nodetool history logging directory
 --

 Key: CASSANDRA-6475
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6475
 Project: Cassandra
  Issue Type: New Feature
  Components: Tools
Reporter: Brian Nixon
Priority: Trivial
  Labels: lhf

 Nodetool history is logged to a directory based on the current user home. 
 This leads to splintering of history with more than one user and, in one 
 case, a failure to run any nodetool commands as the user did not have write 
 access to their home directory.
 Suggested fix is to make the base directory for the history logging (both 
 nodetool and cli) configurable. A way to disable the logging of these tools 
 would also help.
 Reference:
 https://issues.apache.org/jira/browse/CASSANDRA-5823



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CASSANDRA-5266) FileNotFoundException during AntiEntropy Stream Session after compaction

2014-02-10 Thread Arya Goudarzi (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-5266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13897033#comment-13897033
 ] 

Arya Goudarzi commented on CASSANDRA-5266:
--

This weekend this issue was reproduced on our production cluster which runs 
1.2.14 now. But, we don't use secondary indexes this time. We lost a node a few 
days ago which I tried to replace. Over the course of repair, lots of these 
FileNotFound exceptions showed up during streaming sessions from other nodes to 
the node being repaired. As a result, the node being repaired was hung on its 
repair task and had to be restarted. 

 FileNotFoundException during AntiEntropy Stream Session after compaction
 

 Key: CASSANDRA-5266
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5266
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.6
 Environment: Ubuntu 10.04
 Cassandra 1.1.6
 Jave 6 (64 Bit Sun JVM)
Reporter: Arya Goudarzi
Assignee: Yuki Morishita

 It seems that there is a race condition in the compaction process vs 
 AntiEntropy Streams. We often have repairs tossing lots of exceptions in the 
 logs as follows:
 java.lang.RuntimeException: java.io.FileNotFoundException: 
 /var/lib/cassandra/data/keyspace_production/User/keyspace_production-User-hf-20056-Data.db
  (No such file or directory)
 at 
 org.apache.cassandra.utils.FBUtilities.unchecked(FBUtilities.java:628)
 at 
 org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:34)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 at java.lang.Thread.run(Thread.java:662)
 Caused by: java.io.FileNotFoundException: 
 /var/lib/cassandra/data/keyspace_production/User/keyspace_production-User-hf-20056-Data.db
  (No such file or directory)
 at java.io.RandomAccessFile.open(Native Method)
 at java.io.RandomAccessFile.init(RandomAccessFile.java:216)
 at 
 org.apache.cassandra.io.util.RandomAccessReader.init(RandomAccessReader.java:67)
 at 
 org.apache.cassandra.io.compress.CompressedRandomAccessReader.init(CompressedRandomAccessReader.java:64)
 at 
 org.apache.cassandra.io.compress.CompressedRandomAccessReader.open(CompressedRandomAccessReader.java:46)
 at 
 org.apache.cassandra.streaming.FileStreamTask.stream(FileStreamTask.java:145)
 at 
 org.apache.cassandra.streaming.FileStreamTask.runMayThrow(FileStreamTask.java:94)
 at 
 org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
 ... 3 more
 Now about 1-2 minutes before that, I see Secondary Index buildup and 
 compaction which does compact the same SSTable to a new one. 
 INFO [Thread-90838] 2013-02-07 13:51:58,362 SecondaryIndexManager.java (line 
 126) Submitting index build of publisher_id, for data in 
 SSTableReader(path='/var/lib/cassandra/data/keyspace_production/User/keyspace_production-User-hf-20054-Data.db'),
  
 SSTableReader(path='/var/lib/cassandra/data/keyspace_production/User/keyspace_production-User-hf-20055-Data.db'),
  
 SSTableReader(path='/var/lib/cassandra/data/keyspace_production/User/keyspace_production-User-hf-20056-Data.db'),
  
 SSTableReader(path='/var/lib/cassandra/data/keyspace_production/User/keyspace_production-User-hf-20057-Data.db'),
  
 SSTableReader(path='/var/lib/cassandra/data/keyspace_production/User/keyspace_production-User-hf-20058-Data.db')
  INFO [CompactionExecutor:436] 2013-02-07 13:51:58,363 CompactionTask.java 
 (line 109) Compacting 
 [SSTableReader(path='/var/lib/cassandra/data/keyspace_production/User/keyspace_production-User-hf-20055-Data.db'),
  
 SSTableReader(path='/var/lib/cassandra/data/keyspace_production/User/keyspace_production-User-hf-20054-Data.db'),
  
 SSTableReader(path='/var/lib/cassandra/data/keyspace_production/User/keyspace_production-User-hf-20058-Data.db'),
  
 SSTableReader(path='/var/lib/cassandra/data/keyspace_production/User/keyspace_production-User-hf-20057-Data.db'),
  
 SSTableReader(path='/var/lib/cassandra/data/keyspace_production/User/keyspace_production-User-hf-20056-Data.db')]
 Now, does this make the repair sessions to fail? It seems the node was trying 
 to stream a file to a node being repaired but apparently it did not.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (CASSANDRA-5266) FileNotFoundException during AntiEntropy Stream Session after compaction

2014-02-10 Thread Arya Goudarzi (JIRA)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-5266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Arya Goudarzi updated CASSANDRA-5266:
-

Environment: 
Ubuntu 10.04
Cassandra 1.2.14
Jave 7 64 Bit Sun JVM

  was:
Ubuntu 10.04
Cassandra 1.1.6
Jave 6 (64 Bit Sun JVM)


 FileNotFoundException during AntiEntropy Stream Session after compaction
 

 Key: CASSANDRA-5266
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5266
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.6
 Environment: Ubuntu 10.04
 Cassandra 1.2.14
 Jave 7 64 Bit Sun JVM
Reporter: Arya Goudarzi
Assignee: Yuki Morishita

 It seems that there is a race condition in the compaction process vs 
 AntiEntropy Streams. We often have repairs tossing lots of exceptions in the 
 logs as follows:
 java.lang.RuntimeException: java.io.FileNotFoundException: 
 /var/lib/cassandra/data/keyspace_production/User/keyspace_production-User-hf-20056-Data.db
  (No such file or directory)
 at 
 org.apache.cassandra.utils.FBUtilities.unchecked(FBUtilities.java:628)
 at 
 org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:34)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 at java.lang.Thread.run(Thread.java:662)
 Caused by: java.io.FileNotFoundException: 
 /var/lib/cassandra/data/keyspace_production/User/keyspace_production-User-hf-20056-Data.db
  (No such file or directory)
 at java.io.RandomAccessFile.open(Native Method)
 at java.io.RandomAccessFile.init(RandomAccessFile.java:216)
 at 
 org.apache.cassandra.io.util.RandomAccessReader.init(RandomAccessReader.java:67)
 at 
 org.apache.cassandra.io.compress.CompressedRandomAccessReader.init(CompressedRandomAccessReader.java:64)
 at 
 org.apache.cassandra.io.compress.CompressedRandomAccessReader.open(CompressedRandomAccessReader.java:46)
 at 
 org.apache.cassandra.streaming.FileStreamTask.stream(FileStreamTask.java:145)
 at 
 org.apache.cassandra.streaming.FileStreamTask.runMayThrow(FileStreamTask.java:94)
 at 
 org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
 ... 3 more
 Now about 1-2 minutes before that, I see Secondary Index buildup and 
 compaction which does compact the same SSTable to a new one. 
 INFO [Thread-90838] 2013-02-07 13:51:58,362 SecondaryIndexManager.java (line 
 126) Submitting index build of publisher_id, for data in 
 SSTableReader(path='/var/lib/cassandra/data/keyspace_production/User/keyspace_production-User-hf-20054-Data.db'),
  
 SSTableReader(path='/var/lib/cassandra/data/keyspace_production/User/keyspace_production-User-hf-20055-Data.db'),
  
 SSTableReader(path='/var/lib/cassandra/data/keyspace_production/User/keyspace_production-User-hf-20056-Data.db'),
  
 SSTableReader(path='/var/lib/cassandra/data/keyspace_production/User/keyspace_production-User-hf-20057-Data.db'),
  
 SSTableReader(path='/var/lib/cassandra/data/keyspace_production/User/keyspace_production-User-hf-20058-Data.db')
  INFO [CompactionExecutor:436] 2013-02-07 13:51:58,363 CompactionTask.java 
 (line 109) Compacting 
 [SSTableReader(path='/var/lib/cassandra/data/keyspace_production/User/keyspace_production-User-hf-20055-Data.db'),
  
 SSTableReader(path='/var/lib/cassandra/data/keyspace_production/User/keyspace_production-User-hf-20054-Data.db'),
  
 SSTableReader(path='/var/lib/cassandra/data/keyspace_production/User/keyspace_production-User-hf-20058-Data.db'),
  
 SSTableReader(path='/var/lib/cassandra/data/keyspace_production/User/keyspace_production-User-hf-20057-Data.db'),
  
 SSTableReader(path='/var/lib/cassandra/data/keyspace_production/User/keyspace_production-User-hf-20056-Data.db')]
 Now, does this make the repair sessions to fail? It seems the node was trying 
 to stream a file to a node being repaired but apparently it did not.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (CASSANDRA-5266) FileNotFoundException during AntiEntropy Stream Session after compaction

2014-02-10 Thread Arya Goudarzi (JIRA)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-5266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Arya Goudarzi updated CASSANDRA-5266:
-

Reproduced In: 1.2.14
Since Version: 1.1.6

 FileNotFoundException during AntiEntropy Stream Session after compaction
 

 Key: CASSANDRA-5266
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5266
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.1.6
 Environment: Ubuntu 10.04
 Cassandra 1.2.14
 Jave 7 64 Bit Sun JVM
Reporter: Arya Goudarzi
Assignee: Yuki Morishita

 It seems that there is a race condition in the compaction process vs 
 AntiEntropy Streams. We often have repairs tossing lots of exceptions in the 
 logs as follows:
 java.lang.RuntimeException: java.io.FileNotFoundException: 
 /var/lib/cassandra/data/keyspace_production/User/keyspace_production-User-hf-20056-Data.db
  (No such file or directory)
 at 
 org.apache.cassandra.utils.FBUtilities.unchecked(FBUtilities.java:628)
 at 
 org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:34)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 at java.lang.Thread.run(Thread.java:662)
 Caused by: java.io.FileNotFoundException: 
 /var/lib/cassandra/data/keyspace_production/User/keyspace_production-User-hf-20056-Data.db
  (No such file or directory)
 at java.io.RandomAccessFile.open(Native Method)
 at java.io.RandomAccessFile.init(RandomAccessFile.java:216)
 at 
 org.apache.cassandra.io.util.RandomAccessReader.init(RandomAccessReader.java:67)
 at 
 org.apache.cassandra.io.compress.CompressedRandomAccessReader.init(CompressedRandomAccessReader.java:64)
 at 
 org.apache.cassandra.io.compress.CompressedRandomAccessReader.open(CompressedRandomAccessReader.java:46)
 at 
 org.apache.cassandra.streaming.FileStreamTask.stream(FileStreamTask.java:145)
 at 
 org.apache.cassandra.streaming.FileStreamTask.runMayThrow(FileStreamTask.java:94)
 at 
 org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
 ... 3 more
 Now about 1-2 minutes before that, I see Secondary Index buildup and 
 compaction which does compact the same SSTable to a new one. 
 INFO [Thread-90838] 2013-02-07 13:51:58,362 SecondaryIndexManager.java (line 
 126) Submitting index build of publisher_id, for data in 
 SSTableReader(path='/var/lib/cassandra/data/keyspace_production/User/keyspace_production-User-hf-20054-Data.db'),
  
 SSTableReader(path='/var/lib/cassandra/data/keyspace_production/User/keyspace_production-User-hf-20055-Data.db'),
  
 SSTableReader(path='/var/lib/cassandra/data/keyspace_production/User/keyspace_production-User-hf-20056-Data.db'),
  
 SSTableReader(path='/var/lib/cassandra/data/keyspace_production/User/keyspace_production-User-hf-20057-Data.db'),
  
 SSTableReader(path='/var/lib/cassandra/data/keyspace_production/User/keyspace_production-User-hf-20058-Data.db')
  INFO [CompactionExecutor:436] 2013-02-07 13:51:58,363 CompactionTask.java 
 (line 109) Compacting 
 [SSTableReader(path='/var/lib/cassandra/data/keyspace_production/User/keyspace_production-User-hf-20055-Data.db'),
  
 SSTableReader(path='/var/lib/cassandra/data/keyspace_production/User/keyspace_production-User-hf-20054-Data.db'),
  
 SSTableReader(path='/var/lib/cassandra/data/keyspace_production/User/keyspace_production-User-hf-20058-Data.db'),
  
 SSTableReader(path='/var/lib/cassandra/data/keyspace_production/User/keyspace_production-User-hf-20057-Data.db'),
  
 SSTableReader(path='/var/lib/cassandra/data/keyspace_production/User/keyspace_production-User-hf-20056-Data.db')]
 Now, does this make the repair sessions to fail? It seems the node was trying 
 to stream a file to a node being repaired but apparently it did not.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (CASSANDRA-6687) CQL: drop table if exists throws exception when table does not exist

2014-02-10 Thread Brent Haines (JIRA)

Brent Haines created CASSANDRA-6687:
---

 Summary: CQL: drop table if exists throws exception when table 
does not exist
 Key: CASSANDRA-6687
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6687
 Project: Cassandra
  Issue Type: Bug
 Environment: Mac OSX Mavericks
Cassandra 2.0.5
Reporter: Brent Haines


{code}
MacBook-Bro-6:~ brenthaines$ cqlsh
Connected to Test Cluster at localhost:9160.
[cqlsh 4.1.1 | Cassandra 2.0.5 | CQL spec 3.1.1 | Thrift protocol 19.39.0]
Use HELP for help.
cqlsh use apps;
cqlsh:apps describe table brands;

Column family 'brands' not found
cqlsh:apps drop table if exists brands;
Bad Request: unconfigured columnfamily brands
cqlsh:apps 
{code}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CASSANDRA-6662) Sort/reconcile cells in ArrayBackedSortedColumns only when an accessor is called

2014-02-10 Thread Aleksey Yeschenko (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13897222#comment-13897222
 ] 

Aleksey Yeschenko commented on CASSANDRA-6662:
--

Now that I think of it, reconcileTail() path is kinda useless, and only adds 
extra complexity. Doesn't make it more efficient - we still have to do the same 
number of operations as in the regular path.

 Sort/reconcile cells in ArrayBackedSortedColumns only when an accessor is 
 called
 

 Key: CASSANDRA-6662
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6662
 Project: Cassandra
  Issue Type: Improvement
Reporter: Aleksey Yeschenko
Assignee: Aleksey Yeschenko
 Fix For: 2.1


 To avoid poor performance with huge numbers of cells added out of order 
 (which should be rare, but *can* happen with certain batch scenarios) we 
 should make ABSC only sort/reconcile its cells when an actual accessor is 
 actually called, delaying sorting until the very end.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CASSANDRA-6631) cassandra-stress failing in trunk

2014-02-10 Thread Michael Shuler (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13897284#comment-13897284
 ] 

Michael Shuler commented on CASSANDRA-6631:
---

Tried to drop in current java-driver jars, and c* stress-build fails to build 
with:
{noformat}
stress-build:
[mkdir] Created dir: /home/mshuler/git/cassandra/build/classes/stress
[javac] Compiling 74 source files to 
/home/mshuler/git/cassandra/build/classes/stress
[javac] 
/home/mshuler/git/cassandra/tools/stress/src/org/apache/cassandra/stress/util/JavaDriverClient.java:145:
 error: cannot find symbol
[javac] FBUtilities.waitOnFuture(cluster.shutdown());
[javac] ^
[javac]   symbol:   method shutdown()
[javac]   location: variable cluster of type Cluster
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 1 error

BUILD FAILED
{noformat}

Since it took me a bit to figure out how to get both jars we needed from 
java-driver:
{noformat}
git clone https://github.com/datastax/java-driver.git
cd java-driver/driver-core/
mvn package assembly:single
{noformat}

replace the 2.0.0-rc2 jars in $gitdir/cassandra/tools/lib/ with
- target/cassandra-driver-core-2.0.0-rc3-SNAPSHOT.jar
- target/cassandra-driver-core-2.0.0-rc3-SNAPSHOT-jar-with-dependencies.jar

 cassandra-stress failing in trunk
 -

 Key: CASSANDRA-6631
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6631
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
 Environment: Debian Stable Wheezy
 Oracle JDK 1.7.0_51-b13
Reporter: Michael Shuler
 Fix For: 2.1


 Stress is failing in trunk.
 - ant clean jar
 - ./bin/cassandra -f
 - ./tools/bin/cassandra-stress write
 {noformat}
 (trunk)mshuler@hana:~/git/cassandra$ ./tools/bin/cassandra-stress write
 Created keyspaces. Sleeping 1s for propagation.
 Warming up WRITE with 5 iterations...
 Exception in thread Thread-0 java.lang.RuntimeException: 
 java.lang.IllegalArgumentException: replicate_on_write is not a column 
 defined in this metadata
 at 
 org.apache.cassandra.stress.settings.StressSettings.getJavaDriverClient(StressSettings.java:142)
 at 
 org.apache.cassandra.stress.settings.StressSettings.getSmartThriftClient(StressSettings.java:49)
 at 
 org.apache.cassandra.stress.StressAction$Consumer.run(StressAction.java:273)
 Caused by: java.lang.IllegalArgumentException: replicate_on_write is not a 
 column defined in this metadata
 at 
 com.datastax.driver.core.ColumnDefinitions.getAllIdx(ColumnDefinitions.java:273)
 at 
 com.datastax.driver.core.ColumnDefinitions.getFirstIdx(ColumnDefinitions.java:279)
 at com.datastax.driver.core.Row.getBool(Row.java:117)
 at 
 com.datastax.driver.core.TableMetadata$Options.init(TableMetadata.java:474)
 at 
 com.datastax.driver.core.TableMetadata.build(TableMetadata.java:107)
 at 
 com.datastax.driver.core.Metadata.buildTableMetadata(Metadata.java:128)
 at com.datastax.driver.core.Metadata.rebuildSchema(Metadata.java:89)
 at 
 com.datastax.driver.core.ControlConnection.refreshSchema(ControlConnection.java:259)
 at 
 com.datastax.driver.core.ControlConnection.tryConnect(ControlConnection.java:214)
 at 
 com.datastax.driver.core.ControlConnection.reconnectInternal(ControlConnection.java:161)
 at 
 com.datastax.driver.core.ControlConnection.connect(ControlConnection.java:77)
 at com.datastax.driver.core.Cluster$Manager.init(Cluster.java:890)
 at 
 com.datastax.driver.core.Cluster$Manager.access$100(Cluster.java:806)
 at com.datastax.driver.core.Cluster.getMetadata(Cluster.java:217)
 at 
 org.apache.cassandra.stress.util.JavaDriverClient.connect(JavaDriverClient.java:75)
 at 
 org.apache.cassandra.stress.settings.StressSettings.getJavaDriverClient(StressSettings.java:135)
 ... 2 more
 Exception in thread Thread-19 java.lang.RuntimeException: 
 java.lang.IllegalArgumentException: replicate_on_write is not a column 
 defined in this metadata
 at 
 org.apache.cassandra.stress.settings.StressSettings.getJavaDriverClient(StressSettings.java:142)
 at 
 org.apache.cassandra.stress.settings.StressSettings.getSmartThriftClient(StressSettings.java:49)
 at 
 org.apache.cassandra.stress.StressAction$Consumer.run(StressAction.java:273)
 Caused by: java.lang.IllegalArgumentException: replicate_on_write is not a 
 column defined in this metadata
 at

[jira] [Commented] (CASSANDRA-6440) Repair should allow repairing particular endpoints to reduce WAN usage.

2014-02-10 Thread sankalp kohli (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13897318#comment-13897318
 ] 

sankalp kohli commented on CASSANDRA-6440:
--

[~lyubent]  Looks good. 

 Repair should allow repairing particular endpoints to reduce WAN usage. 
 

 Key: CASSANDRA-6440
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6440
 Project: Cassandra
  Issue Type: New Feature
Reporter: sankalp kohli
Assignee: sankalp kohli
Priority: Minor
 Attachments: 6440_repair.log, JIRA-6440-v2.diff, JIRA-6440-v3.diff, 
 JIRA-6440.diff


 The way we send out data that does not match over WAN can be improved. 
 Example: Say there are four nodes(A,B,C,D) which are replica of a range we 
 are repairing. A, B is in DC1 and C,D is in DC2. If A does not have the data 
 which other replicas have, then we will have following streams
 1) A to B and back
 2) A to C and back(Goes over WAN)
 3) A to D and back(Goes over WAN)
 One of the ways of doing it to reduce WAN traffic is this.
 1) Repair A and B only with each other and C and D with each other starting 
 at same time t. 
 2) Once these repairs have finished, A,B and C,D are in sync with respect to 
 time t. 
 3) Now run a repair between A and C, the streams which are exchanged as a 
 result of the diff will also be streamed to B and D via A and C(C and D 
 behaves like a proxy to the streams).
 For a replication of DC1:2,DC2:2, the WAN traffic will get reduced by 50% and 
 even more for higher replication factors.
 Another easy way to do this is to have repair command take nodes with which 
 you want to repair with. Then we can do something like this.
 1) Run repair between (A and B) and (C and D)
 2) Run repair between (A and C)
 3) Run repair between (A and B) and (C and D)
 But this will increase the traffic inside the DC as we wont be doing proxy.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Assigned] (CASSANDRA-6687) CQL: drop table if exists throws exception when table does not exist


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-6687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mikhail Stepura reassigned CASSANDRA-6687:
--

Assignee: Mikhail Stepura

 CQL: drop table if exists throws exception when table does not exist
 --

 Key: CASSANDRA-6687
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6687
 Project: Cassandra
  Issue Type: Bug
 Environment: Mac OSX Mavericks
 Cassandra 2.0.5
Reporter: Brent Haines
Assignee: Mikhail Stepura
  Labels: 2.0.5

 {code}
 MacBook-Bro-6:~ brenthaines$ cqlsh
 Connected to Test Cluster at localhost:9160.
 [cqlsh 4.1.1 | Cassandra 2.0.5 | CQL spec 3.1.1 | Thrift protocol 19.39.0]
 Use HELP for help.
 cqlsh use apps;
 cqlsh:apps describe table brands;
 Column family 'brands' not found
 cqlsh:apps drop table if exists brands;
 Bad Request: unconfigured columnfamily brands
 cqlsh:apps 
 {code}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (CASSANDRA-6687) CQL: drop table if exists throws exception when table does not exist


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-6687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mikhail Stepura updated CASSANDRA-6687:
---

Reproduced In: 2.0.5

 CQL: drop table if exists throws exception when table does not exist
 --

 Key: CASSANDRA-6687
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6687
 Project: Cassandra
  Issue Type: Bug
 Environment: Mac OSX Mavericks
 Cassandra 2.0.5
Reporter: Brent Haines
Assignee: Mikhail Stepura
  Labels: 2.0.5

 {code}
 MacBook-Bro-6:~ brenthaines$ cqlsh
 Connected to Test Cluster at localhost:9160.
 [cqlsh 4.1.1 | Cassandra 2.0.5 | CQL spec 3.1.1 | Thrift protocol 19.39.0]
 Use HELP for help.
 cqlsh use apps;
 cqlsh:apps describe table brands;
 Column family 'brands' not found
 cqlsh:apps drop table if exists brands;
 Bad Request: unconfigured columnfamily brands
 cqlsh:apps 
 {code}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CASSANDRA-6687) CQL: drop table if exists throws exception when table does not exist


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13897370#comment-13897370
 ] 

Mikhail Stepura commented on CASSANDRA-6687:


{{.DropTableStatement.checkAccess(ClientState)}} doesn't handle the case if the 
table doesn't exist

 CQL: drop table if exists throws exception when table does not exist
 --

 Key: CASSANDRA-6687
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6687
 Project: Cassandra
  Issue Type: Bug
 Environment: Mac OSX Mavericks
 Cassandra 2.0.5
Reporter: Brent Haines
Assignee: Mikhail Stepura
  Labels: 2.0.5

 {code}
 MacBook-Bro-6:~ brenthaines$ cqlsh
 Connected to Test Cluster at localhost:9160.
 [cqlsh 4.1.1 | Cassandra 2.0.5 | CQL spec 3.1.1 | Thrift protocol 19.39.0]
 Use HELP for help.
 cqlsh use apps;
 cqlsh:apps describe table brands;
 Column family 'brands' not found
 cqlsh:apps drop table if exists brands;
 Bad Request: unconfigured columnfamily brands
 cqlsh:apps 
 {code}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (CASSANDRA-6687) CQL: drop table if exists throws exception when table does not exist


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-6687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mikhail Stepura updated CASSANDRA-6687:
---

Priority: Minor  (was: Major)

 CQL: drop table if exists throws exception when table does not exist
 --

 Key: CASSANDRA-6687
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6687
 Project: Cassandra
  Issue Type: Bug
 Environment: Mac OSX Mavericks
 Cassandra 2.0.5
Reporter: Brent Haines
Assignee: Mikhail Stepura
Priority: Minor
  Labels: 2.0.5

 {code}
 MacBook-Bro-6:~ brenthaines$ cqlsh
 Connected to Test Cluster at localhost:9160.
 [cqlsh 4.1.1 | Cassandra 2.0.5 | CQL spec 3.1.1 | Thrift protocol 19.39.0]
 Use HELP for help.
 cqlsh use apps;
 cqlsh:apps describe table brands;
 Column family 'brands' not found
 cqlsh:apps drop table if exists brands;
 Bad Request: unconfigured columnfamily brands
 cqlsh:apps 
 {code}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (CASSANDRA-6687) CQL: drop table if exists throws exception when table does not exist


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-6687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mikhail Stepura updated CASSANDRA-6687:
---

Attachment: CASSANDRA-2.0-6687.patch

Attaching the patch to handle exceptions in {{checkAccess}}

 CQL: drop table if exists throws exception when table does not exist
 --

 Key: CASSANDRA-6687
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6687
 Project: Cassandra
  Issue Type: Bug
 Environment: Mac OSX Mavericks
 Cassandra 2.0.5
Reporter: Brent Haines
Assignee: Mikhail Stepura
Priority: Minor
  Labels: 2.0.5
 Fix For: 2.0.6

 Attachments: CASSANDRA-2.0-6687.patch


 {code}
 MacBook-Bro-6:~ brenthaines$ cqlsh
 Connected to Test Cluster at localhost:9160.
 [cqlsh 4.1.1 | Cassandra 2.0.5 | CQL spec 3.1.1 | Thrift protocol 19.39.0]
 Use HELP for help.
 cqlsh use apps;
 cqlsh:apps describe table brands;
 Column family 'brands' not found
 cqlsh:apps drop table if exists brands;
 Bad Request: unconfigured columnfamily brands
 cqlsh:apps 
 {code}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CASSANDRA-6662) Sort/reconcile cells in ArrayBackedSortedColumns only when an accessor is called

2014-02-10 Thread Aleksey Yeschenko (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-6662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13897482#comment-13897482
 ] 

Aleksey Yeschenko commented on CASSANDRA-6662:
--

Pushed v2 to https://github.com/iamaleksey/cassandra/commits/6662-2

 Sort/reconcile cells in ArrayBackedSortedColumns only when an accessor is 
 called
 

 Key: CASSANDRA-6662
 URL: https://issues.apache.org/jira/browse/CASSANDRA-6662
 Project: Cassandra
  Issue Type: Improvement
Reporter: Aleksey Yeschenko
Assignee: Aleksey Yeschenko
 Fix For: 2.1


 To avoid poor performance with huge numbers of cells added out of order 
 (which should be rare, but *can* happen with certain batch scenarios) we 
 should make ABSC only sort/reconcile its cells when an actual accessor is 
 actually called, delaying sorting until the very end.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CASSANDRA-6687) CQL: drop table if exists throws exception when table does not exist