[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.

2011-09-08 Thread Mck SembWever (JIRA)

[ 
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

2011-09-08 Thread Mark Guzman (JIRA)

 [ 
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

2011-09-08 Thread JIRA

[ 
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

2011-09-08 Thread slebresne
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

2011-09-08 Thread Smartree (JIRA)

[ 
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

2011-09-08 Thread Hudson (JIRA)

[ 
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

2011-09-08 Thread Sylvain Lebresne (JIRA)

[ 
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

2011-09-08 Thread Sylvain Lebresne (JIRA)

[ 
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/

2011-09-08 Thread Sylvain Lebresne (JIRA)

[ 
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

2011-09-08 Thread Sylvain Lebresne (JIRA)

[ 
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

2011-09-08 Thread Pavel Yaskevich (JIRA)

[ 
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

2011-09-08 Thread Apache Wiki
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/

2011-09-08 Thread slebresne
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

2011-09-08 Thread slebresne
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.

2011-09-08 Thread Jonathan Ellis (JIRA)

[ 
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

2011-09-08 Thread Jonathan Ellis (JIRA)

[ 
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

2011-09-08 Thread Jonathan Ellis (JIRA)

[ 
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

2011-09-08 Thread Sylvain Lebresne (JIRA)

 [ 
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

2011-09-08 Thread Sylvain Lebresne (JIRA)
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

2011-09-08 Thread Mark Guzman (JIRA)

 [ 
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

2011-09-08 Thread Mark Guzman (JIRA)

 [ 
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

2011-09-08 Thread Jonathan Ellis (JIRA)
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

2011-09-08 Thread Pavel Yaskevich (JIRA)

[ 
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

2011-09-08 Thread Jonathan Ellis (JIRA)

 [ 
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

2011-09-08 Thread Mark Guzman (JIRA)

 [ 
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

2011-09-08 Thread Mark Guzman (JIRA)

[ 
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

2011-09-08 Thread Pavel Yaskevich (JIRA)

[ 
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

2011-09-08 Thread Pavel Yaskevich (JIRA)

[ 
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

2011-09-08 Thread Jonathan Ellis (JIRA)

[ 
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

2011-09-08 Thread Sylvain Lebresne (JIRA)

[ 
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

2011-09-08 Thread Pavel Yaskevich (JIRA)

[ 
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

2011-09-08 Thread slebresne
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

2011-09-08 Thread Jonathan Ellis (JIRA)

 [ 
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

2011-09-08 Thread Jonathan Ellis (JIRA)

 [ 
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

2011-09-08 Thread Sylvain Lebresne (JIRA)

[ 
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

2011-09-08 Thread T Jake Luciani (JIRA)
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

2011-09-08 Thread Jonathan Ellis (JIRA)

[ 
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

2011-09-08 Thread Sylvain Lebresne (JIRA)

[ 
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

2011-09-08 Thread Hudson (JIRA)

[ 
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

2011-09-08 Thread Eric Evans (JIRA)

 [ 
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

2011-09-08 Thread T Jake Luciani (JIRA)

[ 
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

2011-09-08 Thread jbellis
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.

2011-09-08 Thread Eldon Stegall (JIRA)

 [ 
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.

2011-09-08 Thread Eldon Stegall (JIRA)
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.

2011-09-08 Thread Jonathan Ellis (JIRA)

 [ 
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

2011-09-08 Thread luwei (JIRA)

[ 
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/

2011-09-08 Thread jbellis
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/

2011-09-08 Thread jbellis
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

2011-09-08 Thread Jonathan Ellis (JIRA)

[ 
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

2011-09-08 Thread Anton Vedeshin (JIRA)

[ 
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

2011-09-08 Thread Mark Guzman (JIRA)

 [ 
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

2011-09-08 Thread Benoit Perroud (JIRA)

[ 
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

2011-09-08 Thread Jonathan Ellis (JIRA)
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

2011-09-08 Thread Jonathan Ellis (JIRA)

 [ 
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

2011-09-08 Thread brandonwilliams
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

2011-09-08 Thread Brandon Williams (JIRA)

[ 
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

2011-09-08 Thread Brandon Williams (JIRA)

[ 
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()

2011-09-08 Thread Benjamin Coverston (JIRA)

[ 
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

2011-09-08 Thread Jonathan Ellis (JIRA)

[ 
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

2011-09-08 Thread Jonathan Ellis (JIRA)

 [ 
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/

2011-09-08 Thread brandonwilliams
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

2011-09-08 Thread Hudson (JIRA)

[ 
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.

2011-09-08 Thread Hudson (JIRA)

[ 
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

2011-09-08 Thread jbellis
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

2011-09-08 Thread Jonathan Ellis (JIRA)
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

2011-09-08 Thread Jonathan Ellis (JIRA)

 [ 
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

2011-09-08 Thread Stu Hood (JIRA)

[ 
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

2011-09-08 Thread Hudson (JIRA)

[ 
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()

2011-09-08 Thread Hudson (JIRA)

[ 
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

2011-09-08 Thread Jonathan Ellis (JIRA)

[ 
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

2011-09-08 Thread Stu Hood (JIRA)

[ 
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

2011-09-08 Thread Jonathan Ellis (JIRA)

 [ 
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

2011-09-08 Thread Stu Hood (JIRA)

[ 
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

2011-09-08 Thread Brandon Williams (JIRA)

[ 
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

2011-09-08 Thread jbellis
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

2011-09-08 Thread Jonathan Ellis (JIRA)

 [ 
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

2011-09-08 Thread Pavel Yaskevich (JIRA)

[ 
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

2011-09-08 Thread Pavel Yaskevich (JIRA)

[ 
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

2011-09-08 Thread Pavel Yaskevich (JIRA)

[ 
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

2011-09-08 Thread JIRA

 [ 
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

2011-09-08 Thread jbellis
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

2011-09-08 Thread jbellis
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

2011-09-08 Thread JIRA

[ 
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

2011-09-08 Thread Jonathan Ellis (JIRA)

 [ 
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

2011-09-08 Thread JIRA

[ 
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

2011-09-08 Thread Hudson (JIRA)

[ 
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

2011-09-08 Thread Hudson (JIRA)

[ 
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

2011-09-08 Thread JIRA

 [ 
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

2011-09-08 Thread JIRA

 [ 
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

2011-09-08 Thread Brian Lindauer (JIRA)

 [ 
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

2011-09-08 Thread Brian Lindauer (JIRA)

 [ 
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

2011-09-08 Thread Brandon Williams (JIRA)
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

2011-09-08 Thread Jonathan Ellis (JIRA)

[ 
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

2011-09-08 Thread Jonathan Ellis (JIRA)
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

2011-09-08 Thread Brandon Williams (JIRA)

 [ 
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

2011-09-08 Thread Stu Hood (JIRA)

[ 
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.

2011-09-08 Thread Mck SembWever (JIRA)

[ 
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.

2011-09-08 Thread Mck SembWever (JIRA)

[ 
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

2011-09-08 Thread paul cannon (JIRA)

 [ 
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

2011-09-08 Thread paul cannon (JIRA)

 [ 
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




  1   2   >