[jira] [Commented] (CASSANDRA-2388) ColumnFamilyRecordReader fails for a given split because a host is down, even if records could reasonably be read from other replica.
[ https://issues.apache.org/jira/browse/CASSANDRA-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100093#comment-13100093 ] Mck SembWever commented on CASSANDRA-2388: -- In the meantime could we make this behavior configurable. eg replace CFRR:176 with something like {noformat} if(ConfigHelper.isDataLocalityDisabled()) { return split.getLocations()[0]; } else { throw new UnsupportedOperationException(no local connection available); }{noformat} ColumnFamilyRecordReader fails for a given split because a host is down, even if records could reasonably be read from other replica. - Key: CASSANDRA-2388 URL: https://issues.apache.org/jira/browse/CASSANDRA-2388 Project: Cassandra Issue Type: Bug Components: Hadoop Affects Versions: 0.6 Reporter: Eldon Stegall Assignee: Mck SembWever Labels: hadoop, inputformat Fix For: 0.8.6 Attachments: 0002_On_TException_try_next_split.patch, CASSANDRA-2388-addition1.patch, CASSANDRA-2388-extended.patch, CASSANDRA-2388.patch, CASSANDRA-2388.patch, CASSANDRA-2388.patch, CASSANDRA-2388.patch ColumnFamilyRecordReader only tries the first location for a given split. We should try multiple locations for a given split. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2882) describe_ring should include datacenter/topology information
[ https://issues.apache.org/jira/browse/CASSANDRA-2882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Guzman updated CASSANDRA-2882: --- Attachment: 0001-adding-an-additional-parameter-to-the-TokenRange-res.patch v1 patch adding datacenter info and port where possible. needs some cleanup and review. describe_ring should include datacenter/topology information Key: CASSANDRA-2882 URL: https://issues.apache.org/jira/browse/CASSANDRA-2882 Project: Cassandra Issue Type: Improvement Components: API, Core Reporter: Mark Guzman Assignee: Pavel Yaskevich Priority: Minor Labels: lhf Fix For: 1.0 Attachments: 0001-adding-an-additional-parameter-to-the-TokenRange-res.patch describe_ring is great for getting a list of nodes in the cluster, but it doesn't provide any information about the network topology which prevents it's use in a multi-dc setup. It would be nice if we added another list to the TokenRange object containing the DC information. Optimally I could have ask any Cassandra node for this information and on the client-side prefer local nodes but be able to fail to remote nodes without requiring another lookup. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2961) Expire dead gossip states based on time
[ https://issues.apache.org/jira/browse/CASSANDRA-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100123#comment-13100123 ] Jérémy Sevellec commented on CASSANDRA-2961: I found why i have make 2 call of addExpireTimeIfFound into SS instead of calling it into excise : There is 3 calls to excise in SS : handleStateLeft, handleStateRemoving and... removeToken. In removeToken, we don't have the pieces of the VV which contain expireTime. So we can't extract an expireTime. so there is 3 possibilities : - modify excise to add pieces parameter, set it to null in the removeToken call and manage the case if pieces is null. I find this solution not so beautiful but will work. - refactor and create 2 method signature of excise : one with pieces parameter and one without. - keep as it is. It's as you want. Tell me what is your preference (or another). Expire dead gossip states based on time --- Key: CASSANDRA-2961 URL: https://issues.apache.org/jira/browse/CASSANDRA-2961 Project: Cassandra Issue Type: Improvement Affects Versions: 1.0 Reporter: Brandon Williams Priority: Minor Fix For: 1.0 Attachments: trunk-2961-v2.patch, trunk-2961.patch Currently dead states are held until aVeryLongTime, 3 days. The problem is that if a node reboots within this period, it begins a new 3 days and will repopulate the ring with the dead state. While mostly harmless, perpetuating the state forever is at least wasting a small amount of bandwidth. Instead, we can expire states based on a ttl, which will require that the cluster be loosely time synced; within the quarantine period of 60s. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1166564 - in /cassandra/trunk: CHANGES.txt NEWS.txt doc/cql/CQL.textile src/java/org/apache/cassandra/cql/CreateColumnFamilyStatement.java test/system/test_cql.py
Author: slebresne Date: Thu Sep 8 08:20:18 2011 New Revision: 1166564 URL: http://svn.apache.org/viewvc?rev=1166564view=rev Log: Update CQL type names to match expected (SQL) behavior patch by jbellis; reviewed by slebresne for CASSANDRA-3149 Modified: cassandra/trunk/CHANGES.txt cassandra/trunk/NEWS.txt cassandra/trunk/doc/cql/CQL.textile cassandra/trunk/src/java/org/apache/cassandra/cql/CreateColumnFamilyStatement.java cassandra/trunk/test/system/test_cql.py Modified: cassandra/trunk/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/trunk/CHANGES.txt?rev=1166564r1=1166563r2=1166564view=diff == --- cassandra/trunk/CHANGES.txt (original) +++ cassandra/trunk/CHANGES.txt Thu Sep 8 08:20:18 2011 @@ -66,6 +66,7 @@ (CASSANDRA-3148) * fix inconsistency of the CLI syntax when {} should be used instead of [{}] (CASSANDRA-3119) + * rename CQL type names to match expected SQL behavior (CASSANDRA-3149) 0.8.5 * fix NPE when encryption_options is unspecified (CASSANDRA-3007) Modified: cassandra/trunk/NEWS.txt URL: http://svn.apache.org/viewvc/cassandra/trunk/NEWS.txt?rev=1166564r1=1166563r2=1166564view=diff == --- cassandra/trunk/NEWS.txt (original) +++ cassandra/trunk/NEWS.txt Thu Sep 8 08:20:18 2011 @@ -8,6 +8,8 @@ Upgrading - the compaction_thread_priority setting has been removed from cassandra.yaml (use compaction_throughput_mb_per_sec to throttle compaction instead) +- CQL types bytea and date were renamed to blob and timestamp, respectively, + to conform with SQL norms Features @@ -40,6 +42,10 @@ Features easier/possible to repair a full cluster without any work duplication by running this command on every node of the cluster. +New data types +-- +- decimal + Other - - Hinted Handoff is substantially more robust, with the result that Modified: cassandra/trunk/doc/cql/CQL.textile URL: http://svn.apache.org/viewvc/cassandra/trunk/doc/cql/CQL.textile?rev=1166564r1=1166563r2=1166564view=diff == --- cassandra/trunk/doc/cql/CQL.textile (original) +++ cassandra/trunk/doc/cql/CQL.textile Thu Sep 8 08:20:18 2011 @@ -265,15 +265,19 @@ CREATE ... (KEY type PRIMARY KEY, na It is possible to assign columns a type during column family creation. Columns configured with a type are validated accordingly when a write occurs. Column types are specified as a parenthesized, comma-separated list of column term and type pairs. The list of recognized types are: |_. type|_. description| -|bytea|Arbitrary bytes (no validation)| |ascii|ASCII character string| +|bigint|8-byte long| +|blob|Arbitrary bytes (no validation)| +|boolean|true or false| +|counter|Counter column, (8-byte long)| +|decimal|Variable-precision decimal| +|double|8-byte floating point| +|float|4-byte floating point| |text|UTF8 encoded string| -|varchar|UTF8 encoded string| +|timestamp|Date + Time, encoded as 8 bytes since epoch| |uuid|Type 1, or type 4 UUID| +|varchar|UTF8 encoded string| |varint|Arbitrary-precision integer| -|int|8-byte long (same as bigint)| -|bigint|8-byte long| -|counter|Counter column, (8-byte long)| _Note: In addition to the recognized types listed above, it is also possible to supply a string containing the name of a class (a sub-class of @AbstractType@), either fully qualified, or relative to the @org.apache.cassandra.db.marshal@ package._ @@ -380,8 +384,9 @@ Versioning of the CQL language adheres t h1. Changes pre. -Thu, 07 Sep 2011 09:01:00 -0500 - Jonathan Ellis +Wed, 07 Sep 2011 09:01:00 -0500 - Jonathan Ellis * Updated version to 2.0; Documented row-based count() + * Updated list of supported data types Wed, 10 Aug 2011 11:22:00 -0500 - Eric Evans * Improved INSERT vs. UPDATE wording. Modified: cassandra/trunk/src/java/org/apache/cassandra/cql/CreateColumnFamilyStatement.java URL: http://svn.apache.org/viewvc/cassandra/trunk/src/java/org/apache/cassandra/cql/CreateColumnFamilyStatement.java?rev=1166564r1=1166563r2=1166564view=diff == --- cassandra/trunk/src/java/org/apache/cassandra/cql/CreateColumnFamilyStatement.java (original) +++ cassandra/trunk/src/java/org/apache/cassandra/cql/CreateColumnFamilyStatement.java Thu Sep 8 08:20:18 2011 @@ -63,20 +63,20 @@ public class CreateColumnFamilyStatement static { -comparators.put(bytea, BytesType); comparators.put(ascii, AsciiType); -comparators.put(text, UTF8Type); -comparators.put(varchar, UTF8Type); -comparators.put(varint, IntegerType); -comparators.put(int, LongType); comparators.put(bigint, LongType); -comparators.put(uuid, UUIDType);
[jira] [Commented] (CASSANDRA-1236) when I start up the cassandra-cli, a ClassNotFoundException occured:java.lang.ClassNotFoundException: org.apache.cassandra.cli.CliMain
[ https://issues.apache.org/jira/browse/CASSANDRA-1236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100153#comment-13100153 ] Smartree commented on CASSANDRA-1236: - Need the CASSANDRA_HOME system variable, or Run the bat in CMD from Directory of CASSANDRA_HOMEbin\cassandra-cli when I start up the cassandra-cli, a ClassNotFoundException occured:java.lang.ClassNotFoundException: org.apache.cassandra.cli.CliMain -- Key: CASSANDRA-1236 URL: https://issues.apache.org/jira/browse/CASSANDRA-1236 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.6.2 Environment: windows XP Reporter: ialand Assignee: Gary Dusbabek Priority: Minor Fix For: 0.6.4 Attachments: cassandra-cli After start up the cassandra server, I went to the bin/ directory and run the cassandra-cli, but there's an Exception throwed out, I have set the CASSANDRA_HOME system variable, I don't know why Exception in thread main java.lang.NoClassDefFoundError: org/apache/cassandra/cli/CliMain Caused by: java.lang.ClassNotFoundException: org.apache.cassandra.cli.CliMain at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3149) Update CQL type names to match expected (SQL) behavor
[ https://issues.apache.org/jira/browse/CASSANDRA-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100172#comment-13100172 ] Hudson commented on CASSANDRA-3149: --- Integrated in Cassandra #1088 (See [https://builds.apache.org/job/Cassandra/1088/]) Update CQL type names to match expected (SQL) behavior patch by jbellis; reviewed by slebresne for CASSANDRA-3149 slebresne : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1166564 Files : * /cassandra/trunk/CHANGES.txt * /cassandra/trunk/NEWS.txt * /cassandra/trunk/doc/cql/CQL.textile * /cassandra/trunk/src/java/org/apache/cassandra/cql/CreateColumnFamilyStatement.java * /cassandra/trunk/test/system/test_cql.py Update CQL type names to match expected (SQL) behavor - Key: CASSANDRA-3149 URL: https://issues.apache.org/jira/browse/CASSANDRA-3149 Project: Cassandra Issue Type: Improvement Affects Versions: 0.8.0 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Labels: cql Fix For: 1.0 Attachments: 3149.txt As discussed in CASSANDRA-3031, we should make the following changes: - rename bytea to blob - rename date to timestamp - remove int, pending addition of CASSANDRA-3031 (bigint and varint will be unchanged) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2851) hex-to-bytes conversion accepts invalid inputs silently
[ https://issues.apache.org/jira/browse/CASSANDRA-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100184#comment-13100184 ] Sylvain Lebresne commented on CASSANDRA-2851: - bq. Sounds like the problem is thinking of this as a generic hex conversion function, rather than as hex that specifically represents bytes. Well, in a way those methods never pretended being generic hex to *bits* conversion functions since they are called hex2bytes and bytes2hex. I still think that the correct behavior for hex2bytes is to throw an exception on odd sized input. And that CASSANDRA-1411 was a mistake: yes I understand that it's annoying the first time you use '0' as token to get an exception and to have to write '00', but if you had written '0', there is a good chance you had missed the meaning of the input, i.e that it is an hex string representing a byte array. Now changing that behavior would not be backward compatible, so I wonder if we really should do anything here. I would be in favor however to refactor the code slightly so that hex2bytes do throw an exception on odd sized input (it would be fine if the method was named hex2bits, but it's fishy with hex2bytes) and to move the code that pads the input into ByteOrderedPartitioner, since that is what it was meant to: simplify the input of tokens. hex-to-bytes conversion accepts invalid inputs silently --- Key: CASSANDRA-2851 URL: https://issues.apache.org/jira/browse/CASSANDRA-2851 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.6, 0.8.1 Reporter: David Allsopp Priority: Minor Fix For: 1.0 Attachments: cassandra-2851.diff FBUtilities.hexToBytes() has a minor bug - it copes with single-character inputs by prepending 0, which is OK - but it does this for any input with an odd number of characters, which is probably incorrect. {noformat} if (str.length() % 2 == 1) str = 0 + str; {noformat} Given 'fff' as an input, can we really assume that this should be '0fff'? Isn't this just an error? Add the following to FBUtilitiesTest to demonstrate: {noformat} String[] badvalues = new String[]{000, fff}; for (int i = 0; i badvalues.length; i++) try { FBUtilities.hexToBytes(badvalues[i]); fail(Invalid hex value accepted+badvalues[i]); } catch (Exception e){} {noformat} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2472) CQL 1.1
[ https://issues.apache.org/jira/browse/CASSANDRA-2472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100186#comment-13100186 ] Sylvain Lebresne commented on CASSANDRA-2472: - I think this is now called CQL 2.0. Moreover the remaining subtasks will be for another version, so maybe it worth splitting/updating that meta-ticket. CQL 1.1 --- Key: CASSANDRA-2472 URL: https://issues.apache.org/jira/browse/CASSANDRA-2472 Project: Cassandra Issue Type: Improvement Components: API, Core Reporter: Eric Evans Labels: cql Fix For: 1.0 Master ticket for issues relating to CQL 1.1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2922) Move SimpleAuthenticator and SimpleAuthority to examples/
[ https://issues.apache.org/jira/browse/CASSANDRA-2922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100188#comment-13100188 ] Sylvain Lebresne commented on CASSANDRA-2922: - I'm leaving this for 1.0 post freeze because it's not really a new feature per se and has basically no change of screwing things up. Feel free to object that decision. However, the attached patch doesn't seems to do at all what it should. Move SimpleAuthenticator and SimpleAuthority to examples/ - Key: CASSANDRA-2922 URL: https://issues.apache.org/jira/browse/CASSANDRA-2922 Project: Cassandra Issue Type: Task Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 1.0 Attachments: 2922.txt We've provided SimpleAuthenticator and SimpleAuthority, toy file-based authentication and authorization mechanisms, since CASSANDRA-547. These are NOT production ready (even non-experts can tell the encryption is a joke) but newcomers don't always realize this. Let's move them to examples/ instead. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2936) improve dependency situation between JDBC driver and Cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100196#comment-13100196 ] Sylvain Lebresne commented on CASSANDRA-2936: - Is there a reason this is not closed ? Is it in waiting for the drivers to be move off of svn ? improve dependency situation between JDBC driver and Cassandra -- Key: CASSANDRA-2936 URL: https://issues.apache.org/jira/browse/CASSANDRA-2936 Project: Cassandra Issue Type: Improvement Components: API, Core Affects Versions: 0.8.1 Reporter: Eric Evans Assignee: Eric Evans Priority: Minor Labels: cql Fix For: 1.0 Attachments: 2936-cleanup.txt, v1-0001-CASSANDRA-2936-rename-cookie-jar-clientutil.txt, v3-0001-CASSANDRA-2936-create-package-for-CQL-term-marshaling.txt, v3-0002-convert-drivers-and-tests-to-o.a.c.cql.term.txt, v3-0003-remove-extraneous-methods-from-o.a.c.db.marshal-classe.txt, v3-0004-make-better-reuse-of-new-classes.txt, v3-0005-create-jar-file.txt The JDBC jar currently depends on the {{apache-cassandra-$version}} jar, despite the fact that it only (directly) uses a handful of Cassandra's classes. In a perfect world, we'd break those classes out into their own jar which both the JDBC driver and Cassandra (ala {{apache-cassandra-$version.jar}}) could depend on. However, the classes used directly don't fall out to anything that makes much sense organizationally (short of creating a {{apache-cassandra-misc-$version.jar}}), and the situation only gets worse when you take into account all of the transitive dependencies. See CASSANDRA-2761 for more background, in particular ([this|https://issues.apache.org/jira/browse/CASSANDRA-2761?focusedCommentId=13048734page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13048734] and [this|https://issues.apache.org/jira/browse/CASSANDRA-2761?focusedCommentId=13050884page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13050884]) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2882) describe_ring should include datacenter/topology information
[ https://issues.apache.org/jira/browse/CASSANDRA-2882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100197#comment-13100197 ] Pavel Yaskevich commented on CASSANDRA-2882: Hi Mark, thanks for the patch but most of it's size are line-ending modifications and unrelated duplication of the comments and statements, can you please re-configure your IDE and attach updated version of the patch only with actual modifications related to describe_ring? describe_ring should include datacenter/topology information Key: CASSANDRA-2882 URL: https://issues.apache.org/jira/browse/CASSANDRA-2882 Project: Cassandra Issue Type: Improvement Components: API, Core Reporter: Mark Guzman Assignee: Pavel Yaskevich Priority: Minor Labels: lhf Fix For: 1.1 Attachments: 0001-adding-an-additional-parameter-to-the-TokenRange-res.patch describe_ring is great for getting a list of nodes in the cluster, but it doesn't provide any information about the network topology which prevents it's use in a multi-dc setup. It would be nice if we added another list to the TokenRange object containing the DC information. Optimally I could have ask any Cassandra node for this information and on the client-side prefer local nodes but be able to fail to remote nodes without requiring another lookup. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[Cassandra Wiki] Update of API by MarcoMatarazzo
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The API page has been changed by MarcoMatarazzo: http://wiki.apache.org/cassandra/API?action=diffrev1=27rev2=28 Comment: Cassandra 0.7 seems to implement Mutation with vectors and not lists, to my trials. === batch_mutate === . `batch_mutate(mutation_map, consistency_level)` - Executes the specified mutations on the keyspace. `mutation_map` is a `mapstring, mapstring, listMutation`; the outer map maps the key to the inner map, which maps the column family to the `Mutation`; can be read as: `mapkey : string, mapcolumn_family : string, listMutation`. To be more specific, the outer map key is a row key, the inner map key is the column family name. + Executes the specified mutations on the keyspace. `mutation_map` is a `mapstring, mapstring, vectorMutation`; the outer map maps the key to the inner map, which maps the column family to the `Mutation`; can be read as: `mapkey : string, mapcolumn_family : string, vectorMutation`. To be more specific, the outer map key is a row key, the inner map key is the column family name. A `Mutation` specifies either columns to insert or columns to delete. See `Mutation` and `Deletion` above for more details.
svn commit: r1166630 - /cassandra/tags/cassandra-0.8.5/
Author: slebresne Date: Thu Sep 8 11:19:13 2011 New Revision: 1166630 URL: http://svn.apache.org/viewvc?rev=1166630view=rev Log: Creating 0.8.5 tag Added: cassandra/tags/cassandra-0.8.5/ (props changed) - copied from r1165225, cassandra/branches/cassandra-0.8/ Propchange: cassandra/tags/cassandra-0.8.5/ -- --- svn:ignore (added) +++ svn:ignore Thu Sep 8 11:19:13 2011 @@ -0,0 +1,8 @@ +.classpath +.project +.settings +temp-testng-customsuite.xml +build +build.properties +.idea +out Propchange: cassandra/tags/cassandra-0.8.5/ -- --- svn:mergeinfo (added) +++ svn:mergeinfo Thu Sep 8 11:19:13 2011 @@ -0,0 +1,12 @@ +/cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1131291 +/cassandra/branches/cassandra-0.7:1026516-1163782 +/cassandra/branches/cassandra-0.7.0:1053690-1055654 +/cassandra/branches/cassandra-0.8:1090934-1125013,1125041 +/cassandra/branches/cassandra-0.8.0:1125021-1130369 +/cassandra/tags/cassandra-0.7.0-rc3:1051699-1053689 +/cassandra/tags/cassandra-0.8.0-rc1:1102511-1125020 +/cassandra/trunk:1129049-1129050,1129065,1151625,1152416,1153189 +/incubator/cassandra/branches/cassandra-0.3:774578-796573 +/incubator/cassandra/branches/cassandra-0.4:810145-834239,834349-834350 +/incubator/cassandra/branches/cassandra-0.5:72-915439 +/incubator/cassandra/branches/cassandra-0.6:911237-922688
svn commit: r1166648 - in /cassandra/site: publish/download/index.html publish/index.html src/settings.py
Author: slebresne Date: Thu Sep 8 12:12:51 2011 New Revision: 1166648 URL: http://svn.apache.org/viewvc?rev=1166648view=rev Log: Update site for 0.8.5 release Modified: cassandra/site/publish/download/index.html cassandra/site/publish/index.html cassandra/site/src/settings.py Modified: cassandra/site/publish/download/index.html URL: http://svn.apache.org/viewvc/cassandra/site/publish/download/index.html?rev=1166648r1=1166647r2=1166648view=diff == --- cassandra/site/publish/download/index.html (original) +++ cassandra/site/publish/download/index.html Thu Sep 8 12:12:51 2011 @@ -73,31 +73,31 @@ p - The latest stable release of Apache Cassandra is 0.8.4 - (released on 2011-08-11). iIf you're just + The latest stable release of Apache Cassandra is 0.8.5 + (released on 2011-09-08). iIf you're just starting out, download this one./i /p ul li a class=filename - href=http://www.apache.org/dyn/closer.cgi?path=/cassandra/0.8.4/apache-cassandra-0.8.4-bin.tar.gz; + href=http://www.apache.org/dyn/closer.cgi?path=/cassandra/0.8.5/apache-cassandra-0.8.5-bin.tar.gz; onclick=javascript: pageTracker._trackPageview('/clicks/binary_download'); - apache-cassandra-0.8.4-bin.tar.gz + apache-cassandra-0.8.5-bin.tar.gz /a -[a href=http://www.apache.org/dist/cassandra/0.8.4/apache-cassandra-0.8.4-bin.tar.gz.asc;PGP/a] -[a href=http://www.apache.org/dist/cassandra/0.8.4/apache-cassandra-0.8.4-bin.tar.gz.md5;MD5/a] -[a href=http://www.apache.org/dist/cassandra/0.8.4/apache-cassandra-0.8.4-bin.tar.gz.sha;SHA1/a] +[a href=http://www.apache.org/dist/cassandra/0.8.5/apache-cassandra-0.8.5-bin.tar.gz.asc;PGP/a] +[a href=http://www.apache.org/dist/cassandra/0.8.5/apache-cassandra-0.8.5-bin.tar.gz.md5;MD5/a] +[a href=http://www.apache.org/dist/cassandra/0.8.5/apache-cassandra-0.8.5-bin.tar.gz.sha;SHA1/a] /li li a class=filename - href=http://www.apache.org/dyn/closer.cgi?path=/cassandra/0.8.4/apache-cassandra-0.8.4-src.tar.gz; + href=http://www.apache.org/dyn/closer.cgi?path=/cassandra/0.8.5/apache-cassandra-0.8.5-src.tar.gz; onclick=javascript: pageTracker._trackPageview('/clicks/source_download'); - apache-cassandra-0.8.4-src.tar.gz + apache-cassandra-0.8.5-src.tar.gz /a -[a href=http://www.apache.org/dist/cassandra/0.8.4/apache-cassandra-0.8.4-src.tar.gz.asc;PGP/a] -[a href=http://www.apache.org/dist/cassandra/0.8.4/apache-cassandra-0.8.4-src.tar.gz.md5;MD5/a] -[a href=http://www.apache.org/dist/cassandra/0.8.4/apache-cassandra-0.8.4-src.tar.gz.sha;SHA1/a] +[a href=http://www.apache.org/dist/cassandra/0.8.5/apache-cassandra-0.8.5-src.tar.gz.asc;PGP/a] +[a href=http://www.apache.org/dist/cassandra/0.8.5/apache-cassandra-0.8.5-src.tar.gz.md5;MD5/a] +[a href=http://www.apache.org/dist/cassandra/0.8.5/apache-cassandra-0.8.5-src.tar.gz.sha;SHA1/a] /li /ul @@ -162,15 +162,15 @@ New users to Cassandra should be sure to h2Download/h2 div class=inner rc p -The latest release is b0.8.4/b -span class=relnotes(a href=https://svn.apache.org/repos/asf/cassandra/tags/cassandra-0.8.4/CHANGES.txt;Changes/a)/span +The latest release is b0.8.5/b +span class=relnotes(a href=https://svn.apache.org/repos/asf/cassandra/tags/cassandra-0.8.5/CHANGES.txt;Changes/a)/span /p p a class=filename - href=http://www.apache.org/dyn/closer.cgi?path=/cassandra/0.8.4/apache-cassandra-0.8.4-bin.tar.gz; + href=http://www.apache.org/dyn/closer.cgi?path=/cassandra/0.8.5/apache-cassandra-0.8.5-bin.tar.gz; onclick=javascript: pageTracker._trackPageview('/clicks/binary_download'); - apache-cassandra-0.8.4-bin.tar.gz + apache-cassandra-0.8.5-bin.tar.gz /a /p Modified: cassandra/site/publish/index.html URL: http://svn.apache.org/viewvc/cassandra/site/publish/index.html?rev=1166648r1=1166647r2=1166648view=diff == --- cassandra/site/publish/index.html (original) +++ cassandra/site/publish/index.html Thu Sep 8 12:12:51 2011 @@ -82,15 +82,15 @@ h2Download/h2 div class=inner rc p -The latest release is b0.8.4/b -span class=relnotes(a href=https://svn.apache.org/repos/asf/cassandra/tags/cassandra-0.8.4/CHANGES.txt;Changes/a)/span +The latest release is b0.8.5/b +span class=relnotes(a href=https://svn.apache.org/repos/asf/cassandra/tags/cassandra-0.8.5/CHANGES.txt;Changes/a)/span /p p a class=filename - href=http://www.apache.org/dyn/closer.cgi?path=/cassandra/0.8.4/apache-cassandra-0.8.4-bin.tar.gz; + href=http://www.apache.org/dyn/closer.cgi?path=/cassandra/0.8.5/apache-cassandra-0.8.5-bin.tar.gz; onclick=javascript:
[jira] [Commented] (CASSANDRA-2388) ColumnFamilyRecordReader fails for a given split because a host is down, even if records could reasonably be read from other replica.
[ https://issues.apache.org/jira/browse/CASSANDRA-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100281#comment-13100281 ] Jonathan Ellis commented on CASSANDRA-2388: --- Should we just revert the change for now? ColumnFamilyRecordReader fails for a given split because a host is down, even if records could reasonably be read from other replica. - Key: CASSANDRA-2388 URL: https://issues.apache.org/jira/browse/CASSANDRA-2388 Project: Cassandra Issue Type: Bug Components: Hadoop Affects Versions: 0.6 Reporter: Eldon Stegall Assignee: Mck SembWever Labels: hadoop, inputformat Fix For: 0.8.6 Attachments: 0002_On_TException_try_next_split.patch, CASSANDRA-2388-addition1.patch, CASSANDRA-2388-extended.patch, CASSANDRA-2388.patch, CASSANDRA-2388.patch, CASSANDRA-2388.patch, CASSANDRA-2388.patch ColumnFamilyRecordReader only tries the first location for a given split. We should try multiple locations for a given split. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2851) hex-to-bytes conversion accepts invalid inputs silently
[ https://issues.apache.org/jira/browse/CASSANDRA-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100287#comment-13100287 ] Jonathan Ellis commented on CASSANDRA-2851: --- That sounds reasonable. hex-to-bytes conversion accepts invalid inputs silently --- Key: CASSANDRA-2851 URL: https://issues.apache.org/jira/browse/CASSANDRA-2851 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.6, 0.8.1 Reporter: David Allsopp Priority: Minor Fix For: 1.1 Attachments: cassandra-2851.diff FBUtilities.hexToBytes() has a minor bug - it copes with single-character inputs by prepending 0, which is OK - but it does this for any input with an odd number of characters, which is probably incorrect. {noformat} if (str.length() % 2 == 1) str = 0 + str; {noformat} Given 'fff' as an input, can we really assume that this should be '0fff'? Isn't this just an error? Add the following to FBUtilitiesTest to demonstrate: {noformat} String[] badvalues = new String[]{000, fff}; for (int i = 0; i badvalues.length; i++) try { FBUtilities.hexToBytes(badvalues[i]); fail(Invalid hex value accepted+badvalues[i]); } catch (Exception e){} {noformat} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-1236) when I start up the cassandra-cli, a ClassNotFoundException occured:java.lang.ClassNotFoundException: org.apache.cassandra.cli.CliMain
[ https://issues.apache.org/jira/browse/CASSANDRA-1236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100286#comment-13100286 ] Jonathan Ellis commented on CASSANDRA-1236: --- Smartree, 1) please submit changes as a patch generated by svn diff 2) adding lib/*.jar is done by cassandra.in.sh (the CASSANDRA_INCLUDE searched for at the beginning of -cli). There's no need to do it a second time in the cli script. when I start up the cassandra-cli, a ClassNotFoundException occured:java.lang.ClassNotFoundException: org.apache.cassandra.cli.CliMain -- Key: CASSANDRA-1236 URL: https://issues.apache.org/jira/browse/CASSANDRA-1236 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.6.2 Environment: windows XP Reporter: ialand Assignee: Gary Dusbabek Priority: Minor Fix For: 0.6.4 Attachments: cassandra-cli After start up the cassandra server, I went to the bin/ directory and run the cassandra-cli, but there's an Exception throwed out, I have set the CASSANDRA_HOME system variable, I don't know why Exception in thread main java.lang.NoClassDefFoundError: org/apache/cassandra/cli/CliMain Caused by: java.lang.ClassNotFoundException: org.apache.cassandra.cli.CliMain at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3157) After a short read, the wrong read command may be used
[ https://issues.apache.org/jira/browse/CASSANDRA-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-3157: Attachment: 3157.patch After a short read, the wrong read command may be used Key: CASSANDRA-3157 URL: https://issues.apache.org/jira/browse/CASSANDRA-3157 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.0 Attachments: 3157.patch In fetchRows, there is this code: {noformat} for (int i = 0; i commandsToSend.size(); i++) { ReadCallbackRow handler = readCallbacks.get(i); ReadCommand command = commands.get(i); {noformat} On the first iteration of fetchRows, commands == commandsToSend so this is ok, but on a short read, commandsToSend will only contain the command to retry so we'll pick up the wrong command on the last line. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-3157) After a short read, the wrong read command may be used
After a short read, the wrong read command may be used Key: CASSANDRA-3157 URL: https://issues.apache.org/jira/browse/CASSANDRA-3157 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.0 Attachments: 3157.patch In fetchRows, there is this code: {noformat} for (int i = 0; i commandsToSend.size(); i++) { ReadCallbackRow handler = readCallbacks.get(i); ReadCommand command = commands.get(i); {noformat} On the first iteration of fetchRows, commands == commandsToSend so this is ok, but on a short read, commandsToSend will only contain the command to retry so we'll pick up the wrong command on the last line. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2882) describe_ring should include datacenter/topology information
[ https://issues.apache.org/jira/browse/CASSANDRA-2882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Guzman updated CASSANDRA-2882: --- Attachment: 0001-cleaned-up-CASSANDRA-2882-patch.-now-with-less-white.patch Cleaned up version of the previous patch removing extraneous whitespace and line ending changes. This still includes the generated thrift classes. describe_ring should include datacenter/topology information Key: CASSANDRA-2882 URL: https://issues.apache.org/jira/browse/CASSANDRA-2882 Project: Cassandra Issue Type: Improvement Components: API, Core Reporter: Mark Guzman Assignee: Pavel Yaskevich Priority: Minor Labels: lhf Fix For: 1.1 Attachments: 0001-adding-an-additional-parameter-to-the-TokenRange-res.patch, 0001-cleaned-up-CASSANDRA-2882-patch.-now-with-less-white.patch describe_ring is great for getting a list of nodes in the cluster, but it doesn't provide any information about the network topology which prevents it's use in a multi-dc setup. It would be nice if we added another list to the TokenRange object containing the DC information. Optimally I could have ask any Cassandra node for this information and on the client-side prefer local nodes but be able to fail to remote nodes without requiring another lookup. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2882) describe_ring should include datacenter/topology information
[ https://issues.apache.org/jira/browse/CASSANDRA-2882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Guzman updated CASSANDRA-2882: --- Attachment: (was: 0001-cleaned-up-CASSANDRA-2882-patch.-now-with-less-white.patch) describe_ring should include datacenter/topology information Key: CASSANDRA-2882 URL: https://issues.apache.org/jira/browse/CASSANDRA-2882 Project: Cassandra Issue Type: Improvement Components: API, Core Reporter: Mark Guzman Assignee: Pavel Yaskevich Priority: Minor Labels: lhf Fix For: 1.1 Attachments: 0001-adding-an-additional-parameter-to-the-TokenRange-res.patch, 0001-final-cleaned-up-2882-changes.patch describe_ring is great for getting a list of nodes in the cluster, but it doesn't provide any information about the network topology which prevents it's use in a multi-dc setup. It would be nice if we added another list to the TokenRange object containing the DC information. Optimally I could have ask any Cassandra node for this information and on the client-side prefer local nodes but be able to fail to remote nodes without requiring another lookup. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-3158) Digest mismatch retries are not correctly versioned by StorageProxy
Digest mismatch retries are not correctly versioned by StorageProxy --- Key: CASSANDRA-3158 URL: https://issues.apache.org/jira/browse/CASSANDRA-3158 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.1 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 0.8.6 Attachments: 3158.txt -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2882) describe_ring should include datacenter/topology information
[ https://issues.apache.org/jira/browse/CASSANDRA-2882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100334#comment-13100334 ] Pavel Yaskevich commented on CASSANDRA-2882: Sorry I would like to see thrift auto-gen code removed from the patch especially because it's C# code, I will run `ant gen-thrift-java` myself when needed. describe_ring should include datacenter/topology information Key: CASSANDRA-2882 URL: https://issues.apache.org/jira/browse/CASSANDRA-2882 Project: Cassandra Issue Type: Improvement Components: API, Core Reporter: Mark Guzman Assignee: Pavel Yaskevich Priority: Minor Labels: lhf Fix For: 1.1 Attachments: 0001-adding-an-additional-parameter-to-the-TokenRange-res.patch, 0001-final-cleaned-up-2882-changes.patch describe_ring is great for getting a list of nodes in the cluster, but it doesn't provide any information about the network topology which prevents it's use in a multi-dc setup. It would be nice if we added another list to the TokenRange object containing the DC information. Optimally I could have ask any Cassandra node for this information and on the client-side prefer local nodes but be able to fail to remote nodes without requiring another lookup. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3158) Digest mismatch retries are not correctly versioned by StorageProxy
[ https://issues.apache.org/jira/browse/CASSANDRA-3158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-3158: -- Attachment: 3158.txt Digest mismatch retries are not correctly versioned by StorageProxy --- Key: CASSANDRA-3158 URL: https://issues.apache.org/jira/browse/CASSANDRA-3158 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.1 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 0.8.6 Attachments: 3158.txt -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2882) describe_ring should include datacenter/topology information
[ https://issues.apache.org/jira/browse/CASSANDRA-2882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Guzman updated CASSANDRA-2882: --- Attachment: 0001-final-cleaned-up-2882-changes.patch I lied with the last one. This is the final cleaned up version. describe_ring should include datacenter/topology information Key: CASSANDRA-2882 URL: https://issues.apache.org/jira/browse/CASSANDRA-2882 Project: Cassandra Issue Type: Improvement Components: API, Core Reporter: Mark Guzman Assignee: Pavel Yaskevich Priority: Minor Labels: lhf Fix For: 1.1 Attachments: 0001-adding-an-additional-parameter-to-the-TokenRange-res.patch, 0001-final-cleaned-up-2882-changes.patch describe_ring is great for getting a list of nodes in the cluster, but it doesn't provide any information about the network topology which prevents it's use in a multi-dc setup. It would be nice if we added another list to the TokenRange object containing the DC information. Optimally I could have ask any Cassandra node for this information and on the client-side prefer local nodes but be able to fail to remote nodes without requiring another lookup. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2882) describe_ring should include datacenter/topology information
[ https://issues.apache.org/jira/browse/CASSANDRA-2882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100336#comment-13100336 ] Mark Guzman commented on CASSANDRA-2882: Why is this being marked 1.1? The change is backward compatible, older clients will ignore the extra optional field and structure. I've tested with the ruby and a generated c# client. describe_ring should include datacenter/topology information Key: CASSANDRA-2882 URL: https://issues.apache.org/jira/browse/CASSANDRA-2882 Project: Cassandra Issue Type: Improvement Components: API, Core Reporter: Mark Guzman Assignee: Pavel Yaskevich Priority: Minor Labels: lhf Fix For: 1.1 Attachments: 0001-adding-an-additional-parameter-to-the-TokenRange-res.patch, 0001-final-cleaned-up-2882-changes.patch describe_ring is great for getting a list of nodes in the cluster, but it doesn't provide any information about the network topology which prevents it's use in a multi-dc setup. It would be nice if we added another list to the TokenRange object containing the DC information. Optimally I could have ask any Cassandra node for this information and on the client-side prefer local nodes but be able to fail to remote nodes without requiring another lookup. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2882) describe_ring should include datacenter/topology information
[ https://issues.apache.org/jira/browse/CASSANDRA-2882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100337#comment-13100337 ] Pavel Yaskevich commented on CASSANDRA-2882: Please remove auto-generated thrift code from your patch (attach as a separate file if you want). describe_ring should include datacenter/topology information Key: CASSANDRA-2882 URL: https://issues.apache.org/jira/browse/CASSANDRA-2882 Project: Cassandra Issue Type: Improvement Components: API, Core Reporter: Mark Guzman Assignee: Pavel Yaskevich Priority: Minor Labels: lhf Fix For: 1.1 Attachments: 0001-adding-an-additional-parameter-to-the-TokenRange-res.patch, 0001-final-cleaned-up-2882-changes.patch describe_ring is great for getting a list of nodes in the cluster, but it doesn't provide any information about the network topology which prevents it's use in a multi-dc setup. It would be nice if we added another list to the TokenRange object containing the DC information. Optimally I could have ask any Cassandra node for this information and on the client-side prefer local nodes but be able to fail to remote nodes without requiring another lookup. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2882) describe_ring should include datacenter/topology information
[ https://issues.apache.org/jira/browse/CASSANDRA-2882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100338#comment-13100338 ] Pavel Yaskevich commented on CASSANDRA-2882: Because today (8 Sept.) is a date of code-freeze, only bug fixes are going to be included from now on. describe_ring should include datacenter/topology information Key: CASSANDRA-2882 URL: https://issues.apache.org/jira/browse/CASSANDRA-2882 Project: Cassandra Issue Type: Improvement Components: API, Core Reporter: Mark Guzman Assignee: Pavel Yaskevich Priority: Minor Labels: lhf Fix For: 1.1 Attachments: 0001-adding-an-additional-parameter-to-the-TokenRange-res.patch, 0001-final-cleaned-up-2882-changes.patch describe_ring is great for getting a list of nodes in the cluster, but it doesn't provide any information about the network topology which prevents it's use in a multi-dc setup. It would be nice if we added another list to the TokenRange object containing the DC information. Optimally I could have ask any Cassandra node for this information and on the client-side prefer local nodes but be able to fail to remote nodes without requiring another lookup. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3157) After a short read, the wrong read command may be used
[ https://issues.apache.org/jira/browse/CASSANDRA-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100340#comment-13100340 ] Jonathan Ellis commented on CASSANDRA-3157: --- +1 on the fix. (is while-on-newline really an improvement?) After a short read, the wrong read command may be used Key: CASSANDRA-3157 URL: https://issues.apache.org/jira/browse/CASSANDRA-3157 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.0 Attachments: 3157.patch In fetchRows, there is this code: {noformat} for (int i = 0; i commandsToSend.size(); i++) { ReadCallbackRow handler = readCallbacks.get(i); ReadCommand command = commands.get(i); {noformat} On the first iteration of fetchRows, commands == commandsToSend so this is ok, but on a short read, commandsToSend will only contain the command to retry so we'll pick up the wrong command on the last line. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3157) After a short read, the wrong read command may be used
[ https://issues.apache.org/jira/browse/CASSANDRA-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100344#comment-13100344 ] Sylvain Lebresne commented on CASSANDRA-3157: - bq. is while-on-newline really an improvement? Felt more coherent with the coding style to have the bracket on its own line. But I don't have to commit it. After a short read, the wrong read command may be used Key: CASSANDRA-3157 URL: https://issues.apache.org/jira/browse/CASSANDRA-3157 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.0 Attachments: 3157.patch In fetchRows, there is this code: {noformat} for (int i = 0; i commandsToSend.size(); i++) { ReadCallbackRow handler = readCallbacks.get(i); ReadCommand command = commands.get(i); {noformat} On the first iteration of fetchRows, commands == commandsToSend so this is ok, but on a short read, commandsToSend will only contain the command to retry so we'll pick up the wrong command on the last line. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2882) describe_ring should include datacenter/topology information
[ https://issues.apache.org/jira/browse/CASSANDRA-2882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100352#comment-13100352 ] Pavel Yaskevich commented on CASSANDRA-2882: One last thing: please rebase - it can't be applied on the latest trunk. describe_ring should include datacenter/topology information Key: CASSANDRA-2882 URL: https://issues.apache.org/jira/browse/CASSANDRA-2882 Project: Cassandra Issue Type: Improvement Components: API, Core Reporter: Mark Guzman Assignee: Pavel Yaskevich Priority: Minor Labels: lhf Fix For: 1.1 Attachments: 0001-CASSANDRA-2882-patch-w-o-generated-files.patch, 0001-adding-an-additional-parameter-to-the-TokenRange-res.patch, 0001-final-cleaned-up-2882-changes.patch describe_ring is great for getting a list of nodes in the cluster, but it doesn't provide any information about the network topology which prevents it's use in a multi-dc setup. It would be nice if we added another list to the TokenRange object containing the DC information. Optimally I could have ask any Cassandra node for this information and on the client-side prefer local nodes but be able to fail to remote nodes without requiring another lookup. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1166716 - in /cassandra/trunk: CHANGES.txt src/java/org/apache/cassandra/service/StorageProxy.java
Author: slebresne Date: Thu Sep 8 14:36:53 2011 New Revision: 1166716 URL: http://svn.apache.org/viewvc?rev=1166716view=rev Log: After a short read, the wrong read command may be used patch by slebresne; reviewed by jbellis for CASSANDRA-3157 Modified: cassandra/trunk/CHANGES.txt cassandra/trunk/src/java/org/apache/cassandra/service/StorageProxy.java Modified: cassandra/trunk/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/trunk/CHANGES.txt?rev=1166716r1=1166715r2=1166716view=diff == --- cassandra/trunk/CHANGES.txt (original) +++ cassandra/trunk/CHANGES.txt Thu Sep 8 14:36:53 2011 @@ -24,7 +24,7 @@ * use lazy initialization instead of class initialization in NodeId (CASSANDRA-2953) * add paging to get_count (CASSANDRA-2894) - * fix short reads in [multi]get (CASSANDRA-2643) + * fix short reads in [multi]get (CASSANDRA-2643, 3157) * add optional compression for sstables (CASSANDRA-47, 3001, 3128) * add scheduler JMX metrics (CASSANDRA-2962) * add block level checksum for compressed data (CASSANDRA-1717) Modified: cassandra/trunk/src/java/org/apache/cassandra/service/StorageProxy.java URL: http://svn.apache.org/viewvc/cassandra/trunk/src/java/org/apache/cassandra/service/StorageProxy.java?rev=1166716r1=1166715r2=1166716view=diff == --- cassandra/trunk/src/java/org/apache/cassandra/service/StorageProxy.java (original) +++ cassandra/trunk/src/java/org/apache/cassandra/service/StorageProxy.java Thu Sep 8 14:36:53 2011 @@ -652,7 +652,7 @@ public class StorageProxy implements Sto { ReadCallbackRow handler = readCallbacks.get(i); Row row; -ReadCommand command = commands.get(i); +ReadCommand command = commandsToSend.get(i); try { long startTime2 = System.currentTimeMillis();
[jira] [Updated] (CASSANDRA-3158) Improve caching of same-version Messages on digest and repair paths
[ https://issues.apache.org/jira/browse/CASSANDRA-3158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-3158: -- Summary: Improve caching of same-version Messages on digest and repair paths (was: Digest mismatch retries are not correctly versioned by StorageProxy) Improve caching of same-version Messages on digest and repair paths --- Key: CASSANDRA-3158 URL: https://issues.apache.org/jira/browse/CASSANDRA-3158 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.1 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 0.8.6 Attachments: 3158.txt -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3158) Improve caching of same-version Messages on digest and repair paths
[ https://issues.apache.org/jira/browse/CASSANDRA-3158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-3158: -- Attachment: 3158-v2.txt v2 also lazy-initializes the caching producer for the initial digest reads, and updates comments Improve caching of same-version Messages on digest and repair paths --- Key: CASSANDRA-3158 URL: https://issues.apache.org/jira/browse/CASSANDRA-3158 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.1 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 0.8.6 Attachments: 3158-v2.txt, 3158.txt -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3158) Improve caching of same-version Messages on digest and repair paths
[ https://issues.apache.org/jira/browse/CASSANDRA-3158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100368#comment-13100368 ] Sylvain Lebresne commented on CASSANDRA-3158: - For the initial digest reads, it would be nice to use the CachingMessageProducer for the local digest read too. Improve caching of same-version Messages on digest and repair paths --- Key: CASSANDRA-3158 URL: https://issues.apache.org/jira/browse/CASSANDRA-3158 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.1 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 0.8.6 Attachments: 3158-v2.txt, 3158.txt -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-3159) Multiple classpath entries in the cassandra-all.jar
Multiple classpath entries in the cassandra-all.jar --- Key: CASSANDRA-3159 URL: https://issues.apache.org/jira/browse/CASSANDRA-3159 Project: Cassandra Issue Type: Bug Reporter: T Jake Luciani Assignee: Eric Evans Priority: Minor Fix For: 1.0 from CASSANDRA-2936 {code} Sep 8, 2011 8:47:45 AM java.util.jar.Attributes read WARNING: Duplicate name in Manifest: Class-Path. Ensure that the manifest does not have duplicate entries, and that blank lines separate individual sections in both your manifest and in the META-INF/MANIFEST.MF entry in the jar file. {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3158) Improve caching of same-version Messages on digest and repair paths
[ https://issues.apache.org/jira/browse/CASSANDRA-3158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100374#comment-13100374 ] Jonathan Ellis commented on CASSANDRA-3158: --- no Messages are created for local reads. Improve caching of same-version Messages on digest and repair paths --- Key: CASSANDRA-3158 URL: https://issues.apache.org/jira/browse/CASSANDRA-3158 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.1 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 0.8.6 Attachments: 3158-v2.txt, 3158.txt -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3158) Improve caching of same-version Messages on digest and repair paths
[ https://issues.apache.org/jira/browse/CASSANDRA-3158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100378#comment-13100378 ] Sylvain Lebresne commented on CASSANDRA-3158: - Oh right, my bad. Anyways, lgtm, +1. Improve caching of same-version Messages on digest and repair paths --- Key: CASSANDRA-3158 URL: https://issues.apache.org/jira/browse/CASSANDRA-3158 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.1 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 0.8.6 Attachments: 3158-v2.txt, 3158.txt -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3157) After a short read, the wrong read command may be used
[ https://issues.apache.org/jira/browse/CASSANDRA-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100382#comment-13100382 ] Hudson commented on CASSANDRA-3157: --- Integrated in Cassandra #1089 (See [https://builds.apache.org/job/Cassandra/1089/]) After a short read, the wrong read command may be used patch by slebresne; reviewed by jbellis for CASSANDRA-3157 slebresne : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1166716 Files : * /cassandra/trunk/CHANGES.txt * /cassandra/trunk/src/java/org/apache/cassandra/service/StorageProxy.java After a short read, the wrong read command may be used Key: CASSANDRA-3157 URL: https://issues.apache.org/jira/browse/CASSANDRA-3157 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.0 Attachments: 3157.patch In fetchRows, there is this code: {noformat} for (int i = 0; i commandsToSend.size(); i++) { ReadCallbackRow handler = readCallbacks.get(i); ReadCommand command = commands.get(i); {noformat} On the first iteration of fetchRows, commands == commandsToSend so this is ok, but on a short read, commandsToSend will only contain the command to retry so we'll pick up the wrong command on the last line. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3159) Multiple classpath entries in the cassandra-all.jar
[ https://issues.apache.org/jira/browse/CASSANDRA-3159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Evans updated CASSANDRA-3159: -- Attachment: v1-0001-CASSANDRA-3159-remove-extra-cp-entry.txt Multiple classpath entries in the cassandra-all.jar --- Key: CASSANDRA-3159 URL: https://issues.apache.org/jira/browse/CASSANDRA-3159 Project: Cassandra Issue Type: Bug Reporter: T Jake Luciani Assignee: Eric Evans Priority: Minor Fix For: 1.0 Attachments: v1-0001-CASSANDRA-3159-remove-extra-cp-entry.txt from CASSANDRA-2936 {code} Sep 8, 2011 8:47:45 AM java.util.jar.Attributes read WARNING: Duplicate name in Manifest: Class-Path. Ensure that the manifest does not have duplicate entries, and that blank lines separate individual sections in both your manifest and in the META-INF/MANIFEST.MF entry in the jar file. {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3159) Multiple classpath entries in the cassandra-all.jar
[ https://issues.apache.org/jira/browse/CASSANDRA-3159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100396#comment-13100396 ] T Jake Luciani commented on CASSANDRA-3159: --- +1 Multiple classpath entries in the cassandra-all.jar --- Key: CASSANDRA-3159 URL: https://issues.apache.org/jira/browse/CASSANDRA-3159 Project: Cassandra Issue Type: Bug Reporter: T Jake Luciani Assignee: Eric Evans Priority: Minor Fix For: 1.0 Attachments: v1-0001-CASSANDRA-3159-remove-extra-cp-entry.txt from CASSANDRA-2936 {code} Sep 8, 2011 8:47:45 AM java.util.jar.Attributes read WARNING: Duplicate name in Manifest: Class-Path. Ensure that the manifest does not have duplicate entries, and that blank lines separate individual sections in both your manifest and in the META-INF/MANIFEST.MF entry in the jar file. {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1166774 - /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/StorageProxy.java
Author: jbellis Date: Thu Sep 8 16:04:20 2011 New Revision: 1166774 URL: http://svn.apache.org/viewvc?rev=1166774view=rev Log: Improve caching of same-version Messages on digest and repair paths patch by jbellis; reviewed by slebresne for CASSANDRA-3158 Modified: cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/StorageProxy.java Modified: cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/StorageProxy.java URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/StorageProxy.java?rev=1166774r1=1166773r2=1166774view=diff == --- cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/StorageProxy.java (original) +++ cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/StorageProxy.java Thu Sep 8 16:04:20 2011 @@ -516,50 +516,45 @@ public class StorageProxy implements Sto ReadCallbackRow handler = getReadCallback(resolver, command, consistency_level, endpoints); handler.assureSufficientLiveNodes(); assert !handler.endpoints.isEmpty(); +readCallbacks.add(handler); -// The data-request message is sent to dataPoint, the node that will actually get -// the data for us. The other replicas are only sent a digest query. -ReadCommand digestCommand = null; -if (handler.endpoints.size() 1) -{ -digestCommand = command.copy(); -digestCommand.setDigestQuery(true); -} - +// The data-request message is sent to dataPoint, the node that will actually get the data for us InetAddress dataPoint = handler.endpoints.get(0); if (dataPoint.equals(FBUtilities.getLocalAddress())) { -if (logger.isDebugEnabled()) -logger.debug(reading data locally); +logger.debug(reading data locally); StageManager.getStage(Stage.READ).execute(new LocalReadRunnable(command, handler)); } else { -if (logger.isDebugEnabled()) -logger.debug(reading data from + dataPoint); +logger.debug(reading data from {}, dataPoint); MessagingService.instance().sendRR(command, dataPoint, handler); } -// We lazy-construct the digest Message object since it may not be necessary if we -// are doing a local digest read, or no digest reads at all. -MessageProducer producer = new CachingMessageProducer(digestCommand); +if (handler.endpoints.size() == 1) +continue; + +// send the other endpoints a digest request +ReadCommand digestCommand = command.copy(); +digestCommand.setDigestQuery(true); +MessageProducer producer = null; for (InetAddress digestPoint : handler.endpoints.subList(1, handler.endpoints.size())) { if (digestPoint.equals(FBUtilities.getLocalAddress())) { -if (logger.isDebugEnabled()) -logger.debug(reading digest locally); +logger.debug(reading digest locally); StageManager.getStage(Stage.READ).execute(new LocalReadRunnable(digestCommand, handler)); } else { -if (logger.isDebugEnabled()) -logger.debug(reading digest for from + digestPoint); +logger.debug(reading digest from {}, digestPoint); +// (We lazy-construct the digest Message object since it may not be necessary if we +// are doing a local digest read, or no digest reads at all.) +if (producer == null) +producer = new CachingMessageProducer(digestCommand); MessagingService.instance().sendRR(producer, digestPoint, handler); } } - -readCallbacks.add(handler); } // read results and make a second pass for any digest mismatches @@ -591,8 +586,9 @@ public class StorageProxy implements Sto logger.debug(Digest mismatch: {}, ex.toString()); RowRepairResolver resolver = new RowRepairResolver(command.table, command.key); RepairCallbackRow repairHandler = new RepairCallbackRow(resolver, handler.endpoints); +MessageProducer producer = new CachingMessageProducer(command); for (InetAddress endpoint : handler.endpoints) -MessagingService.instance().sendRR(command, endpoint, repairHandler); +MessagingService.instance().sendRR(producer, endpoint,
[jira] [Updated] (CASSANDRA-3160) PIG_OPTS bash variable interpolation doesn't work correctly when PIG_OPTS is set in the environment.
[ https://issues.apache.org/jira/browse/CASSANDRA-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eldon Stegall updated CASSANDRA-3160: - Attachment: CASSANDRA-3160.patch PIG_OPTS bash variable interpolation doesn't work correctly when PIG_OPTS is set in the environment. Key: CASSANDRA-3160 URL: https://issues.apache.org/jira/browse/CASSANDRA-3160 Project: Cassandra Issue Type: Bug Components: Contrib Affects Versions: 0.8.5 Environment: bash Reporter: Eldon Stegall Priority: Minor Fix For: 0.8.6, 1.0 Attachments: CASSANDRA-3160.patch PIG_OPTS bash variable interpolation doesn't work correctly when PIG_OPTS is set in the environment due to variable preceding quotes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-3160) PIG_OPTS bash variable interpolation doesn't work correctly when PIG_OPTS is set in the environment.
PIG_OPTS bash variable interpolation doesn't work correctly when PIG_OPTS is set in the environment. Key: CASSANDRA-3160 URL: https://issues.apache.org/jira/browse/CASSANDRA-3160 Project: Cassandra Issue Type: Bug Components: Contrib Affects Versions: 0.8.5, 0.8.6, 1.0 Environment: bash Reporter: Eldon Stegall Priority: Minor PIG_OPTS bash variable interpolation doesn't work correctly when PIG_OPTS is set in the environment due to variable preceding quotes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3160) PIG_OPTS bash variable interpolation doesn't work correctly when PIG_OPTS is set in the environment.
[ https://issues.apache.org/jira/browse/CASSANDRA-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-3160: -- Reviewer: brandon.williams PIG_OPTS bash variable interpolation doesn't work correctly when PIG_OPTS is set in the environment. Key: CASSANDRA-3160 URL: https://issues.apache.org/jira/browse/CASSANDRA-3160 Project: Cassandra Issue Type: Bug Components: Contrib Affects Versions: 0.8.5 Environment: bash Reporter: Eldon Stegall Priority: Minor Fix For: 0.8.6, 1.0 Attachments: CASSANDRA-3160.patch PIG_OPTS bash variable interpolation doesn't work correctly when PIG_OPTS is set in the environment due to variable preceding quotes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3037) Could not get input splits Caused by: java.io.IOException: failed connecting to all endpoints slave1/123.198.69.242
[ https://issues.apache.org/jira/browse/CASSANDRA-3037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100430#comment-13100430 ] luwei commented on CASSANDRA-3037: -- hi, I don't know whether you have solved the problem. I met with the same problem as yours (Same configuration as yours too) and trrie to solve it. Problem location: public ListInputSplit call() throws Exception { ... ListString tokens = getSubSplits(keyspace, cfName, range, conf); ... In the method getSubSplits when calling method createConnection(host, ConfigHelper.getRpcPort(conf), true), the format of host is not right. It is hostname/10.197.34.111 sometimes (ip_address), so createConnection will fail. We need to extract the ip address and then call createConnection. You can try to change the code and try Hadoop again. Good luck! Could not get input splits Caused by: java.io.IOException: failed connecting to all endpoints slave1/123.198.69.242 --- Key: CASSANDRA-3037 URL: https://issues.apache.org/jira/browse/CASSANDRA-3037 Project: Cassandra Issue Type: Bug Components: Hadoop Affects Versions: 0.8.4 Environment: Ubuntu 10.04 LTS Hadoop from Cloudera 0.20.203 Latest java Reporter: Anton Vedeshin Priority: Blocker After upgrade of cassandra from 0.8.2 to 0.8.4, got this error, before upgrade everything was working fine I have restarted cassandra, removed data, etc. nothing helps I have 6 identical machines in the cloud, before it was working fine. If I make netstat then it shows port 9160 listening nodetool ... ring - responces with 6 machines UP. Finally I have truncated all 6 servers and reinstalled hadoop + cassandra 0.8.4 from scratch. compiled and tried to execute word_cound receive the same error as after upgrade Error: 11/08/15 15:23:54 INFO WordCount: output reducer type: cassandra 11/08/15 15:23:54 INFO jvm.JvmMetrics: Initializing JVM Metrics with processName=JobTracker, sessionId= Exception in thread main java.io.IOException: Could not get input splits at org.apache.cassandra.hadoop.ColumnFamilyInputFormat.getSplits(ColumnFamilyInputFormat.java:157) at org.apache.hadoop.mapred.JobClient.writeNewSplits(JobClient.java:885) at org.apache.hadoop.mapred.JobClient.submitJobInternal(JobClient.java:779) at org.apache.hadoop.mapreduce.Job.submit(Job.java:432) at org.apache.hadoop.mapreduce.Job.waitForCompletion(Job.java:447) at WordCount.run(Unknown Source) at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:65) at WordCount.main(Unknown Source) Caused by: java.util.concurrent.ExecutionException: java.io.IOException: failed connecting to all endpoints slave1/154.198.69.242 at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222) at java.util.concurrent.FutureTask.get(FutureTask.java:83) at org.apache.cassandra.hadoop.ColumnFamilyInputFormat.getSplits(ColumnFamilyInputFormat.java:153) ... 7 more Caused by: java.io.IOException: failed connecting to all endpoints slave1/154.198.69.242 at org.apache.cassandra.hadoop.ColumnFamilyInputFormat.getSubSplits(ColumnFamilyInputFormat.java:234) at org.apache.cassandra.hadoop.ColumnFamilyInputFormat.access$200(ColumnFamilyInputFormat.java:70) at org.apache.cassandra.hadoop.ColumnFamilyInputFormat$SplitCallable.call(ColumnFamilyInputFormat.java:190) at org.apache.cassandra.hadoop.ColumnFamilyInputFormat$SplitCallable.call(ColumnFamilyInputFormat.java:175) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1166779 - in /cassandra/trunk: ./ conf/ contrib/ interface/thrift/gen-java/org/apache/cassandra/thrift/ src/java/org/apache/cassandra/cli/ src/java/org/apache/cassandra/locator/ src/java/
Author: jbellis Date: Thu Sep 8 16:31:27 2011 New Revision: 1166779 URL: http://svn.apache.org/viewvc?rev=1166779view=rev Log: merge from 0.8 Modified: cassandra/trunk/ (props changed) cassandra/trunk/CHANGES.txt cassandra/trunk/NEWS.txt cassandra/trunk/conf/cassandra-env.sh cassandra/trunk/contrib/ (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/NotFoundException.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/SuperColumn.java (props changed) cassandra/trunk/src/java/org/apache/cassandra/cli/CliClient.java cassandra/trunk/src/java/org/apache/cassandra/locator/PropertyFileSnitch.java cassandra/trunk/src/java/org/apache/cassandra/service/StorageService.java cassandra/trunk/src/java/org/apache/cassandra/service/StorageServiceMBean.java cassandra/trunk/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java cassandra/trunk/src/java/org/apache/cassandra/thrift/ThriftValidation.java cassandra/trunk/src/java/org/apache/cassandra/utils/BloomFilter.java cassandra/trunk/test/unit/org/apache/cassandra/cli/CliTest.java cassandra/trunk/test/unit/org/apache/cassandra/thrift/ThriftValidationTest.java Propchange: cassandra/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Sep 8 16:31:27 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1131291 /cassandra/branches/cassandra-0.7:1026516-1163782 /cassandra/branches/cassandra-0.7.0:1053690-1055654 -/cassandra/branches/cassandra-0.8:1090934-1125013,1125019-1163783,1164068-1164069,1164399,1164634,1164657,1165218,1166261 +/cassandra/branches/cassandra-0.8:1090934-1125013,1125019-1166261 /cassandra/branches/cassandra-0.8.0:1125021-1130369 /cassandra/branches/cassandra-0.8.1:1101014-1125018 /cassandra/tags/cassandra-0.7.0-rc3:1051699-1053689 Modified: cassandra/trunk/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/trunk/CHANGES.txt?rev=1166779r1=1166778r2=1166779view=diff == --- cassandra/trunk/CHANGES.txt (original) +++ cassandra/trunk/CHANGES.txt Thu Sep 8 16:31:27 2011 @@ -68,6 +68,18 @@ (CASSANDRA-3119) * rename CQL type names to match expected SQL behavior (CASSANDRA-3149) + +0.8.6 + * avoid trying to watch cassandra-topology.properties when loaded from jar + (CASSANDRA-3138) + * prevent users from creating keyspaces with LocalStrategy replication + (CASSANDRA-3139) + * fix CLI `show schema;` to output correct keyspace definition statement + (CASSANDRA-3129) + * CustomTThreadPoolServer to log TTransportException at DEBUG level + (CASSANDRA-3142) + + 0.8.5 * fix NPE when encryption_options is unspecified (CASSANDRA-3007) * include column name in validation failure exceptions (CASSANDRA-2849) @@ -121,6 +133,10 @@ * bundle sstableloader with the debian package (CASSANDRA-3113) * don't try to build secondary indexes when there is none (CASSANDRA-3123) * improve SSTableSimpleUnsortedWriter speed for large rows (CASSANDRA-3122) + * handle keyspace arguments correctly in nodetool snapshot (CASSANDRA-3038) + * Fix SSTableImportTest on windows (CASSANDRA-3043) + * expose compactionThroughputMbPerSec through JMX (CASSANDRA-3117) + * log keyspace and CF of large rows being compacted 0.8.4 @@ -182,7 +198,7 @@ * allow deleting a row and updating indexed columns in it in the same mutation (CASSANDRA-2773) * Expose number of threads blocked on submitting memtable to flush - (CASSANDRA-2817) + in JMX (CASSANDRA-2817) * add ability to return endpoints to nodetool (CASSANDRA-2776) * Add support for multiple (comma-delimited) coordinator addresses to ColumnFamilyInputFormat (CASSANDRA-2807) Modified: cassandra/trunk/NEWS.txt URL: http://svn.apache.org/viewvc/cassandra/trunk/NEWS.txt?rev=1166779r1=1166778r2=1166779view=diff == --- cassandra/trunk/NEWS.txt (original) +++ cassandra/trunk/NEWS.txt Thu Sep 8 16:31:27 2011 @@ -64,9 +64,17 @@ Other 0.8.5 = +Features + +- SSTables copied to a data directory can be loaded by a live node through + nodetool refresh (may be handy to load snapshots). +- The configured compaction throughput is exposed through JMX. + Other - -- The sstableloader is now bundled with the debian package +- The sstableloader is now bundled with the debian package. +-
svn commit: r1166783 - in /cassandra/trunk: ./ contrib/ interface/thrift/gen-java/org/apache/cassandra/thrift/ src/java/org/apache/cassandra/locator/ src/java/org/apache/cassandra/service/
Author: jbellis Date: Thu Sep 8 16:35:45 2011 New Revision: 1166783 URL: http://svn.apache.org/viewvc?rev=1166783view=rev Log: merge from 0.8 Modified: cassandra/trunk/ (props changed) cassandra/trunk/contrib/ (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/NotFoundException.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/SuperColumn.java (props changed) cassandra/trunk/src/java/org/apache/cassandra/locator/AbstractNetworkTopologySnitch.java cassandra/trunk/src/java/org/apache/cassandra/service/StorageProxy.java Propchange: cassandra/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Sep 8 16:35:45 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1131291 /cassandra/branches/cassandra-0.7:1026516-1163782 /cassandra/branches/cassandra-0.7.0:1053690-1055654 -/cassandra/branches/cassandra-0.8:1090934-1125013,1125019-1166261 +/cassandra/branches/cassandra-0.8:1090934-1125013,1125019-1166782 /cassandra/branches/cassandra-0.8.0:1125021-1130369 /cassandra/branches/cassandra-0.8.1:1101014-1125018 /cassandra/tags/cassandra-0.7.0-rc3:1051699-1053689 Propchange: cassandra/trunk/contrib/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Sep 8 16:35:45 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6/contrib:922689-1052356,1052358-1053452,1053454,1053456-1068009 /cassandra/branches/cassandra-0.7/contrib:1026516-1163782 /cassandra/branches/cassandra-0.7.0/contrib:1053690-1055654 -/cassandra/branches/cassandra-0.8/contrib:1090934-1125013,1125019-1166261 +/cassandra/branches/cassandra-0.8/contrib:1090934-1125013,1125019-1166782 /cassandra/branches/cassandra-0.8.0/contrib:1125021-1130369 /cassandra/branches/cassandra-0.8.1/contrib:1101014-1125018 /cassandra/tags/cassandra-0.7.0-rc3/contrib:1051699-1053689 Propchange: cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Sep 8 16:35:45 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:922689-1052356,1052358-1053452,1053454,1053456-1131291 /cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1163782 /cassandra/branches/cassandra-0.7.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1053690-1055654 -/cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1090934-1125013,1125019-1166261 +/cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1090934-1125013,1125019-1166782 /cassandra/branches/cassandra-0.8.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1125021-1130369 /cassandra/branches/cassandra-0.8.1/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1101014-1125018 /cassandra/tags/cassandra-0.7.0-rc3/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1051699-1053689 Propchange: cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Sep 8 16:35:45 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:922689-1052356,1052358-1053452,1053454,1053456-1131291 /cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1026516-1163782 /cassandra/branches/cassandra-0.7.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1053690-1055654 -/cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1090934-1125013,1125019-1166261 +/cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1090934-1125013,1125019-1166782 /cassandra/branches/cassandra-0.8.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1125021-1130369 /cassandra/branches/cassandra-0.8.1/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1101014-1125018
[jira] [Commented] (CASSANDRA-3158) Improve caching of same-version Messages on digest and repair paths
[ https://issues.apache.org/jira/browse/CASSANDRA-3158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100436#comment-13100436 ] Jonathan Ellis commented on CASSANDRA-3158: --- Note that on merge to trunk I also added a readCallbacks.clear() statement at the beginning of the short-read do/while loop. Improve caching of same-version Messages on digest and repair paths --- Key: CASSANDRA-3158 URL: https://issues.apache.org/jira/browse/CASSANDRA-3158 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.1 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 0.8.6 Attachments: 3158-v2.txt, 3158.txt -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3037) Could not get input splits Caused by: java.io.IOException: failed connecting to all endpoints slave1/123.198.69.242
[ https://issues.apache.org/jira/browse/CASSANDRA-3037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100442#comment-13100442 ] Anton Vedeshin commented on CASSANDRA-3037: --- Hi! Unfortunately we have given up using Cassandra this time (may be later, when it will be more stable). When I look the examples, etc, they are great, but when we start using it, there are plenty of problems to be solved like one described above and support is very slow. Cassandra is a great thing, but not for our current project. Could not get input splits Caused by: java.io.IOException: failed connecting to all endpoints slave1/123.198.69.242 --- Key: CASSANDRA-3037 URL: https://issues.apache.org/jira/browse/CASSANDRA-3037 Project: Cassandra Issue Type: Bug Components: Hadoop Affects Versions: 0.8.4 Environment: Ubuntu 10.04 LTS Hadoop from Cloudera 0.20.203 Latest java Reporter: Anton Vedeshin Priority: Blocker After upgrade of cassandra from 0.8.2 to 0.8.4, got this error, before upgrade everything was working fine I have restarted cassandra, removed data, etc. nothing helps I have 6 identical machines in the cloud, before it was working fine. If I make netstat then it shows port 9160 listening nodetool ... ring - responces with 6 machines UP. Finally I have truncated all 6 servers and reinstalled hadoop + cassandra 0.8.4 from scratch. compiled and tried to execute word_cound receive the same error as after upgrade Error: 11/08/15 15:23:54 INFO WordCount: output reducer type: cassandra 11/08/15 15:23:54 INFO jvm.JvmMetrics: Initializing JVM Metrics with processName=JobTracker, sessionId= Exception in thread main java.io.IOException: Could not get input splits at org.apache.cassandra.hadoop.ColumnFamilyInputFormat.getSplits(ColumnFamilyInputFormat.java:157) at org.apache.hadoop.mapred.JobClient.writeNewSplits(JobClient.java:885) at org.apache.hadoop.mapred.JobClient.submitJobInternal(JobClient.java:779) at org.apache.hadoop.mapreduce.Job.submit(Job.java:432) at org.apache.hadoop.mapreduce.Job.waitForCompletion(Job.java:447) at WordCount.run(Unknown Source) at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:65) at WordCount.main(Unknown Source) Caused by: java.util.concurrent.ExecutionException: java.io.IOException: failed connecting to all endpoints slave1/154.198.69.242 at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222) at java.util.concurrent.FutureTask.get(FutureTask.java:83) at org.apache.cassandra.hadoop.ColumnFamilyInputFormat.getSplits(ColumnFamilyInputFormat.java:153) ... 7 more Caused by: java.io.IOException: failed connecting to all endpoints slave1/154.198.69.242 at org.apache.cassandra.hadoop.ColumnFamilyInputFormat.getSubSplits(ColumnFamilyInputFormat.java:234) at org.apache.cassandra.hadoop.ColumnFamilyInputFormat.access$200(ColumnFamilyInputFormat.java:70) at org.apache.cassandra.hadoop.ColumnFamilyInputFormat$SplitCallable.call(ColumnFamilyInputFormat.java:190) at org.apache.cassandra.hadoop.ColumnFamilyInputFormat$SplitCallable.call(ColumnFamilyInputFormat.java:175) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2882) describe_ring should include datacenter/topology information
[ https://issues.apache.org/jira/browse/CASSANDRA-2882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Guzman updated CASSANDRA-2882: --- Attachment: 0001-CASSANDRA-2882-rebased.patch Rebased off trunk as of an hour ago. da34fa8f486b6209149e8e71c42685c0a7a407e4 describe_ring should include datacenter/topology information Key: CASSANDRA-2882 URL: https://issues.apache.org/jira/browse/CASSANDRA-2882 Project: Cassandra Issue Type: Improvement Components: API, Core Reporter: Mark Guzman Assignee: Pavel Yaskevich Priority: Minor Labels: lhf Fix For: 1.1 Attachments: 0001-CASSANDRA-2882-patch-w-o-generated-files.patch, 0001-CASSANDRA-2882-rebased.patch, 0001-adding-an-additional-parameter-to-the-TokenRange-res.patch, 0001-final-cleaned-up-2882-changes.patch describe_ring is great for getting a list of nodes in the cluster, but it doesn't provide any information about the network topology which prevents it's use in a multi-dc setup. It would be nice if we added another list to the TokenRange object containing the DC information. Optimally I could have ask any Cassandra node for this information and on the client-side prefer local nodes but be able to fail to remote nodes without requiring another lookup. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3141) SSTableSimpleUnsortedWriter call to ColumnFamily.serializedSize iterate through the whole columns
[ https://issues.apache.org/jira/browse/CASSANDRA-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100449#comment-13100449 ] Benoit Perroud commented on CASSANDRA-3141: --- Iterating through a list of 1'000'000 of elements takes obviously time. But I agree with both of you : - it's a premature optimization, I will try with CASSANDRA-2843 first - the way I use SSTSUW is not completely appropriate, I have way better result doing one key after the other. SSTableSimpleUnsortedWriter call to ColumnFamily.serializedSize iterate through the whole columns - Key: CASSANDRA-3141 URL: https://issues.apache.org/jira/browse/CASSANDRA-3141 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.8.3 Reporter: Benoit Perroud Priority: Minor Fix For: 0.8.6 Attachments: CachedSizeCF.patch Every time newRow is called, serializedSize iterate through all the columns to compute the size. Once 1'000'000 columns exist in the CF, it becomes painfull to do at every iteration the same computation. Caching the size and incrementing when a Column is added could be an option. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-3161) clean up read path
clean up read path -- Key: CASSANDRA-3161 URL: https://issues.apache.org/jira/browse/CASSANDRA-3161 Project: Cassandra Issue Type: Improvement Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 1.0 As CASSANDRA-3156, CASSANDRA-3158, CASSANDRA-3159 show, the read path has gotten a little crufty, especially with the introduction of short read protection. Time for some cleanup to reduce the chance of bugs and to make troubleshooting easier when we do have one. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3161) clean up read path
[ https://issues.apache.org/jira/browse/CASSANDRA-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-3161: -- Attachment: 3161.txt - updates comments in RowDigestResolver and RowRepairResolver - removes unnecessary versions + endpoints lists from RRR - moves fetchrows helper collections into the do/while loop, where possible (this is fine from a performance perspective since the overwhelmingly most frequent case is we only execute the loop body once); also renames commands-initialCommands and commandsToSend-commands, pre-sizes rows list to avoid re-allocating it, and sizes readCallbacks as well. clean up read path -- Key: CASSANDRA-3161 URL: https://issues.apache.org/jira/browse/CASSANDRA-3161 Project: Cassandra Issue Type: Improvement Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 1.0 Attachments: 3161.txt As CASSANDRA-3156, CASSANDRA-3158, CASSANDRA-3157 show, the read path has gotten a little crufty, especially with the introduction of short read protection. Time for some cleanup to reduce the chance of bugs and to make troubleshooting easier when we do have one. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1166809 - /cassandra/branches/cassandra-0.8/contrib/pig/bin/pig_cassandra
Author: brandonwilliams Date: Thu Sep 8 17:11:26 2011 New Revision: 1166809 URL: http://svn.apache.org/viewvc?rev=1166809view=rev Log: Fix interpolation of PIG_OPTS. Patch by Eldon Stegall, reviewed by brandonwilliams for CASSANDRA-3160 Modified: cassandra/branches/cassandra-0.8/contrib/pig/bin/pig_cassandra Modified: cassandra/branches/cassandra-0.8/contrib/pig/bin/pig_cassandra URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/contrib/pig/bin/pig_cassandra?rev=1166809r1=1166808r2=1166809view=diff == --- cassandra/branches/cassandra-0.8/contrib/pig/bin/pig_cassandra (original) +++ cassandra/branches/cassandra-0.8/contrib/pig/bin/pig_cassandra Thu Sep 8 17:11:26 2011 @@ -46,5 +46,5 @@ fi CLASSPATH=$CLASSPATH:$PIG_JAR export PIG_CLASSPATH=$PIG_CLASSPATH:$CLASSPATH -export PIG_OPTS=$PIG_OPTS -Dudf.import.list=org.apache.cassandra.hadoop.pig +export PIG_OPTS=$PIG_OPTS -Dudf.import.list=org.apache.cassandra.hadoop.pig cat $cwd/../build/bootstrap.pig - | $PIG_HOME/bin/pig $*
[jira] [Issue Comment Edited] (CASSANDRA-2961) Expire dead gossip states based on time
[ https://issues.apache.org/jira/browse/CASSANDRA-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100468#comment-13100468 ] Brandon Williams edited comment on CASSANDRA-2961 at 9/8/11 5:20 PM: - bq. hamscrest : In my case, It's true, I just use hamcrest with is into assert. There is a lot of other verb which interesting to make asserting more readable. Tt was for help for next but if you want I can remove it. tell me you do you prefer. I don't think it's providing enough utility yet to justify another dependency. bq. VersionedValue.getExpireTime : It's true, I put it in the Gossiper? a utility class? I think I would pass the expire times to the VV constructors and put the actual generation of the times in Gossiper. bq. There is 3 calls to excise in SS : handleStateLeft, handleStateRemoving and... removeToken. In removeToken, we don't have the pieces of the VV which contain expireTime. So we can't extract an expireTime. That's because in removeToken, we are responsible for the generation of the expireTime (we are the removal coordinator.) was (Author: brandon.williams): bq. hamscrest : In my case, It's true, I just use hamcrest with is into assert. There is a lot of other verb which interesting to make asserting more readable. Tt was for help for next but if you want I can remove it. tell me you do you prefer. I don't think it's providing enough utility yet to justify another dependency. bq. VersionedValue.getExpireTime : It's true, I put it in the Gossiper? a utility class? I think I would pass the expire times to the VV constructors and put the actual generation of the times in Gossiper. bq. There is 3 calls to excise in SS : handleStateLeft, handleStateRemoving and... removeToken. In removeToken, we don't have the pieces of the VV which contain expireTime. So we can't extract an expireTime. That's because in removeToken, we are responsible for the generation of the expireTime (we are the removal coordinator.) Expire dead gossip states based on time --- Key: CASSANDRA-2961 URL: https://issues.apache.org/jira/browse/CASSANDRA-2961 Project: Cassandra Issue Type: Improvement Affects Versions: 1.0 Reporter: Brandon Williams Priority: Minor Fix For: 1.1 Attachments: trunk-2961-v2.patch, trunk-2961.patch Currently dead states are held until aVeryLongTime, 3 days. The problem is that if a node reboots within this period, it begins a new 3 days and will repopulate the ring with the dead state. While mostly harmless, perpetuating the state forever is at least wasting a small amount of bandwidth. Instead, we can expire states based on a ttl, which will require that the cluster be loosely time synced; within the quarantine period of 60s. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2961) Expire dead gossip states based on time
[ https://issues.apache.org/jira/browse/CASSANDRA-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100468#comment-13100468 ] Brandon Williams commented on CASSANDRA-2961: - bq. hamscrest : In my case, It's true, I just use hamcrest with is into assert. There is a lot of other verb which interesting to make asserting more readable. Tt was for help for next but if you want I can remove it. tell me you do you prefer. I don't think it's providing enough utility yet to justify another dependency. bq. VersionedValue.getExpireTime : It's true, I put it in the Gossiper? a utility class? I think I would pass the expire times to the VV constructors and put the actual generation of the times in Gossiper. bq. There is 3 calls to excise in SS : handleStateLeft, handleStateRemoving and... removeToken. In removeToken, we don't have the pieces of the VV which contain expireTime. So we can't extract an expireTime. That's because in removeToken, we are responsible for the generation of the expireTime (we are the removal coordinator.) Expire dead gossip states based on time --- Key: CASSANDRA-2961 URL: https://issues.apache.org/jira/browse/CASSANDRA-2961 Project: Cassandra Issue Type: Improvement Affects Versions: 1.0 Reporter: Brandon Williams Priority: Minor Fix For: 1.1 Attachments: trunk-2961-v2.patch, trunk-2961.patch Currently dead states are held until aVeryLongTime, 3 days. The problem is that if a node reboots within this period, it begins a new 3 days and will repopulate the ring with the dead state. While mostly harmless, perpetuating the state forever is at least wasting a small amount of bandwidth. Instead, we can expire states based on a ttl, which will require that the cluster be loosely time synced; within the quarantine period of 60s. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3154) Bad equality check in ColumnFamilyStore.isCompleteSSTables()
[ https://issues.apache.org/jira/browse/CASSANDRA-3154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100470#comment-13100470 ] Benjamin Coverston commented on CASSANDRA-3154: --- Patch is good. +1 Getting rid of isMajor makes the logic behind the determination of the compaction operation much cleaner. Bad equality check in ColumnFamilyStore.isCompleteSSTables() Key: CASSANDRA-3154 URL: https://issues.apache.org/jira/browse/CASSANDRA-3154 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0 Reporter: Tupshin Harper Assignee: Tupshin Harper Priority: Minor Fix For: 1.0 Attachments: 3154.txt, CASSANDRA-3154.diff The equality check in isCompleteSSTables() always fails because it tries to call equals() with a Set and a List. This might result in failure to purge tombstones in some cases. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3137) Implement wrapping intersections for ConfigHelper's InputKeyRange
[ https://issues.apache.org/jira/browse/CASSANDRA-3137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100475#comment-13100475 ] Jonathan Ellis commented on CASSANDRA-3137: --- Sounds reasonable. Patch looks okay to me. I'll commit it after you've tested it. :) Implement wrapping intersections for ConfigHelper's InputKeyRange - Key: CASSANDRA-3137 URL: https://issues.apache.org/jira/browse/CASSANDRA-3137 Project: Cassandra Issue Type: Improvement Components: Hadoop Affects Versions: 0.8.5 Reporter: Mck SembWever Assignee: Mck SembWever Fix For: 0.8.6 Attachments: CASSANDRA-3137.patch, CASSANDRA-3137.patch Before there was no support for multiple intersections between the split's range and the job's configured range. After CASSANDRA-3108 it is now possible. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3137) Implement wrapping intersections for ConfigHelper's InputKeyRange
[ https://issues.apache.org/jira/browse/CASSANDRA-3137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-3137: -- Reviewer: jbellis Priority: Minor (was: Major) Fix Version/s: 0.8.6 Implement wrapping intersections for ConfigHelper's InputKeyRange - Key: CASSANDRA-3137 URL: https://issues.apache.org/jira/browse/CASSANDRA-3137 Project: Cassandra Issue Type: Improvement Components: Hadoop Affects Versions: 0.8.5 Reporter: Mck SembWever Assignee: Mck SembWever Priority: Minor Fix For: 0.8.6 Attachments: CASSANDRA-3137.patch, CASSANDRA-3137.patch Before there was no support for multiple intersections between the split's range and the job's configured range. After CASSANDRA-3108 it is now possible. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1166816 - in /cassandra/trunk: ./ contrib/ contrib/pig/bin/ interface/thrift/gen-java/org/apache/cassandra/thrift/
Author: brandonwilliams Date: Thu Sep 8 17:26:53 2011 New Revision: 1166816 URL: http://svn.apache.org/viewvc?rev=1166816view=rev Log: Merge 3160 from 0.8 Modified: cassandra/trunk/ (props changed) cassandra/trunk/contrib/ (props changed) cassandra/trunk/contrib/pig/bin/pig_cassandra cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/NotFoundException.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/SuperColumn.java (props changed) Propchange: cassandra/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Sep 8 17:26:53 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1131291 /cassandra/branches/cassandra-0.7:1026516-1163782 /cassandra/branches/cassandra-0.7.0:1053690-1055654 -/cassandra/branches/cassandra-0.8:1090934-1125013,1125019-1166782 +/cassandra/branches/cassandra-0.8:1090934-1125013,1125019-1166782,1166809 /cassandra/branches/cassandra-0.8.0:1125021-1130369 /cassandra/branches/cassandra-0.8.1:1101014-1125018 /cassandra/tags/cassandra-0.7.0-rc3:1051699-1053689 Propchange: cassandra/trunk/contrib/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Sep 8 17:26:53 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6/contrib:922689-1052356,1052358-1053452,1053454,1053456-1068009 /cassandra/branches/cassandra-0.7/contrib:1026516-1163782 /cassandra/branches/cassandra-0.7.0/contrib:1053690-1055654 -/cassandra/branches/cassandra-0.8/contrib:1090934-1125013,1125019-1166782 +/cassandra/branches/cassandra-0.8/contrib:1090934-1125013,1125019-1166782,1166809 /cassandra/branches/cassandra-0.8.0/contrib:1125021-1130369 /cassandra/branches/cassandra-0.8.1/contrib:1101014-1125018 /cassandra/tags/cassandra-0.7.0-rc3/contrib:1051699-1053689 Modified: cassandra/trunk/contrib/pig/bin/pig_cassandra URL: http://svn.apache.org/viewvc/cassandra/trunk/contrib/pig/bin/pig_cassandra?rev=1166816r1=1166815r2=1166816view=diff == --- cassandra/trunk/contrib/pig/bin/pig_cassandra (original) +++ cassandra/trunk/contrib/pig/bin/pig_cassandra Thu Sep 8 17:26:53 2011 @@ -46,5 +46,5 @@ fi CLASSPATH=$CLASSPATH:$PIG_JAR export PIG_CLASSPATH=$PIG_CLASSPATH:$CLASSPATH -export PIG_OPTS=$PIG_OPTS -Dudf.import.list=org.apache.cassandra.hadoop.pig +export PIG_OPTS=$PIG_OPTS -Dudf.import.list=org.apache.cassandra.hadoop.pig cat $cwd/../build/bootstrap.pig - | $PIG_HOME/bin/pig $* Propchange: cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Sep 8 17:26:53 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:922689-1052356,1052358-1053452,1053454,1053456-1131291 /cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1163782 /cassandra/branches/cassandra-0.7.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1053690-1055654 -/cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1090934-1125013,1125019-1166782 +/cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1090934-1125013,1125019-1166782,1166809 /cassandra/branches/cassandra-0.8.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1125021-1130369 /cassandra/branches/cassandra-0.8.1/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1101014-1125018 /cassandra/tags/cassandra-0.7.0-rc3/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1051699-1053689 Propchange: cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Sep 8 17:26:53 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:922689-1052356,1052358-1053452,1053454,1053456-1131291 /cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1026516-1163782
[jira] [Commented] (CASSANDRA-3158) Improve caching of same-version Messages on digest and repair paths
[ https://issues.apache.org/jira/browse/CASSANDRA-3158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100483#comment-13100483 ] Hudson commented on CASSANDRA-3158: --- Integrated in Cassandra-0.8 #321 (See [https://builds.apache.org/job/Cassandra-0.8/321/]) Improve caching of same-version Messages on digest and repair paths patch by jbellis; reviewed by slebresne for CASSANDRA-3158 jbellis : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1166774 Files : * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/StorageProxy.java Improve caching of same-version Messages on digest and repair paths --- Key: CASSANDRA-3158 URL: https://issues.apache.org/jira/browse/CASSANDRA-3158 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.1 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 0.8.6 Attachments: 3158-v2.txt, 3158.txt -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3160) PIG_OPTS bash variable interpolation doesn't work correctly when PIG_OPTS is set in the environment.
[ https://issues.apache.org/jira/browse/CASSANDRA-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100482#comment-13100482 ] Hudson commented on CASSANDRA-3160: --- Integrated in Cassandra-0.8 #321 (See [https://builds.apache.org/job/Cassandra-0.8/321/]) Fix interpolation of PIG_OPTS. Patch by Eldon Stegall, reviewed by brandonwilliams for CASSANDRA-3160 brandonwilliams : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1166809 Files : * /cassandra/branches/cassandra-0.8/contrib/pig/bin/pig_cassandra PIG_OPTS bash variable interpolation doesn't work correctly when PIG_OPTS is set in the environment. Key: CASSANDRA-3160 URL: https://issues.apache.org/jira/browse/CASSANDRA-3160 Project: Cassandra Issue Type: Bug Components: Contrib Affects Versions: 0.8.5 Environment: bash Reporter: Eldon Stegall Priority: Minor Fix For: 0.8.6, 1.0 Attachments: CASSANDRA-3160.patch PIG_OPTS bash variable interpolation doesn't work correctly when PIG_OPTS is set in the environment due to variable preceding quotes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1166822 - in /cassandra/trunk: ./ src/java/org/apache/cassandra/cache/ src/java/org/apache/cassandra/cli/ src/java/org/apache/cassandra/db/ src/java/org/apache/cassandra/db/compaction/ sr
Author: jbellis Date: Thu Sep 8 17:36:26 2011 New Revision: 1166822 URL: http://svn.apache.org/viewvc?rev=1166822view=rev Log: remove isMajor compaction designation patch by jbellis; reviewed by Tupshin Harper and Ben Coverston for CASSANDRA-3154 Added: cassandra/trunk/src/java/org/apache/cassandra/db/compaction/OperationType.java - copied, changed from r1166816, cassandra/trunk/src/java/org/apache/cassandra/db/compaction/CompactionType.java Modified: cassandra/trunk/CHANGES.txt cassandra/trunk/src/java/org/apache/cassandra/cache/AutoSavingCache.java cassandra/trunk/src/java/org/apache/cassandra/cli/CliClient.java cassandra/trunk/src/java/org/apache/cassandra/db/ColumnFamilyStore.java cassandra/trunk/src/java/org/apache/cassandra/db/compaction/AbstractCompactionIterable.java cassandra/trunk/src/java/org/apache/cassandra/db/compaction/CompactionController.java cassandra/trunk/src/java/org/apache/cassandra/db/compaction/CompactionInfo.java cassandra/trunk/src/java/org/apache/cassandra/db/compaction/CompactionIterable.java cassandra/trunk/src/java/org/apache/cassandra/db/compaction/CompactionManager.java cassandra/trunk/src/java/org/apache/cassandra/db/compaction/CompactionTask.java cassandra/trunk/src/java/org/apache/cassandra/db/compaction/CompactionType.java cassandra/trunk/src/java/org/apache/cassandra/db/compaction/ParallelCompactionIterable.java cassandra/trunk/src/java/org/apache/cassandra/db/index/SecondaryIndexBuilder.java cassandra/trunk/test/unit/org/apache/cassandra/io/LazilyCompactedRowTest.java Modified: cassandra/trunk/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/trunk/CHANGES.txt?rev=1166822r1=1166821r2=1166822view=diff == --- cassandra/trunk/CHANGES.txt (original) +++ cassandra/trunk/CHANGES.txt Thu Sep 8 17:36:26 2011 @@ -44,7 +44,7 @@ Thrift-Avro conversion methods (CASSANDRA-3032) * Add timeouts to client request schedulers (CASSANDRA-3079, 3096) * Cli to use hashes rather than array of hashes for strategy options (CASSANDRA-3081) - * LeveledCompactionStrategy (CASSANDRA-1608, 3085, 3110, 3087, 3145) + * LeveledCompactionStrategy (CASSANDRA-1608, 3085, 3110, 3087, 3145, 3154) * Improvements of the CLI `describe` command (CASSANDRA-2630) * reduce window where dropped CF sstables may not be deleted (CASSANDRA-2942) * Expose gossip/FD info to JMX (CASSANDRA-2806) Modified: cassandra/trunk/src/java/org/apache/cassandra/cache/AutoSavingCache.java URL: http://svn.apache.org/viewvc/cassandra/trunk/src/java/org/apache/cassandra/cache/AutoSavingCache.java?rev=1166822r1=1166821r2=1166822view=diff == --- cassandra/trunk/src/java/org/apache/cassandra/cache/AutoSavingCache.java (original) +++ cassandra/trunk/src/java/org/apache/cassandra/cache/AutoSavingCache.java Thu Sep 8 17:36:26 2011 @@ -37,7 +37,7 @@ import org.apache.cassandra.db.ColumnFam import org.apache.cassandra.db.compaction.CompactionInfo; import org.apache.cassandra.db.compaction.CompactionManager; import org.apache.cassandra.db.DecoratedKey; -import org.apache.cassandra.db.compaction.CompactionType; +import org.apache.cassandra.db.compaction.OperationType; import org.apache.cassandra.io.util.*; import org.apache.cassandra.service.StorageService; import org.apache.cassandra.utils.ByteBufferUtil; @@ -207,14 +207,14 @@ public abstract class AutoSavingCacheK, bytes += translateKey(key).remaining(); // an approximation -- the keyset can change while saving estimatedTotalBytes = bytes; -CompactionType type; +OperationType type; if (cacheType == ColumnFamilyStore.CacheType.KEY_CACHE_TYPE) -type = CompactionType.KEY_CACHE_SAVE; +type = OperationType.KEY_CACHE_SAVE; else if (cacheType == ColumnFamilyStore.CacheType.ROW_CACHE_TYPE) -type = CompactionType.ROW_CACHE_SAVE; +type = OperationType.ROW_CACHE_SAVE; else -type = CompactionType.UNKNOWN; +type = OperationType.UNKNOWN; info = new CompactionInfo(this.hashCode(), ksname, Modified: cassandra/trunk/src/java/org/apache/cassandra/cli/CliClient.java URL: http://svn.apache.org/viewvc/cassandra/trunk/src/java/org/apache/cassandra/cli/CliClient.java?rev=1166822r1=1166821r2=1166822view=diff == --- cassandra/trunk/src/java/org/apache/cassandra/cli/CliClient.java (original) +++ cassandra/trunk/src/java/org/apache/cassandra/cli/CliClient.java Thu Sep 8 17:36:26 2011 @@ -25,8 +25,6 @@ import java.nio.ByteBuffer; import java.nio.charset.CharacterCodingException; import java.util.*; -import
[jira] [Created] (CASSANDRA-3162) use weak references to SlabAllocator regions
use weak references to SlabAllocator regions Key: CASSANDRA-3162 URL: https://issues.apache.org/jira/browse/CASSANDRA-3162 Project: Cassandra Issue Type: Improvement Affects Versions: 1.0 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 1.0 Yang points out on CASSANDRA-2252, Conceivably, one region would contain bytebuffer values of similar age. as more updates come in, all the columns in older regions are likely to have all died out, thus allowing us to free the entire region before flushing happens. So it's a bit of a corner case optimization, but easy to do and safe. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3162) use weak references to SlabAllocator regions
[ https://issues.apache.org/jira/browse/CASSANDRA-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-3162: -- Attachment: 3162.txt Patch to use a set built on MapMaker.weakKeys. Also reduces region size to 1MB to make the overhead lower for the lots of small CFs use case. use weak references to SlabAllocator regions Key: CASSANDRA-3162 URL: https://issues.apache.org/jira/browse/CASSANDRA-3162 Project: Cassandra Issue Type: Improvement Affects Versions: 1.0 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 1.0 Attachments: 3162.txt Yang points out on CASSANDRA-2252, Conceivably, one region would contain bytebuffer values of similar age. as more updates come in, all the columns in older regions are likely to have all died out, thus allowing us to free the entire region before flushing happens. So it's a bit of a corner case optimization, but easy to do and safe. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-3162) use weak references to SlabAllocator regions
[ https://issues.apache.org/jira/browse/CASSANDRA-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100533#comment-13100533 ] Stu Hood edited comment on CASSANDRA-3162 at 9/8/11 6:22 PM: - I'm not sure I like using this many WeakReferences in the common case: couldn't we get approximately the same effect by just nulling the 'data' field of the Region immediately after it has been retired? Then the filledRegions list would be an empty shell of regions. was (Author: stuhood): I'm not sure I like using this many WeakReferences in the common case: couldn't we get approximately the same effect by just nulling the 'data' field of the Region immediately after it has been retired? Then the filledRegions list would be an empty shell of references. use weak references to SlabAllocator regions Key: CASSANDRA-3162 URL: https://issues.apache.org/jira/browse/CASSANDRA-3162 Project: Cassandra Issue Type: Improvement Affects Versions: 1.0 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 1.0 Attachments: 3162.txt Yang points out on CASSANDRA-2252, Conceivably, one region would contain bytebuffer values of similar age. as more updates come in, all the columns in older regions are likely to have all died out, thus allowing us to free the entire region before flushing happens. So it's a bit of a corner case optimization, but easy to do and safe. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3159) Multiple classpath entries in the cassandra-all.jar
[ https://issues.apache.org/jira/browse/CASSANDRA-3159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100535#comment-13100535 ] Hudson commented on CASSANDRA-3159: --- Integrated in Cassandra #1091 (See [https://builds.apache.org/job/Cassandra/1091/]) remove extra cp entry Patch by eevans; reviewed by tjake for CASSANDRA-3159 eevans : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1166812 Files : * /cassandra/trunk/build.xml Multiple classpath entries in the cassandra-all.jar --- Key: CASSANDRA-3159 URL: https://issues.apache.org/jira/browse/CASSANDRA-3159 Project: Cassandra Issue Type: Bug Reporter: T Jake Luciani Assignee: Eric Evans Priority: Minor Fix For: 1.0 Attachments: v1-0001-CASSANDRA-3159-remove-extra-cp-entry.txt from CASSANDRA-2936 {code} Sep 8, 2011 8:47:45 AM java.util.jar.Attributes read WARNING: Duplicate name in Manifest: Class-Path. Ensure that the manifest does not have duplicate entries, and that blank lines separate individual sections in both your manifest and in the META-INF/MANIFEST.MF entry in the jar file. {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3154) Bad equality check in ColumnFamilyStore.isCompleteSSTables()
[ https://issues.apache.org/jira/browse/CASSANDRA-3154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100536#comment-13100536 ] Hudson commented on CASSANDRA-3154: --- Integrated in Cassandra #1091 (See [https://builds.apache.org/job/Cassandra/1091/]) remove isMajor compaction designation patch by jbellis; reviewed by Tupshin Harper and Ben Coverston for CASSANDRA-3154 jbellis : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1166822 Files : * /cassandra/trunk/CHANGES.txt * /cassandra/trunk/src/java/org/apache/cassandra/cache/AutoSavingCache.java * /cassandra/trunk/src/java/org/apache/cassandra/cli/CliClient.java * /cassandra/trunk/src/java/org/apache/cassandra/db/ColumnFamilyStore.java * /cassandra/trunk/src/java/org/apache/cassandra/db/compaction/AbstractCompactionIterable.java * /cassandra/trunk/src/java/org/apache/cassandra/db/compaction/CompactionController.java * /cassandra/trunk/src/java/org/apache/cassandra/db/compaction/CompactionInfo.java * /cassandra/trunk/src/java/org/apache/cassandra/db/compaction/CompactionIterable.java * /cassandra/trunk/src/java/org/apache/cassandra/db/compaction/CompactionManager.java * /cassandra/trunk/src/java/org/apache/cassandra/db/compaction/CompactionTask.java * /cassandra/trunk/src/java/org/apache/cassandra/db/compaction/CompactionType.java * /cassandra/trunk/src/java/org/apache/cassandra/db/compaction/OperationType.java * /cassandra/trunk/src/java/org/apache/cassandra/db/compaction/ParallelCompactionIterable.java * /cassandra/trunk/src/java/org/apache/cassandra/db/index/SecondaryIndexBuilder.java * /cassandra/trunk/test/unit/org/apache/cassandra/io/LazilyCompactedRowTest.java Bad equality check in ColumnFamilyStore.isCompleteSSTables() Key: CASSANDRA-3154 URL: https://issues.apache.org/jira/browse/CASSANDRA-3154 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0 Reporter: Tupshin Harper Assignee: Tupshin Harper Priority: Minor Fix For: 1.0 Attachments: 3154.txt, CASSANDRA-3154.diff The equality check in isCompleteSSTables() always fails because it tries to call equals() with a Set and a List. This might result in failure to purge tombstones in some cases. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3162) use weak references to SlabAllocator regions
[ https://issues.apache.org/jira/browse/CASSANDRA-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100598#comment-13100598 ] Jonathan Ellis commented on CASSANDRA-3162: --- But then you have no way of knowing whether to include it in size(). use weak references to SlabAllocator regions Key: CASSANDRA-3162 URL: https://issues.apache.org/jira/browse/CASSANDRA-3162 Project: Cassandra Issue Type: Improvement Affects Versions: 1.0 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 1.0 Attachments: 3162.txt Yang points out on CASSANDRA-2252, Conceivably, one region would contain bytebuffer values of similar age. as more updates come in, all the columns in older regions are likely to have all died out, thus allowing us to free the entire region before flushing happens. So it's a bit of a corner case optimization, but easy to do and safe. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3162) use weak references to SlabAllocator regions
[ https://issues.apache.org/jira/browse/CASSANDRA-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100604#comment-13100604 ] Stu Hood commented on CASSANDRA-3162: - That's true, but I didn't think that was the goal of this ticket. use weak references to SlabAllocator regions Key: CASSANDRA-3162 URL: https://issues.apache.org/jira/browse/CASSANDRA-3162 Project: Cassandra Issue Type: Improvement Affects Versions: 1.0 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 1.0 Attachments: 3162.txt Yang points out on CASSANDRA-2252, Conceivably, one region would contain bytebuffer values of similar age. as more updates come in, all the columns in older regions are likely to have all died out, thus allowing us to free the entire region before flushing happens. So it's a bit of a corner case optimization, but easy to do and safe. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3156) assertion error in RowRepairResolver
[ https://issues.apache.org/jira/browse/CASSANDRA-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-3156: -- Attachment: 3156.txt The new threadlocal code was omitting to reset the buffer before each use. Patch attached. assertion error in RowRepairResolver Key: CASSANDRA-3156 URL: https://issues.apache.org/jira/browse/CASSANDRA-3156 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0 Reporter: Brandon Williams Priority: Blocker Fix For: 1.0 Attachments: 3156.txt Only seems to happen on a coordinator who does not have a copy of the data: DEBUG 03:15:59,866 Processing response on a callback from 3840@/10.179.64.227 DEBUG 03:15:59,866 Preprocessed data response DEBUG 03:15:59,866 Processing response on a callback from 3841@/10.179.111.137 DEBUG 03:15:59,866 Preprocessed digest response DEBUG 03:15:59,865 Processing response on a callback from 3837@/10.179.111.137 DEBUG 03:15:59,865 Preprocessed data response DEBUG 03:15:59,865 Preprocessed data response DEBUG 03:15:59,867 Preprocessed digest response DEBUG 03:15:59,867 resolving 2 responses ERROR 03:15:59,866 Fatal exception in thread Thread[ReadRepairStage:526,5,main] java.lang.AssertionError at org.apache.cassandra.service.RowRepairResolver.resolve(RowRepairResolver.java:77) at org.apache.cassandra.service.AsyncRepairCallback$1.runMayThrow(AsyncRepairCallback.java:54) at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) 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) ERROR 03:15:59,866 Fatal exception in thread Thread[ReadRepairStage:525,5,main] java.lang.AssertionError at org.apache.cassandra.service.RowRepairResolver.resolve(RowRepairResolver.java:77) at org.apache.cassandra.service.AsyncRepairCallback$1.runMayThrow(AsyncRepairCallback.java:54) at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) 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) ERROR 03:15:59,867 Fatal exception in thread Thread[ReadRepairStage:528,5,main] java.lang.AssertionError at org.apache.cassandra.service.RowRepairResolver.resolve(RowRepairResolver.java:77) at org.apache.cassandra.service.AsyncRepairCallback$1.runMayThrow(AsyncRepairCallback.java:54) at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) 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) DEBUG 03:15:59,867 resolving 2 responses DEBUG 03:15:59,867 resolving 2 responses DEBUG 03:15:59,867 resolving 2 responses -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-3162) use weak references to SlabAllocator regions
[ https://issues.apache.org/jira/browse/CASSANDRA-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100604#comment-13100604 ] Stu Hood edited comment on CASSANDRA-3162 at 9/8/11 7:19 PM: - That's true, but I didn't think that was the goal of this ticket. EDIT: I'm fine either way, so +1 if you prefer the WeakReference approach. was (Author: stuhood): That's true, but I didn't think that was the goal of this ticket. use weak references to SlabAllocator regions Key: CASSANDRA-3162 URL: https://issues.apache.org/jira/browse/CASSANDRA-3162 Project: Cassandra Issue Type: Improvement Affects Versions: 1.0 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 1.0 Attachments: 3162.txt Yang points out on CASSANDRA-2252, Conceivably, one region would contain bytebuffer values of similar age. as more updates come in, all the columns in older regions are likely to have all died out, thus allowing us to free the entire region before flushing happens. So it's a bit of a corner case optimization, but easy to do and safe. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3156) assertion error in RowRepairResolver
[ https://issues.apache.org/jira/browse/CASSANDRA-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100614#comment-13100614 ] Brandon Williams commented on CASSANDRA-3156: - +1 assertion error in RowRepairResolver Key: CASSANDRA-3156 URL: https://issues.apache.org/jira/browse/CASSANDRA-3156 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0 Reporter: Brandon Williams Priority: Blocker Fix For: 1.0 Attachments: 3156.txt Only seems to happen on a coordinator who does not have a copy of the data: DEBUG 03:15:59,866 Processing response on a callback from 3840@/10.179.64.227 DEBUG 03:15:59,866 Preprocessed data response DEBUG 03:15:59,866 Processing response on a callback from 3841@/10.179.111.137 DEBUG 03:15:59,866 Preprocessed digest response DEBUG 03:15:59,865 Processing response on a callback from 3837@/10.179.111.137 DEBUG 03:15:59,865 Preprocessed data response DEBUG 03:15:59,865 Preprocessed data response DEBUG 03:15:59,867 Preprocessed digest response DEBUG 03:15:59,867 resolving 2 responses ERROR 03:15:59,866 Fatal exception in thread Thread[ReadRepairStage:526,5,main] java.lang.AssertionError at org.apache.cassandra.service.RowRepairResolver.resolve(RowRepairResolver.java:77) at org.apache.cassandra.service.AsyncRepairCallback$1.runMayThrow(AsyncRepairCallback.java:54) at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) 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) ERROR 03:15:59,866 Fatal exception in thread Thread[ReadRepairStage:525,5,main] java.lang.AssertionError at org.apache.cassandra.service.RowRepairResolver.resolve(RowRepairResolver.java:77) at org.apache.cassandra.service.AsyncRepairCallback$1.runMayThrow(AsyncRepairCallback.java:54) at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) 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) ERROR 03:15:59,867 Fatal exception in thread Thread[ReadRepairStage:528,5,main] java.lang.AssertionError at org.apache.cassandra.service.RowRepairResolver.resolve(RowRepairResolver.java:77) at org.apache.cassandra.service.AsyncRepairCallback$1.runMayThrow(AsyncRepairCallback.java:54) at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) 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) DEBUG 03:15:59,867 resolving 2 responses DEBUG 03:15:59,867 resolving 2 responses DEBUG 03:15:59,867 resolving 2 responses -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1166865 - /cassandra/trunk/src/java/org/apache/cassandra/db/ReadVerbHandler.java
Author: jbellis Date: Thu Sep 8 19:26:34 2011 New Revision: 1166865 URL: http://svn.apache.org/viewvc?rev=1166865view=rev Log: reset ReadVerbHandler buffer between uses patch by jbellis; reviewed by brandonwilliams for CASSANDRA-3156 Modified: cassandra/trunk/src/java/org/apache/cassandra/db/ReadVerbHandler.java Modified: cassandra/trunk/src/java/org/apache/cassandra/db/ReadVerbHandler.java URL: http://svn.apache.org/viewvc/cassandra/trunk/src/java/org/apache/cassandra/db/ReadVerbHandler.java?rev=1166865r1=1166864r2=1166865view=diff == --- cassandra/trunk/src/java/org/apache/cassandra/db/ReadVerbHandler.java (original) +++ cassandra/trunk/src/java/org/apache/cassandra/db/ReadVerbHandler.java Thu Sep 8 19:26:34 2011 @@ -62,6 +62,7 @@ public class ReadVerbHandler implements Row row = command.getRow(table); DataOutputBuffer out = threadLocalOut.get(); +out.reset(); ReadResponse.serializer().serialize(getResponse(command, row), out, message.getVersion()); byte[] bytes = new byte[out.getLength()]; System.arraycopy(out.getData(), 0, bytes, 0, bytes.length);
[jira] [Resolved] (CASSANDRA-3156) assertion error in RowRepairResolver
[ https://issues.apache.org/jira/browse/CASSANDRA-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-3156. --- Resolution: Fixed Reviewer: brandon.williams Assignee: Jonathan Ellis committed assertion error in RowRepairResolver Key: CASSANDRA-3156 URL: https://issues.apache.org/jira/browse/CASSANDRA-3156 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0 Reporter: Brandon Williams Assignee: Jonathan Ellis Priority: Blocker Fix For: 1.0 Attachments: 3156.txt Only seems to happen on a coordinator who does not have a copy of the data: DEBUG 03:15:59,866 Processing response on a callback from 3840@/10.179.64.227 DEBUG 03:15:59,866 Preprocessed data response DEBUG 03:15:59,866 Processing response on a callback from 3841@/10.179.111.137 DEBUG 03:15:59,866 Preprocessed digest response DEBUG 03:15:59,865 Processing response on a callback from 3837@/10.179.111.137 DEBUG 03:15:59,865 Preprocessed data response DEBUG 03:15:59,865 Preprocessed data response DEBUG 03:15:59,867 Preprocessed digest response DEBUG 03:15:59,867 resolving 2 responses ERROR 03:15:59,866 Fatal exception in thread Thread[ReadRepairStage:526,5,main] java.lang.AssertionError at org.apache.cassandra.service.RowRepairResolver.resolve(RowRepairResolver.java:77) at org.apache.cassandra.service.AsyncRepairCallback$1.runMayThrow(AsyncRepairCallback.java:54) at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) 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) ERROR 03:15:59,866 Fatal exception in thread Thread[ReadRepairStage:525,5,main] java.lang.AssertionError at org.apache.cassandra.service.RowRepairResolver.resolve(RowRepairResolver.java:77) at org.apache.cassandra.service.AsyncRepairCallback$1.runMayThrow(AsyncRepairCallback.java:54) at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) 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) ERROR 03:15:59,867 Fatal exception in thread Thread[ReadRepairStage:528,5,main] java.lang.AssertionError at org.apache.cassandra.service.RowRepairResolver.resolve(RowRepairResolver.java:77) at org.apache.cassandra.service.AsyncRepairCallback$1.runMayThrow(AsyncRepairCallback.java:54) at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) 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) DEBUG 03:15:59,867 resolving 2 responses DEBUG 03:15:59,867 resolving 2 responses DEBUG 03:15:59,867 resolving 2 responses -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2882) describe_ring should include datacenter/topology information
[ https://issues.apache.org/jira/browse/CASSANDRA-2882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100622#comment-13100622 ] Pavel Yaskevich commented on CASSANDRA-2882: Few notes: - I don't think that we need to add EndpointDetails without information about datacenter or port. - Please instead of {noformat}tr.endpoint_details = epDetails;{noformat} do {noformat}new TokenRange(tf.toString(range.left), tf.toString(range.right), endpoints).setEndpoint_details(epDetails);{noformat} because that way thrift will mark that field as set. Looks good otherwise. describe_ring should include datacenter/topology information Key: CASSANDRA-2882 URL: https://issues.apache.org/jira/browse/CASSANDRA-2882 Project: Cassandra Issue Type: Improvement Components: API, Core Reporter: Mark Guzman Assignee: Pavel Yaskevich Priority: Minor Labels: lhf Fix For: 1.1 Attachments: 0001-CASSANDRA-2882-patch-w-o-generated-files.patch, 0001-CASSANDRA-2882-rebased.patch, 0001-adding-an-additional-parameter-to-the-TokenRange-res.patch, 0001-final-cleaned-up-2882-changes.patch describe_ring is great for getting a list of nodes in the cluster, but it doesn't provide any information about the network topology which prevents it's use in a multi-dc setup. It would be nice if we added another list to the TokenRange object containing the DC information. Optimally I could have ask any Cassandra node for this information and on the client-side prefer local nodes but be able to fail to remote nodes without requiring another lookup. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2882) describe_ring should include datacenter/topology information
[ https://issues.apache.org/jira/browse/CASSANDRA-2882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100622#comment-13100622 ] Pavel Yaskevich edited comment on CASSANDRA-2882 at 9/8/11 7:32 PM: Few notes: - I don't think that we need to add EndpointDetails without information about datacenter or port, having (-1, null) there is misleading. - Please instead of {noformat}tr.endpoint_details = epDetails;{noformat} do {noformat}new TokenRange(tf.toString(range.left), tf.toString(range.right), endpoints).setEndpoint_details(epDetails);{noformat} because that way thrift will mark that field as set. Looks good otherwise. was (Author: xedin): Few notes: - I don't think that we need to add EndpointDetails without information about datacenter or port. - Please instead of {noformat}tr.endpoint_details = epDetails;{noformat} do {noformat}new TokenRange(tf.toString(range.left), tf.toString(range.right), endpoints).setEndpoint_details(epDetails);{noformat} because that way thrift will mark that field as set. Looks good otherwise. describe_ring should include datacenter/topology information Key: CASSANDRA-2882 URL: https://issues.apache.org/jira/browse/CASSANDRA-2882 Project: Cassandra Issue Type: Improvement Components: API, Core Reporter: Mark Guzman Assignee: Pavel Yaskevich Priority: Minor Labels: lhf Fix For: 1.1 Attachments: 0001-CASSANDRA-2882-patch-w-o-generated-files.patch, 0001-CASSANDRA-2882-rebased.patch, 0001-adding-an-additional-parameter-to-the-TokenRange-res.patch, 0001-final-cleaned-up-2882-changes.patch describe_ring is great for getting a list of nodes in the cluster, but it doesn't provide any information about the network topology which prevents it's use in a multi-dc setup. It would be nice if we added another list to the TokenRange object containing the DC information. Optimally I could have ask any Cassandra node for this information and on the client-side prefer local nodes but be able to fail to remote nodes without requiring another lookup. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2882) describe_ring should include datacenter/topology information
[ https://issues.apache.org/jira/browse/CASSANDRA-2882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100622#comment-13100622 ] Pavel Yaskevich edited comment on CASSANDRA-2882 at 9/8/11 7:35 PM: Few notes: - I don't think that we need to add EndpointDetails without information about datacenter or port, having (-1, null) there is misleading. - you can change Vector to ArrayList because you don't use any vector specific features such as capacity planing and auto-resize etc. - Please instead of {noformat}tr.endpoint_details = epDetails;{noformat} do {noformat}new TokenRange(tf.toString(range.left), tf.toString(range.right), endpoints).setEndpoint_details(epDetails);{noformat} because that way thrift will mark that field as set. Looks good otherwise. was (Author: xedin): Few notes: - I don't think that we need to add EndpointDetails without information about datacenter or port, having (-1, null) there is misleading. - Please instead of {noformat}tr.endpoint_details = epDetails;{noformat} do {noformat}new TokenRange(tf.toString(range.left), tf.toString(range.right), endpoints).setEndpoint_details(epDetails);{noformat} because that way thrift will mark that field as set. Looks good otherwise. describe_ring should include datacenter/topology information Key: CASSANDRA-2882 URL: https://issues.apache.org/jira/browse/CASSANDRA-2882 Project: Cassandra Issue Type: Improvement Components: API, Core Reporter: Mark Guzman Assignee: Pavel Yaskevich Priority: Minor Labels: lhf Fix For: 1.1 Attachments: 0001-CASSANDRA-2882-patch-w-o-generated-files.patch, 0001-CASSANDRA-2882-rebased.patch, 0001-adding-an-additional-parameter-to-the-TokenRange-res.patch, 0001-final-cleaned-up-2882-changes.patch describe_ring is great for getting a list of nodes in the cluster, but it doesn't provide any information about the network topology which prevents it's use in a multi-dc setup. It would be nice if we added another list to the TokenRange object containing the DC information. Optimally I could have ask any Cassandra node for this information and on the client-side prefer local nodes but be able to fail to remote nodes without requiring another lookup. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2961) Expire dead gossip states based on time
[ https://issues.apache.org/jira/browse/CASSANDRA-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jérémy Sevellec updated CASSANDRA-2961: --- Attachment: trunk-2961-v3.patch Expire dead gossip states based on time --- Key: CASSANDRA-2961 URL: https://issues.apache.org/jira/browse/CASSANDRA-2961 Project: Cassandra Issue Type: Improvement Affects Versions: 1.0 Reporter: Brandon Williams Priority: Minor Fix For: 1.1 Attachments: trunk-2961-v2.patch, trunk-2961-v3.patch, trunk-2961.patch Currently dead states are held until aVeryLongTime, 3 days. The problem is that if a node reboots within this period, it begins a new 3 days and will repopulate the ring with the dead state. While mostly harmless, perpetuating the state forever is at least wasting a small amount of bandwidth. Instead, we can expire states based on a ttl, which will require that the cluster be loosely time synced; within the quarantine period of 60s. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1166876 - /cassandra/trunk/src/java/org/apache/cassandra/utils/SlabAllocator.java
Author: jbellis Date: Thu Sep 8 19:50:06 2011 New Revision: 1166876 URL: http://svn.apache.org/viewvc?rev=1166876view=rev Log: use weak references to track slab regions patch by jbellis; reviewed by stuhood for CASSANDRA-3162 Modified: cassandra/trunk/src/java/org/apache/cassandra/utils/SlabAllocator.java Modified: cassandra/trunk/src/java/org/apache/cassandra/utils/SlabAllocator.java URL: http://svn.apache.org/viewvc/cassandra/trunk/src/java/org/apache/cassandra/utils/SlabAllocator.java?rev=1166876r1=1166875r2=1166876view=diff == --- cassandra/trunk/src/java/org/apache/cassandra/utils/SlabAllocator.java (original) +++ cassandra/trunk/src/java/org/apache/cassandra/utils/SlabAllocator.java Thu Sep 8 19:50:06 2011 @@ -28,6 +28,7 @@ import java.util.concurrent.atomic.Atomi import com.google.common.base.Preconditions; import com.google.common.collect.Iterables; +import com.google.common.collect.MapMaker; /** * The SlabAllocator is a bump-the-pointer allocator that allocates @@ -45,11 +46,11 @@ import com.google.common.collect.Iterabl */ public class SlabAllocator extends Allocator { -private final static int REGION_SIZE = 2 * 1024 * 1024; -private final static int MAX_CLONED_SIZE = 256 * 1024; // bigger than this don't go in the region +private final static int REGION_SIZE = 1024 * 1024; +private final static int MAX_CLONED_SIZE = 128 * 1024; // bigger than this don't go in the region private final AtomicReferenceRegion currentRegion = new AtomicReferenceRegion(); -private final CollectionRegion filledRegions = new LinkedBlockingQueueRegion(); +private final CollectionRegion filledRegions = Collections.newSetFromMap(new MapMaker().weakKeys().Region, BooleanmakeMap()); /** @return Total number of bytes allocated by this allocator. */ public long size()
svn commit: r1166877 - /cassandra/trunk/CHANGES.txt
Author: jbellis Date: Thu Sep 8 19:50:57 2011 New Revision: 1166877 URL: http://svn.apache.org/viewvc?rev=1166877view=rev Log: update CHANGES Modified: cassandra/trunk/CHANGES.txt Modified: cassandra/trunk/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/trunk/CHANGES.txt?rev=1166877r1=1166876r2=1166877view=diff == --- cassandra/trunk/CHANGES.txt (original) +++ cassandra/trunk/CHANGES.txt Thu Sep 8 19:50:57 2011 @@ -67,6 +67,7 @@ * fix inconsistency of the CLI syntax when {} should be used instead of [{}] (CASSANDRA-3119) * rename CQL type names to match expected SQL behavior (CASSANDRA-3149) + * Arena-based allocation for memtables (CASSANDRA-2252, 3162) 0.8.6
[jira] [Commented] (CASSANDRA-2961) Expire dead gossip states based on time
[ https://issues.apache.org/jira/browse/CASSANDRA-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100637#comment-13100637 ] Jérémy Sevellec commented on CASSANDRA-2961: You can find an new version of the patch : - without hamcrest dependency - compute the generation of expireTime into gossiper and calling it into the constructor of VV - modify SS to be more readable I hope it's ok :-) Expire dead gossip states based on time --- Key: CASSANDRA-2961 URL: https://issues.apache.org/jira/browse/CASSANDRA-2961 Project: Cassandra Issue Type: Improvement Affects Versions: 1.0 Reporter: Brandon Williams Priority: Minor Fix For: 1.1 Attachments: trunk-2961-v2.patch, trunk-2961-v3.patch, trunk-2961.patch Currently dead states are held until aVeryLongTime, 3 days. The problem is that if a node reboots within this period, it begins a new 3 days and will repopulate the ring with the dead state. While mostly harmless, perpetuating the state forever is at least wasting a small amount of bandwidth. Instead, we can expire states based on a ttl, which will require that the cluster be loosely time synced; within the quarantine period of 60s. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2890) Randomize (to some extend) the choice of the first replica for counter increment
[ https://issues.apache.org/jira/browse/CASSANDRA-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2890: -- Fix Version/s: 1.1 David Hawthorne reports on the mailing list that he ran into this in the wild: {quote} It was exactly due to 2890, and the fact that the first replica is always the one with the lowest value IP address. I patched cassandra to pick a random node out of the replica set in StorageProxy.java findSuitableEndpoint: Random rng = new Random(); return endpoints.get(rng.nextInt(endpoints.size())); // instead of return endpoints.get(0); Now work load is evenly balanced among all 5 nodes and I'm getting 2.5x the inserts/sec throughput. Here's the behavior I saw, and disk work refers to the ReplicateOnWrite load of a counter insert: One node will get RF/n of the disk work. Two nodes will always get 0 disk work. in a 3 node cluster, 1 node gets disk hit really hard. You get the performance of a one-node cluster. in a 6 node cluster, 1 node gets hit with 50% of the disk work, giving you the performance of ~2 node cluster. in a 10 node cluster, 1 node gets 30% of the disk work, giving you the performance of a ~3 node cluster. I confirmed this behavior with a 3, 4, and 5 node cluster size. {quote} Randomize (to some extend) the choice of the first replica for counter increment Key: CASSANDRA-2890 URL: https://issues.apache.org/jira/browse/CASSANDRA-2890 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.8.0 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Labels: counters Fix For: 1.1 Right now, we choose the first replica for a counter increments based solely on what the snitch returns. If the clients requests are well balanced over the cluster and the snitch not ill configured, this should not be a problem, but this is probably too strong an assumption to make. The goal of this ticket is to change this to choose a random replica in the current data center instead. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2961) Expire dead gossip states based on time
[ https://issues.apache.org/jira/browse/CASSANDRA-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100637#comment-13100637 ] Jérémy Sevellec edited comment on CASSANDRA-2961 at 9/8/11 8:21 PM: You can find an new version of the patch : - without hamcrest dependency - compute the generation of expireTime into gossiper and calling it into the constructor of VV - modify SS to be more readable - adding some log I hope it's ok :-) was (Author: jsevellec): You can find an new version of the patch : - without hamcrest dependency - compute the generation of expireTime into gossiper and calling it into the constructor of VV - modify SS to be more readable I hope it's ok :-) Expire dead gossip states based on time --- Key: CASSANDRA-2961 URL: https://issues.apache.org/jira/browse/CASSANDRA-2961 Project: Cassandra Issue Type: Improvement Affects Versions: 1.0 Reporter: Brandon Williams Priority: Minor Fix For: 1.1 Attachments: trunk-2961-v2.patch, trunk-2961-v3.patch, trunk-2961.patch Currently dead states are held until aVeryLongTime, 3 days. The problem is that if a node reboots within this period, it begins a new 3 days and will repopulate the ring with the dead state. While mostly harmless, perpetuating the state forever is at least wasting a small amount of bandwidth. Instead, we can expire states based on a ttl, which will require that the cluster be loosely time synced; within the quarantine period of 60s. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3162) use weak references to SlabAllocator regions
[ https://issues.apache.org/jira/browse/CASSANDRA-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100669#comment-13100669 ] Hudson commented on CASSANDRA-3162: --- Integrated in Cassandra #1092 (See [https://builds.apache.org/job/Cassandra/1092/]) use weak references to track slab regions patch by jbellis; reviewed by stuhood for CASSANDRA-3162 jbellis : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1166876 Files : * /cassandra/trunk/src/java/org/apache/cassandra/utils/SlabAllocator.java use weak references to SlabAllocator regions Key: CASSANDRA-3162 URL: https://issues.apache.org/jira/browse/CASSANDRA-3162 Project: Cassandra Issue Type: Improvement Affects Versions: 1.0 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 1.0 Attachments: 3162.txt Yang points out on CASSANDRA-2252, Conceivably, one region would contain bytebuffer values of similar age. as more updates come in, all the columns in older regions are likely to have all died out, thus allowing us to free the entire region before flushing happens. So it's a bit of a corner case optimization, but easy to do and safe. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3156) assertion error in RowRepairResolver
[ https://issues.apache.org/jira/browse/CASSANDRA-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100670#comment-13100670 ] Hudson commented on CASSANDRA-3156: --- Integrated in Cassandra #1092 (See [https://builds.apache.org/job/Cassandra/1092/]) reset ReadVerbHandler buffer between uses patch by jbellis; reviewed by brandonwilliams for CASSANDRA-3156 jbellis : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1166865 Files : * /cassandra/trunk/src/java/org/apache/cassandra/db/ReadVerbHandler.java assertion error in RowRepairResolver Key: CASSANDRA-3156 URL: https://issues.apache.org/jira/browse/CASSANDRA-3156 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0 Reporter: Brandon Williams Assignee: Jonathan Ellis Priority: Blocker Fix For: 1.0 Attachments: 3156.txt Only seems to happen on a coordinator who does not have a copy of the data: DEBUG 03:15:59,866 Processing response on a callback from 3840@/10.179.64.227 DEBUG 03:15:59,866 Preprocessed data response DEBUG 03:15:59,866 Processing response on a callback from 3841@/10.179.111.137 DEBUG 03:15:59,866 Preprocessed digest response DEBUG 03:15:59,865 Processing response on a callback from 3837@/10.179.111.137 DEBUG 03:15:59,865 Preprocessed data response DEBUG 03:15:59,865 Preprocessed data response DEBUG 03:15:59,867 Preprocessed digest response DEBUG 03:15:59,867 resolving 2 responses ERROR 03:15:59,866 Fatal exception in thread Thread[ReadRepairStage:526,5,main] java.lang.AssertionError at org.apache.cassandra.service.RowRepairResolver.resolve(RowRepairResolver.java:77) at org.apache.cassandra.service.AsyncRepairCallback$1.runMayThrow(AsyncRepairCallback.java:54) at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) 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) ERROR 03:15:59,866 Fatal exception in thread Thread[ReadRepairStage:525,5,main] java.lang.AssertionError at org.apache.cassandra.service.RowRepairResolver.resolve(RowRepairResolver.java:77) at org.apache.cassandra.service.AsyncRepairCallback$1.runMayThrow(AsyncRepairCallback.java:54) at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) 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) ERROR 03:15:59,867 Fatal exception in thread Thread[ReadRepairStage:528,5,main] java.lang.AssertionError at org.apache.cassandra.service.RowRepairResolver.resolve(RowRepairResolver.java:77) at org.apache.cassandra.service.AsyncRepairCallback$1.runMayThrow(AsyncRepairCallback.java:54) at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) 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) DEBUG 03:15:59,867 resolving 2 responses DEBUG 03:15:59,867 resolving 2 responses DEBUG 03:15:59,867 resolving 2 responses -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2961) Expire dead gossip states based on time
[ https://issues.apache.org/jira/browse/CASSANDRA-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jérémy Sevellec updated CASSANDRA-2961: --- Attachment: (was: trunk-2961-v3.patch) Expire dead gossip states based on time --- Key: CASSANDRA-2961 URL: https://issues.apache.org/jira/browse/CASSANDRA-2961 Project: Cassandra Issue Type: Improvement Affects Versions: 1.0 Reporter: Brandon Williams Priority: Minor Fix For: 1.1 Attachments: trunk-2961-v2.patch, trunk-2961.patch Currently dead states are held until aVeryLongTime, 3 days. The problem is that if a node reboots within this period, it begins a new 3 days and will repopulate the ring with the dead state. While mostly harmless, perpetuating the state forever is at least wasting a small amount of bandwidth. Instead, we can expire states based on a ttl, which will require that the cluster be loosely time synced; within the quarantine period of 60s. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2961) Expire dead gossip states based on time
[ https://issues.apache.org/jira/browse/CASSANDRA-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jérémy Sevellec updated CASSANDRA-2961: --- Attachment: trunk-2961-v3.patch Expire dead gossip states based on time --- Key: CASSANDRA-2961 URL: https://issues.apache.org/jira/browse/CASSANDRA-2961 Project: Cassandra Issue Type: Improvement Affects Versions: 1.0 Reporter: Brandon Williams Priority: Minor Fix For: 1.1 Attachments: trunk-2961-v2.patch, trunk-2961-v3.patch, trunk-2961.patch Currently dead states are held until aVeryLongTime, 3 days. The problem is that if a node reboots within this period, it begins a new 3 days and will repopulate the ring with the dead state. While mostly harmless, perpetuating the state forever is at least wasting a small amount of bandwidth. Instead, we can expire states based on a ttl, which will require that the cluster be loosely time synced; within the quarantine period of 60s. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2975) Upgrade MurmurHash to version 3
[ https://issues.apache.org/jira/browse/CASSANDRA-2975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Lindauer updated CASSANDRA-2975: -- Attachment: 0001-Convert-BloomFilter-to-use-MurmurHash-v3-instead-of-.patch Murmur3 changes Upgrade MurmurHash to version 3 --- Key: CASSANDRA-2975 URL: https://issues.apache.org/jira/browse/CASSANDRA-2975 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Brian Lindauer Assignee: Brian Lindauer Priority: Trivial Labels: lhf Fix For: 1.1 Attachments: 0001-Convert-BloomFilter-to-use-MurmurHash-v3-instead-of-.patch, 0002-Backwards-compatibility-with-files-using-Murmur2-blo.patch MurmurHash version 3 was finalized on June 3. It provides an enormous speedup and increased robustness over version 2, which is implemented in Cassandra. Information here: http://code.google.com/p/smhasher/ The reference implementation is here: http://code.google.com/p/smhasher/source/browse/trunk/MurmurHash3.cpp?spec=svn136r=136 I have already done the work to port the (public domain) reference implementation to Java in the MurmurHash class and updated the BloomFilter class to use the new implementation: https://github.com/lindauer/cassandra/commit/cea6068a4a3e5d7d9509335394f9ef3350d37e93 Apart from the faster hash time, the new version only requires one call to hash() rather than 2, since it returns 128 bits of hash instead of 64. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2975) Upgrade MurmurHash to version 3
[ https://issues.apache.org/jira/browse/CASSANDRA-2975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Lindauer updated CASSANDRA-2975: -- Attachment: 0002-Backwards-compatibility-with-files-using-Murmur2-blo.patch Murmur3-Murmur2 backwards compatibility Upgrade MurmurHash to version 3 --- Key: CASSANDRA-2975 URL: https://issues.apache.org/jira/browse/CASSANDRA-2975 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Brian Lindauer Assignee: Brian Lindauer Priority: Trivial Labels: lhf Fix For: 1.1 Attachments: 0001-Convert-BloomFilter-to-use-MurmurHash-v3-instead-of-.patch, 0002-Backwards-compatibility-with-files-using-Murmur2-blo.patch MurmurHash version 3 was finalized on June 3. It provides an enormous speedup and increased robustness over version 2, which is implemented in Cassandra. Information here: http://code.google.com/p/smhasher/ The reference implementation is here: http://code.google.com/p/smhasher/source/browse/trunk/MurmurHash3.cpp?spec=svn136r=136 I have already done the work to port the (public domain) reference implementation to Java in the MurmurHash class and updated the BloomFilter class to use the new implementation: https://github.com/lindauer/cassandra/commit/cea6068a4a3e5d7d9509335394f9ef3350d37e93 Apart from the faster hash time, the new version only requires one call to hash() rather than 2, since it returns 128 bits of hash instead of 64. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-3163) SlabAllocator OOMs much faster than HeapAllocator
SlabAllocator OOMs much faster than HeapAllocator - Key: CASSANDRA-3163 URL: https://issues.apache.org/jira/browse/CASSANDRA-3163 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0 Environment: 3 nodes, 1G heap, RF=2 Reporter: Brandon Williams Fix For: 1.0 SlabAllocator will OOM with stress at around 5.5M rows, which in this configuration is roughly 3.3M rows per node. Reverting to the HeapAllocator allowed all 10M rows to finish. Examining the SA heap dump in MAT just shows ~98% of the heap is in 'remainder' -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3163) SlabAllocator OOMs much faster than HeapAllocator
[ https://issues.apache.org/jira/browse/CASSANDRA-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100680#comment-13100680 ] Jonathan Ellis commented on CASSANDRA-3163: --- what liveRatio was it logging on the OOM run? SlabAllocator OOMs much faster than HeapAllocator - Key: CASSANDRA-3163 URL: https://issues.apache.org/jira/browse/CASSANDRA-3163 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0 Environment: 3 nodes, 1G heap, RF=2 Reporter: Brandon Williams Fix For: 1.0 SlabAllocator will OOM with stress at around 5.5M rows, which in this configuration is roughly 3.3M rows per node. Reverting to the HeapAllocator allowed all 10M rows to finish. Examining the SA heap dump in MAT just shows ~98% of the heap is in 'remainder' -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-3164) GCInspector still not avoiding divide by zero
GCInspector still not avoiding divide by zero - Key: CASSANDRA-3164 URL: https://issues.apache.org/jira/browse/CASSANDRA-3164 Project: Cassandra Issue Type: Bug Reporter: Jonathan Ellis Priority: Minor This is because Long objects need to be compared with .equals, not ==. CASSANDRA-3076 is the original issue but we should use a new ticket for this since 0.7.9 and 0.8.5 are both released already. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3163) SlabAllocator OOMs much faster than HeapAllocator
[ https://issues.apache.org/jira/browse/CASSANDRA-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-3163: Attachment: system.log.gz Here's a system.log with your extra debug statements and Memtable set to DEBUG. It OOM'd many times, but never actually dumped. SlabAllocator OOMs much faster than HeapAllocator - Key: CASSANDRA-3163 URL: https://issues.apache.org/jira/browse/CASSANDRA-3163 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0 Environment: 3 nodes, 1G heap, RF=2 Reporter: Brandon Williams Fix For: 1.0 Attachments: system.log.gz SlabAllocator will OOM with stress at around 5.5M rows, which in this configuration is roughly 3.3M rows per node. Reverting to the HeapAllocator allowed all 10M rows to finish. Examining the SA heap dump in MAT just shows ~98% of the heap is in 'remainder' -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2890) Randomize (to some extend) the choice of the first replica for counter increment
[ https://issues.apache.org/jira/browse/CASSANDRA-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100715#comment-13100715 ] Stu Hood commented on CASSANDRA-2890: - Randomizing the first replica will break dynamic snitch behaviour. If we're assuming: 1) everyone uses the dynamic snitch 2) some folks perform nearly 100% writes, and very few client reads ...would it be better to start recording the replicate-on-writes latencies in the dynamic snitch, so that the first replica will be chosen based on latency, rather than raw snitch scores? Randomize (to some extend) the choice of the first replica for counter increment Key: CASSANDRA-2890 URL: https://issues.apache.org/jira/browse/CASSANDRA-2890 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.8.0 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Labels: counters Fix For: 1.1 Right now, we choose the first replica for a counter increments based solely on what the snitch returns. If the clients requests are well balanced over the cluster and the snitch not ill configured, this should not be a problem, but this is probably too strong an assumption to make. The goal of this ticket is to change this to choose a random replica in the current data center instead. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2388) ColumnFamilyRecordReader fails for a given split because a host is down, even if records could reasonably be read from other replica.
[ https://issues.apache.org/jira/browse/CASSANDRA-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100717#comment-13100717 ] Mck SembWever commented on CASSANDRA-2388: -- Well that would work for me, was only thinking you want to push a default behavior (especially for those using a RP). But I think a better understanding (at least from me) of hadoop's task scheduling is required before enforcing data locality, as as-is it certainly doesn't work. ColumnFamilyRecordReader fails for a given split because a host is down, even if records could reasonably be read from other replica. - Key: CASSANDRA-2388 URL: https://issues.apache.org/jira/browse/CASSANDRA-2388 Project: Cassandra Issue Type: Bug Components: Hadoop Affects Versions: 0.6 Reporter: Eldon Stegall Assignee: Mck SembWever Labels: hadoop, inputformat Fix For: 0.8.6 Attachments: 0002_On_TException_try_next_split.patch, CASSANDRA-2388-addition1.patch, CASSANDRA-2388-extended.patch, CASSANDRA-2388.patch, CASSANDRA-2388.patch, CASSANDRA-2388.patch, CASSANDRA-2388.patch ColumnFamilyRecordReader only tries the first location for a given split. We should try multiple locations for a given split. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2388) ColumnFamilyRecordReader fails for a given split because a host is down, even if records could reasonably be read from other replica.
[ https://issues.apache.org/jira/browse/CASSANDRA-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100717#comment-13100717 ] Mck SembWever edited comment on CASSANDRA-2388 at 9/8/11 9:37 PM: -- Well that would work for me, was only thinking you want to push a default behavior (especially for those using a RP). But I think a better understanding (at least from me) of hadoop's task scheduling is required before enforcing data locality, as as-is it certainly doesn't work for all. was (Author: michaelsembwever): Well that would work for me, was only thinking you want to push a default behavior (especially for those using a RP). But I think a better understanding (at least from me) of hadoop's task scheduling is required before enforcing data locality, as as-is it certainly doesn't work. ColumnFamilyRecordReader fails for a given split because a host is down, even if records could reasonably be read from other replica. - Key: CASSANDRA-2388 URL: https://issues.apache.org/jira/browse/CASSANDRA-2388 Project: Cassandra Issue Type: Bug Components: Hadoop Affects Versions: 0.6 Reporter: Eldon Stegall Assignee: Mck SembWever Labels: hadoop, inputformat Fix For: 0.8.6 Attachments: 0002_On_TException_try_next_split.patch, CASSANDRA-2388-addition1.patch, CASSANDRA-2388-extended.patch, CASSANDRA-2388.patch, CASSANDRA-2388.patch, CASSANDRA-2388.patch, CASSANDRA-2388.patch ColumnFamilyRecordReader only tries the first location for a given split. We should try multiple locations for a given split. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2434) node bootstrapping can violate consistency
[ https://issues.apache.org/jira/browse/CASSANDRA-2434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] paul cannon updated CASSANDRA-2434: --- Attachment: 2434-3.patch.txt 2434-3.patch.txt removes the bits that add the -n option to nodetool join. Apparently no nodetool join should ever result in a bootstrap, so it doesn't matter whether the caller wants strict or not. node bootstrapping can violate consistency -- Key: CASSANDRA-2434 URL: https://issues.apache.org/jira/browse/CASSANDRA-2434 Project: Cassandra Issue Type: Bug Reporter: Peter Schuller Assignee: paul cannon Fix For: 1.1 Attachments: 2434-3.patch.txt, 2434-testery.patch.txt My reading (a while ago) of the code indicates that there is no logic involved during bootstrapping that avoids consistency level violations. If I recall correctly it just grabs neighbors that are currently up. There are at least two issues I have with this behavior: * If I have a cluster where I have applications relying on QUORUM with RF=3, and bootstrapping complete based on only one node, I have just violated the supposedly guaranteed consistency semantics of the cluster. * Nodes can flap up and down at any time, so even if a human takes care to look at which nodes are up and things about it carefully before bootstrapping, there's no guarantee. A complication is that not only does it depend on use-case where this is an issue (if all you ever do you do at CL.ONE, it's fine); even in a cluster which is otherwise used for QUORUM operations you may wish to accept less-than-quorum nodes during bootstrap in various emergency situations. A potential easy fix is to have bootstrap take an argument which is the number of hosts to bootstrap from, or to assume QUORUM if none is given. (A related concern is bootstrapping across data centers. You may *want* to bootstrap to a local node and then do a repair to avoid sending loads of data across DC:s while still achieving consistency. Or even if you don't care about the consistency issues, I don't think there is currently a way to bootstrap from local nodes only.) Thoughts? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2434) node bootstrapping can violate consistency
[ https://issues.apache.org/jira/browse/CASSANDRA-2434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] paul cannon updated CASSANDRA-2434: --- Attachment: (was: 2434-2.patch.txt) node bootstrapping can violate consistency -- Key: CASSANDRA-2434 URL: https://issues.apache.org/jira/browse/CASSANDRA-2434 Project: Cassandra Issue Type: Bug Reporter: Peter Schuller Assignee: paul cannon Fix For: 1.1 Attachments: 2434-3.patch.txt, 2434-testery.patch.txt My reading (a while ago) of the code indicates that there is no logic involved during bootstrapping that avoids consistency level violations. If I recall correctly it just grabs neighbors that are currently up. There are at least two issues I have with this behavior: * If I have a cluster where I have applications relying on QUORUM with RF=3, and bootstrapping complete based on only one node, I have just violated the supposedly guaranteed consistency semantics of the cluster. * Nodes can flap up and down at any time, so even if a human takes care to look at which nodes are up and things about it carefully before bootstrapping, there's no guarantee. A complication is that not only does it depend on use-case where this is an issue (if all you ever do you do at CL.ONE, it's fine); even in a cluster which is otherwise used for QUORUM operations you may wish to accept less-than-quorum nodes during bootstrap in various emergency situations. A potential easy fix is to have bootstrap take an argument which is the number of hosts to bootstrap from, or to assume QUORUM if none is given. (A related concern is bootstrapping across data centers. You may *want* to bootstrap to a local node and then do a repair to avoid sending loads of data across DC:s while still achieving consistency. Or even if you don't care about the consistency issues, I don't think there is currently a way to bootstrap from local nodes only.) Thoughts? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira