[jira] [Reopened] (CASSANDRA-6663) Connecting to a Raspberry PI Cassandra Cluster crashes the node being connected to
[
https://issues.apache.org/jira/browse/CASSANDRA-6663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ian mccrae reopened CASSANDRA-6663:
---
I am really confused as to why this ticket has twice been changed to "Closed"
when there doesn't seem to be a solution.
Though perhaps I have misunderstood something here.
> 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 "", line 1, in
> 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': ,
> '_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': ,
> 'compression': None,
> 'contact_points': ['192.168.200.151'],
> 'control_connection': 0x106168cd0>,
> 'control_connection_timeout': 2.0,
> 'cql_version': None,
> 'executor': 0x106148410>,
> 'load_balancing_policy': 0x104adae50>,
> 'max_schema_agreement_wait': 10,
> 'metadata': ,
> 'metrics_enabled': False,
> 'port': 9042,
> 'scheduler': ,
> 'sessions': <_weakrefset.WeakSet object at 0x106148750>,
> 'sockopts': None,
> 'ssl_options': None}
> >>>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6688) Avoid possible sstable overlaps with leveled compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-6688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-6688: --- Attachment: 0001-6688.patch > Avoid possible sstable overlaps with leveled compaction > --- > > Key: CASSANDRA-6688 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6688 > Project: Cassandra > Issue Type: Bug >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson > Attachments: 0001-6688.patch > > > Two cases where we can end up with overlapping sstables in the leveled > manifest; > FIrst one is when we skip levels during compaction. Here we need to make sure > we are not compacting in newLevel - 1 since if, for example, we are doing a > L1 -> L2 compaction and then start a new L0 compaction where we decide to > skip L1, we could have overlapping sstables in L2 when the compactions are > done. This case is new in 2.0 since we check if we skip levels before the > compaction starts. > Second case is where we try to include as many overlapping L0 sstables as > possible, here we could add sstables that are not compacting, but overlap > sstables that are. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CASSANDRA-6688) Avoid possible sstable overlaps with leveled compaction
Marcus Eriksson created CASSANDRA-6688: -- Summary: Avoid possible sstable overlaps with leveled compaction Key: CASSANDRA-6688 URL: https://issues.apache.org/jira/browse/CASSANDRA-6688 Project: Cassandra Issue Type: Bug Reporter: Marcus Eriksson Assignee: Marcus Eriksson Two cases where we can end up with overlapping sstables in the leveled manifest; FIrst one is when we skip levels during compaction. Here we need to make sure we are not compacting in newLevel - 1 since if, for example, we are doing a L1 -> L2 compaction and then start a new L0 compaction where we decide to skip L1, we could have overlapping sstables in L2 when the compactions are done. This case is new in 2.0 since we check if we skip levels before the compaction starts. Second case is where we try to include as many overlapping L0 sstables as possible, here we could add sstables that are not compacting, but overlap sstables that are. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[1/2] git commit: refs CASSANDRA-6687. Don't fail in checkAccess if table doesn't exist
Updated Branches:
refs/heads/trunk 503a8a865 -> f05870ee8
refs CASSANDRA-6687. Don't fail in checkAccess if table doesn't exist
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/87aca600
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/87aca600
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/87aca600
Branch: refs/heads/trunk
Commit: 87aca600fda47a1b72f27ee02cf5f854437ce2be
Parents: 9a6ae96
Author: Mikhail Stepura
Authored: Mon Feb 10 17:03:27 2014 -0800
Committer: Mikhail Stepura
Committed: Mon Feb 10 17:10:09 2014 -0800
--
.../cassandra/cql3/statements/DropTableStatement.java | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/87aca600/src/java/org/apache/cassandra/cql3/statements/DropTableStatement.java
--
diff --git
a/src/java/org/apache/cassandra/cql3/statements/DropTableStatement.java
b/src/java/org/apache/cassandra/cql3/statements/DropTableStatement.java
index fa620e8..d27261c 100644
--- a/src/java/org/apache/cassandra/cql3/statements/DropTableStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/DropTableStatement.java
@@ -38,7 +38,15 @@ public class DropTableStatement extends
SchemaAlteringStatement
public void checkAccess(ClientState state) throws UnauthorizedException,
InvalidRequestException
{
-state.hasColumnFamilyAccess(keyspace(), columnFamily(),
Permission.DROP);
+try
+{
+state.hasColumnFamilyAccess(keyspace(), columnFamily(),
Permission.DROP);
+}
+catch (InvalidRequestException e)
+{
+if (!ifExists)
+throw e;
+}
}
public void validate(ClientState state)
[2/2] 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/f05870ee Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f05870ee Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f05870ee Branch: refs/heads/trunk Commit: f05870ee8cefec3bd9a1af051b2c7098c1f82933 Parents: 503a8a8 87aca60 Author: Mikhail Stepura Authored: Mon Feb 10 21:00:39 2014 -0800 Committer: Mikhail Stepura Committed: Mon Feb 10 21:00:39 2014 -0800 -- .../cassandra/cql3/statements/DropTableStatement.java | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) --
git commit: refs CASSANDRA-6687. Don't fail in checkAccess if table doesn't exist
Updated Branches:
refs/heads/cassandra-2.0 9a6ae96af -> 87aca600f
refs CASSANDRA-6687. Don't fail in checkAccess if table doesn't exist
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/87aca600
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/87aca600
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/87aca600
Branch: refs/heads/cassandra-2.0
Commit: 87aca600fda47a1b72f27ee02cf5f854437ce2be
Parents: 9a6ae96
Author: Mikhail Stepura
Authored: Mon Feb 10 17:03:27 2014 -0800
Committer: Mikhail Stepura
Committed: Mon Feb 10 17:10:09 2014 -0800
--
.../cassandra/cql3/statements/DropTableStatement.java | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/87aca600/src/java/org/apache/cassandra/cql3/statements/DropTableStatement.java
--
diff --git
a/src/java/org/apache/cassandra/cql3/statements/DropTableStatement.java
b/src/java/org/apache/cassandra/cql3/statements/DropTableStatement.java
index fa620e8..d27261c 100644
--- a/src/java/org/apache/cassandra/cql3/statements/DropTableStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/DropTableStatement.java
@@ -38,7 +38,15 @@ public class DropTableStatement extends
SchemaAlteringStatement
public void checkAccess(ClientState state) throws UnauthorizedException,
InvalidRequestException
{
-state.hasColumnFamilyAccess(keyspace(), columnFamily(),
Permission.DROP);
+try
+{
+state.hasColumnFamilyAccess(keyspace(), columnFamily(),
Permission.DROP);
+}
+catch (InvalidRequestException e)
+{
+if (!ifExists)
+throw e;
+}
}
public void validate(ClientState state)
[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-tabpanel&focusedCommentId=13897534#comment-13897534
]
Jonathan Ellis commented on CASSANDRA-6687:
---
+1
> 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
[ https://issues.apache.org/jira/browse/CASSANDRA-6662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [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] [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:
---
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-tabpanel&focusedCommentId=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] [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] [Commented] (CASSANDRA-6440) Repair should allow repairing particular endpoints to reduce WAN usage.
[ https://issues.apache.org/jira/browse/CASSANDRA-6440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Commented] (CASSANDRA-6631) cassandra-stress failing in trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-6631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.(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 met
[jira] [Commented] (CASSANDRA-6662) Sort/reconcile cells in ArrayBackedSortedColumns only when an accessor is called
[ https://issues.apache.org/jira/browse/CASSANDRA-6662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Created] (CASSANDRA-6687) CQL: "drop table if exists" throws exception when table does not exist
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] [Updated] (CASSANDRA-5266) FileNotFoundException during AntiEntropy Stream Session after compaction
[ 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.(RandomAccessFile.java:216) > at > org.apache.cassandra.io.util.RandomAccessReader.(RandomAccessReader.java:67) > at > org.apache.cassandra.io.compress.CompressedRandomAccessReader.(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
[ 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.(RandomAccessFile.java:216) > at > org.apache.cassandra.io.util.RandomAccessReader.(RandomAccessReader.java:67) > at > org.apache.cassandra.io.compress.CompressedRandomAccessReader.(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] [Commented] (CASSANDRA-5266) FileNotFoundException during AntiEntropy Stream Session after compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-5266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.(RandomAccessFile.java:216) > at > org.apache.cassandra.io.util.RandomAccessReader.(RandomAccessReader.java:67) > at > org.apache.cassandra.io.compress.CompressedRandomAccessReader.(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] [Commented] (CASSANDRA-6475) Control nodetool history logging directory
[ https://issues.apache.org/jira/browse/CASSANDRA-6475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [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] [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)
svn commit: r1566726 - in /cassandra/site: publish/download/index.html src/content/download/index.html
Author: jbellis Date: Mon Feb 10 20:12:29 2014 New Revision: 1566726 URL: http://svn.apache.org/r1566726 Log: new snapshot build links Modified: cassandra/site/publish/download/index.html cassandra/site/src/content/download/index.html Modified: cassandra/site/publish/download/index.html URL: http://svn.apache.org/viewvc/cassandra/site/publish/download/index.html?rev=1566726&r1=1566725&r2=1566726&view=diff == --- cassandra/site/publish/download/index.html (original) +++ cassandra/site/publish/download/index.html Mon Feb 10 20:12:29 2014 @@ -178,8 +178,9 @@ - Bleeding edge development snapshots of Cassandra are available from - https://builds.apache.org/job/Cassandra/lastSuccessfulBuild/artifact/cassandra/build/";>Jenkins continuous integration. + Bleeding edge development snapshots of Cassandra are available from Jenkins continuous integration: + http://cassci.datastax.com/job/trunk/lastSuccessfulBuild/";>trunk and + http://cassci.datastax.com/job/cassandra-2.0/lastSuccessfulBuild/";>2.0. Modified: cassandra/site/src/content/download/index.html URL: http://svn.apache.org/viewvc/cassandra/site/src/content/download/index.html?rev=1566726&r1=1566725&r2=1566726&view=diff == --- cassandra/site/src/content/download/index.html (original) +++ cassandra/site/src/content/download/index.html Mon Feb 10 20:12:29 2014 @@ -158,8 +158,9 @@ - Bleeding edge development snapshots of Cassandra are available from - https://builds.apache.org/job/Cassandra/lastSuccessfulBuild/artifact/cassandra/build/";>Jenkins continuous integration. + Bleeding edge development snapshots of Cassandra are available from Jenkins continuous integration: + http://cassci.datastax.com/job/trunk/lastSuccessfulBuild/";>trunk and + http://cassci.datastax.com/job/cassandra-2.0/lastSuccessfulBuild/";>2.0.
[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] [Created] (CASSANDRA-6686) Update download page with snapshot build links
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-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] [Assigned] (CASSANDRA-6654) Droppable tombstones are not being removed from LCS table despite being above 20%
[
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 map,
> last timestamp,
> paid boolean,
> sku_time map,
> values map,
> 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)
[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
Authored: Mon Feb 10 18:34:43 2014 +0100
Committer: Marcus Eriksson
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);
List 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
Authored: Mon Feb 10 18:32:06 2014 +0100
Committer: Marcus Eriksson
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/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
Authored: Mon Feb 10 18:34:43 2014 +0100
Committer: Marcus Eriksson
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);
List rows;
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
Authored: Mon Feb 10 18:32:06 2014 +0100
Committer: Marcus Eriksson
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);
[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 Authored: Mon Feb 10 18:35:41 2014 +0100 Committer: Marcus Eriksson 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 --
[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
Authored: Mon Feb 10 18:32:06 2014 +0100
Committer: Marcus Eriksson
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);
[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)
[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)
[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 Authored: Mon Feb 10 09:37:56 2014 -0600 Committer: Brandon Williams 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 Authored: Mon Feb 10 09:37:43 2014 -0600 Committer: Brandon Williams 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
Authored: Mon Feb 10 09:36:42 2014 -0600
Committer: Brandon Williams
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)
[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
Authored: Mon Feb 10 09:36:42 2014 -0600
Committer: Brandon Williams
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 Authored: Mon Feb 10 09:37:43 2014 -0600 Committer: Brandon Williams 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 --
[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
Authored: Mon Feb 10 09:36:42 2014 -0600
Committer: Brandon Williams
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] [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-tabpanel&focusedCommentId=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)
[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-tabpanel&focusedCommentId=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] [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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-6572) Workload recording / playback
[ https://issues.apache.org/jira/browse/CASSANDRA-6572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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-6679) CleanupTest occasional failure in 1.2
[
https://issues.apache.org/jira/browse/CASSANDRA-6679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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-6685) Nodes never bootstrap if schema is empty
[
https://issues.apache.org/jira/browse/CASSANDRA-6685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-6685) Nodes never bootstrap if schema is empty
[
https://issues.apache.org/jira/browse/CASSANDRA-6685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Resolved] (CASSANDRA-6663) Connecting to a Raspberry PI Cassandra Cluster crashes the node being connected to
[
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 "", line 1, in
> 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': ,
> '_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': ,
> 'compression': None,
> 'contact_points': ['192.168.200.151'],
> 'control_connection': 0x106168cd0>,
> 'control_connection_timeout': 2.0,
> 'cql_version': None,
> 'executor': 0x106148410>,
> 'load_balancing_policy': 0x104adae50>,
> 'max_schema_agreement_wait': 10,
> 'metadata': ,
> 'metrics_enabled': False,
> 'port': 9042,
> 'scheduler': ,
> 'sessions': <_weakrefset.WeakSet object at 0x106148750>,
> 'sockopts': None,
> 'ssl_options': None}
> >>>
> {noformat}
--
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] [Commented] (CASSANDRA-6572) Workload recording / playback
[ https://issues.apache.org/jira/browse/CASSANDRA-6572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [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-tabpanel&focusedCommentId=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] [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] [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] [Updated] (CASSANDRA-6679) CleanupTest occasional failure in 1.2
[
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, ), 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] [Commented] (CASSANDRA-6475) Control nodetool history logging directory
[
https://issues.apache.org/jira/browse/CASSANDRA-6475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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= ...}}
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-5732) Can not query secondary index
[ 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 > - > > 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] [Comment Edited] (CASSANDRA-6467) Hadoop CQL3 example is throwing an Exception
[ https://issues.apache.org/jira/browse/CASSANDRA-6467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-5732) Can not query secondary index
[ https://issues.apache.org/jira/browse/CASSANDRA-5732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Commented] (CASSANDRA-6467) Hadoop CQL3 example is throwing an Exception
[ https://issues.apache.org/jira/browse/CASSANDRA-6467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [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-6684) Count fails with Illegal Capacity: -1
[ https://issues.apache.org/jira/browse/CASSANDRA-6684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Comment Edited] (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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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] [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-tabpanel&focusedCommentId=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] [Resolved] (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 ] 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-tabpanel&focusedCommentId=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] [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] [Created] (CASSANDRA-6684) Count fails with Illegal Capacity: -1
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] [Created] (CASSANDRA-6683) BADNESS_THRESHOLD does not working correctly with DynamicEndpointSnitch
Kirill Bogdanov created CASSANDRA-6683:
--
Summary: 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
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)
