date:20130801

Updated Branches:
  refs/heads/cassandra-1.2 579ed75c0 - 299396537
  refs/heads/trunk 0ab0db292 - 66f0d6b73


Fix rare IOOBE in sendGossip
Patch by Chris Lohfink, reviewed by brandonwilliams for CASSANDRA-4774


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

Branch: refs/heads/cassandra-1.2
Commit: 299396537102b4ac5bf6d40952a1b6ef83ce3662
Parents: 579ed75
Author: Brandon Williams brandonwilli...@apache.org
Authored: Thu Aug 1 09:30:16 2013 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Thu Aug 1 09:30:16 2013 -0500

--
 src/java/org/apache/cassandra/gms/Gossiper.java | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/29939653/src/java/org/apache/cassandra/gms/Gossiper.java
--
diff --git a/src/java/org/apache/cassandra/gms/Gossiper.java 
b/src/java/org/apache/cassandra/gms/Gossiper.java
index b0284c1..0dcfb90 100644
--- a/src/java/org/apache/cassandra/gms/Gossiper.java
+++ b/src/java/org/apache/cassandra/gms/Gossiper.java
@@ -38,6 +38,9 @@ import org.apache.cassandra.net.MessagingService;
 import org.apache.cassandra.service.StorageService;
 import org.apache.cassandra.utils.FBUtilities;
 
+import com.google.common.collect.ImmutableList;
+import com.google.common.collect.Lists;
+
 /**
  * This module is responsible for Gossiping information for the local 
endpoint. This abstraction
  * maintains the list of live and dead endpoints. Periodically i.e. every 1 
second this module
@@ -508,11 +511,12 @@ public class Gossiper implements 
IFailureDetectionEventListener, GossiperMBean
  */
 private boolean sendGossip(MessageOutGossipDigestSyn message, 
SetInetAddress epSet)
 {
-int size = epSet.size();
+ListInetAddress liveEndpoints = ImmutableList.copyOf(epSet);
+
+int size = liveEndpoints.size();
 if (size  1)
 return false;
 /* Generate a random number from 0 - size */
-ListInetAddress liveEndpoints = new ArrayListInetAddress(epSet);
 int index = (size == 1) ? 0 : random.nextInt(size);
 InetAddress to = liveEndpoints.get(index);
 if (logger.isTraceEnabled())

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

Merge branch 'cassandra-1.2' into trunk


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

Branch: refs/heads/trunk
Commit: 66f0d6b7351bc2cc21a1df75c0a035a18c8720ab
Parents: 0ab0db2 2993965
Author: Brandon Williams brandonwilli...@apache.org
Authored: Thu Aug 1 09:35:07 2013 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Thu Aug 1 09:35:07 2013 -0500

--
 src/java/org/apache/cassandra/gms/Gossiper.java | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/66f0d6b7/src/java/org/apache/cassandra/gms/Gossiper.java
--

[2/3] git commit: Fix rare IOOBE in sendGossip Patch by Chris Lohfink, reviewed by brandonwilliams for CASSANDRA-4774

Fix rare IOOBE in sendGossip
Patch by Chris Lohfink, reviewed by brandonwilliams for CASSANDRA-4774


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

Branch: refs/heads/trunk
Commit: 299396537102b4ac5bf6d40952a1b6ef83ce3662
Parents: 579ed75
Author: Brandon Williams brandonwilli...@apache.org
Authored: Thu Aug 1 09:30:16 2013 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Thu Aug 1 09:30:16 2013 -0500

--
 src/java/org/apache/cassandra/gms/Gossiper.java | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/29939653/src/java/org/apache/cassandra/gms/Gossiper.java
--
diff --git a/src/java/org/apache/cassandra/gms/Gossiper.java 
b/src/java/org/apache/cassandra/gms/Gossiper.java
index b0284c1..0dcfb90 100644
--- a/src/java/org/apache/cassandra/gms/Gossiper.java
+++ b/src/java/org/apache/cassandra/gms/Gossiper.java
@@ -38,6 +38,9 @@ import org.apache.cassandra.net.MessagingService;
 import org.apache.cassandra.service.StorageService;
 import org.apache.cassandra.utils.FBUtilities;
 
+import com.google.common.collect.ImmutableList;
+import com.google.common.collect.Lists;
+
 /**
  * This module is responsible for Gossiping information for the local 
endpoint. This abstraction
  * maintains the list of live and dead endpoints. Periodically i.e. every 1 
second this module
@@ -508,11 +511,12 @@ public class Gossiper implements 
IFailureDetectionEventListener, GossiperMBean
  */
 private boolean sendGossip(MessageOutGossipDigestSyn message, 
SetInetAddress epSet)
 {
-int size = epSet.size();
+ListInetAddress liveEndpoints = ImmutableList.copyOf(epSet);
+
+int size = liveEndpoints.size();
 if (size  1)
 return false;
 /* Generate a random number from 0 - size */
-ListInetAddress liveEndpoints = new ArrayListInetAddress(epSet);
 int index = (size == 1) ? 0 : random.nextInt(size);
 InetAddress to = liveEndpoints.get(index);
 if (logger.isTraceEnabled())

Git Push Summary

Updated Tags:  refs/tags/cassandra-1.2.8 [created] 0291d6960

[jira] [Created] (CASSANDRA-5838) Upgrade

2013-08-01 Thread Eugen Paraschiv (JIRA)

Eugen Paraschiv created CASSANDRA-5838:
--

 Summary: Upgrade
 Key: CASSANDRA-5838
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5838
 Project: Cassandra
  Issue Type: Improvement
Reporter: Eugen Paraschiv
Priority: Minor


Cassandra is now using [metrics|https://github.com/codahale/metrics] and is 
depending on metrics-core 2.0.3. 
It would be great to make the jump to the latest version of the library which 
is 3.x - [latest is 
3.0.1|http://search.maven.org/#search|gav|1|g%3A%22com.codahale.metrics%22%20AND%20a%3A%22metrics-core%22].
 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-5837) [patch] improve performance of DecimalSerializer.serialize


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

Jonathan Ellis updated CASSANDRA-5837:
--

 Priority: Trivial  (was: Major)
Affects Version/s: (was: 2.0 beta 2)
   (was: 2.0 beta 1)
   1.0.0
Fix Version/s: 2.0 rc1

 [patch] improve performance of DecimalSerializer.serialize
 --

 Key: CASSANDRA-5837
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5837
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.0.0
Reporter: Julien Aymé
Priority: Trivial
  Labels: patch, perfomance
 Fix For: 2.0 rc1

 Attachments: cassandra-trunk-5837.diff

   Original Estimate: 1h
  Remaining Estimate: 1h

 DecimalSerializer.serialize creates a new byte array and copies byte per byte 
 instead of doing a bulk copying.
 This can lead to performance degradations when lots of calls are made.
 Patch will follow

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

git commit: improve DecimalSerializer performance

2013-08-01 Thread jbellis

Updated Branches:
  refs/heads/trunk 66f0d6b73 - dbe53c811


improve DecimalSerializer performance


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

Branch: refs/heads/trunk
Commit: dbe53c811fea105f0a98adbb21850348ce37d336
Parents: 66f0d6b
Author: Jonathan Ellis jbel...@apache.org
Authored: Thu Aug 1 12:06:18 2013 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Thu Aug 1 12:06:39 2013 -0500

--
 CHANGES.txt  |  1 +
 .../cassandra/serializers/DecimalSerializer.java | 15 ++-
 2 files changed, 7 insertions(+), 9 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/dbe53c81/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index ff3ea41..a0cd6af 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.0.0-rc1
+ * improve DecimalSerializer performance (CASSANDRA-5837)
  * fix potential spurious wakeup in AsyncOneResponse (CASSANDRA-5690)
  * fix schema-related trigger issues (CASSANDRA-5774)
  * Better validation when accessing CQL3 table from thrift (CASSANDRA-5138)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/dbe53c81/src/java/org/apache/cassandra/serializers/DecimalSerializer.java
--
diff --git a/src/java/org/apache/cassandra/serializers/DecimalSerializer.java 
b/src/java/org/apache/cassandra/serializers/DecimalSerializer.java
index 0ffea9e..819789f 100644
--- a/src/java/org/apache/cassandra/serializers/DecimalSerializer.java
+++ b/src/java/org/apache/cassandra/serializers/DecimalSerializer.java
@@ -48,17 +48,14 @@ public class DecimalSerializer implements 
TypeSerializerBigDecimal
 return ByteBufferUtil.EMPTY_BYTE_BUFFER;
 
 BigInteger bi = value.unscaledValue();
-Integer scale = value.scale();
+int scale = value.scale();
 byte[] bibytes = bi.toByteArray();
-byte[] sbytes = ByteBufferUtil.bytes(scale).array();
-byte[] bytes = new byte[bi.toByteArray().length + 4];
 
-for (int i = 0; i  4; i++)
-bytes[i] = sbytes[i];
-for (int i = 4; i  bibytes.length + 4; i++)
-bytes[i] = bibytes[i - 4];
-
-return ByteBuffer.wrap(bytes);
+ByteBuffer bytes = ByteBuffer.allocate(4 + bibytes.length);
+bytes.putInt(scale);
+bytes.put(bibytes);
+bytes.rewind();
+return bytes;
 }
 
 public void validate(ByteBuffer bytes) throws MarshalException

[jira] [Commented] (CASSANDRA-2698) Instrument repair to be able to assess it's efficiency (precision)

2013-08-01 Thread Yuki Morishita (JIRA)

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

Yuki Morishita commented on CASSANDRA-2698:
---

Benedict,

Thanks for the update.

bq. 1) I'm not sure what you mean by not serializing those

I meant you don't have to send back to the coordinator.
Changing serialized format means we have to bump up messaging version defined
in MessagingService.
2.0 got feature freeze, so I think it's better to wait until next minor version
for message change.

Also, I looked at the change made to MerkleTree#differenceHelper, and I'm still
not sure how row count helps improve logic.
What is the difference from just using hash value?

bq. 5) One thing we might want to consider changing is the format of the
EstimatedHistogram ranges in the log messages

Yeah, especially -1 in (-1, 0] feels weird. How about omitting lower bound
from the label and output like:

{code}
~0: xxx
~10: xxx
~20: xxx
{code}

nit: you should surround whole output logic in Validator#compele with
`logger.isDebugEnabled` check

Instrument repair to be able to assess it's efficiency (precision)
--

Key: CASSANDRA-2698
URL: https://issues.apache.org/jira/browse/CASSANDRA-2698
Project: Cassandra
Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Benedict
Priority: Minor
Labels: lhf
Attachments: nodetool_repair_and_cfhistogram.tar.gz,
patch_2698_v1.txt, patch.diff, patch-rebased.diff, patch.taketwo.alpha.diff,
patch.taketwo.forreview.diff

Some reports indicate that repair sometime transfer huge amounts of data. One
hypothesis is that the merkle tree precision may deteriorate too much at some
data size. To check this hypothesis, it would be reasonably to gather
statistic during the merkle tree building of how many rows each merkle tree
range account for (and the size that this represent). It is probably an
interesting statistic to have anyway.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2698) Instrument repair to be able to assess it's efficiency (precision)

2013-08-01 Thread Benedict (JIRA)


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

Benedict commented on CASSANDRA-2698:
-

Good points.

As to the changes to differenceHelper(), the row count permits not breaking up 
contiguous ranges of differences that happen to be separated by unpopulated 
leaves (using just the hash to determine if the data was populated I realised 
was dangerous, as you cannot disambiguate between no rows and a non-zero number 
of empty rows), which in my previous patch was generating a lot of ugly log 
messages. After sending my patch last night I must admit I began to doubt the 
sense of keeping the changes in, and was probably the hangover of wanting to 
retain what I could from the previous patch. I think kill your babies is the 
mantra to apply here, as it doesn't serve any purpose at the moment, and if we 
don't intend to send counts over the wire would be actively dangerous.

I'll strip out those changes, modify the messages and and fire over another 
patch.

That said, I'd prefer to emit the lower bound as well so we know the starting 
point; ~100: xxx doesn't tell you if the distribution is 0-100, or 99-100, 
which might be useful information. This is only helpful for the first item, so 
could emit only for that, but for neatness I'd probably retain it for all; 
since we're dealing with integers there's an easy fix of just bumping both 
start/end by 1 and swapping the brackets.

 Instrument repair to be able to assess it's efficiency (precision)
 --

 Key: CASSANDRA-2698
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2698
 Project: Cassandra
  Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Benedict
Priority: Minor
  Labels: lhf
 Attachments: nodetool_repair_and_cfhistogram.tar.gz, 
 patch_2698_v1.txt, patch.diff, patch-rebased.diff, patch.taketwo.alpha.diff, 
 patch.taketwo.forreview.diff


 Some reports indicate that repair sometime transfer huge amounts of data. One 
 hypothesis is that the merkle tree precision may deteriorate too much at some 
 data size. To check this hypothesis, it would be reasonably to gather 
 statistic during the merkle tree building of how many rows each merkle tree 
 range account for (and the size that this represent). It is probably an 
 interesting statistic to have anyway.   

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2698) Instrument repair to be able to assess it's efficiency (precision)

2013-08-01 Thread Benedict (JIRA)


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

Benedict commented on CASSANDRA-2698:
-

Of course the other option is to always emit the range [0..lb] even if its not 
populated to demarcate the lb - which is your preference?

 Instrument repair to be able to assess it's efficiency (precision)
 --

 Key: CASSANDRA-2698
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2698
 Project: Cassandra
  Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Benedict
Priority: Minor
  Labels: lhf
 Attachments: nodetool_repair_and_cfhistogram.tar.gz, 
 patch_2698_v1.txt, patch.diff, patch-rebased.diff, patch.taketwo.alpha.diff, 
 patch.taketwo.forreview.diff


 Some reports indicate that repair sometime transfer huge amounts of data. One 
 hypothesis is that the merkle tree precision may deteriorate too much at some 
 data size. To check this hypothesis, it would be reasonably to gather 
 statistic during the merkle tree building of how many rows each merkle tree 
 range account for (and the size that this represent). It is probably an 
 interesting statistic to have anyway.   

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-5718) Cql3 reader returns duplicate rows if the cluster column is reversed

2013-08-01 Thread Alex Liu (JIRA)


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

Alex Liu updated CASSANDRA-5718:


Attachment: 5718-2-1.2-branch.txt

Oh, I get it. 5718-2-1.2-branch.txt is attached to fix the none-composite 
reversed type of comparator

 Cql3 reader returns duplicate rows if the cluster column is reversed
 

 Key: CASSANDRA-5718
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5718
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.6
Reporter: Alex Liu
Assignee: Alex Liu
 Fix For: 1.2.9

 Attachments: 5718-1.2-branch.txt, 5718-2-1.2-branch.txt


 To reproduce it,
 cqlsh:test  select * from wordfreq;
  title   | occurances | word
 -++---
  alex123 |  4 |  liu3
alex1 |  23456 |  liu2
   alex10 | 10 | liu10
   alex12 | 34 |  liu3
 alex | 123456 |  liu1
 alex |   1000 |   liu
 CREATE TABLE wordfreq ( title text, word text, occurances int, PRIMARY KEY 
 (title,occurances)) WITH CLUSTERING ORDER by (occurances DESC);
 The hadoop job returns 7 rows instead of 6 rows. 
 I will post a patch soon.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5831) Running sstableupgrade on C* 1.0 data dir, before starting C* 1.2 for the first time breaks stuff


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

Tyler Hobbs commented on CASSANDRA-5831:


bq. I think we probably want to decouble sstableNeedsMigration from its caller 
in CassandraDaemon, it throws a bunch of exceptions that are probably not 
expected.

Are you just referring to the RuntimeExceptions around the total path length on 
Windows?  If not, can you clarify?

bq. However, I also note that StandaloneScrubber calls sNM, so maybe making 
upgradesstables able to perform the migration automagically isn't as painful as 
I thought.

Yeah, I noticed that with only a few minor changes to {{migrateSSTables()}}, 
the upgrader should be able to do this pretty easily.  Do you want me to add 
that in?

 Running sstableupgrade on C* 1.0 data dir, before starting C* 1.2 for the 
 first time breaks stuff
 -

 Key: CASSANDRA-5831
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5831
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Reporter: Jeremiah Jordan
Assignee: Tyler Hobbs
Priority: Minor
 Fix For: 1.2.9

 Attachments: 
 0001-Check-for-current-directory-layout-before-upgrading.patch


 If you try to upgrade from C* 1.0.X to 1.2.X and run offline sstableupgrade 
 to try and migrate the sstables before starting 1.2.X for the first time, it 
 messes up the system folder, because it doesn't migrate it right, and then C* 
 1.2 can't start.
 sstableupgrade should either refuse to run against a C* 1.0 data folder, or 
 migrate stuff the right way.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5831) Running sstableupgrade on C* 1.0 data dir, before starting C* 1.2 for the first time breaks stuff


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

Jonathan Ellis commented on CASSANDRA-5831:
---

bq. Are you just referring to the RuntimeExceptions

Yes. 

bq. with only a few minor changes to migrateSSTables(), the upgrader should be 
able to do this pretty easily

Let's go ahead and do that, then.

 Running sstableupgrade on C* 1.0 data dir, before starting C* 1.2 for the 
 first time breaks stuff
 -

 Key: CASSANDRA-5831
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5831
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Reporter: Jeremiah Jordan
Assignee: Tyler Hobbs
Priority: Minor
 Fix For: 1.2.9

 Attachments: 
 0001-Check-for-current-directory-layout-before-upgrading.patch


 If you try to upgrade from C* 1.0.X to 1.2.X and run offline sstableupgrade 
 to try and migrate the sstables before starting 1.2.X for the first time, it 
 messes up the system folder, because it doesn't migrate it right, and then C* 
 1.2 can't start.
 sstableupgrade should either refuse to run against a C* 1.0 data folder, or 
 migrate stuff the right way.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-5838) Upgrade metrics-core library

2013-08-01 Thread Yuki Morishita (JIRA)


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

Yuki Morishita updated CASSANDRA-5838:
--

Summary: Upgrade metrics-core library  (was: Upgrade)

 Upgrade metrics-core library
 

 Key: CASSANDRA-5838
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5838
 Project: Cassandra
  Issue Type: Improvement
Reporter: Eugen Paraschiv
Priority: Minor

 Cassandra is now using [metrics|https://github.com/codahale/metrics] and is 
 depending on metrics-core 2.0.3. 
 It would be great to make the jump to the latest version of the library which 
 is 3.x - [latest is 
 3.0.1|http://search.maven.org/#search|gav|1|g%3A%22com.codahale.metrics%22%20AND%20a%3A%22metrics-core%22].
  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5825) StatusLogger should print out the All time blocked stat like tpstats does

2013-08-01 Thread Jeremiah Jordan (JIRA)


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

Jeremiah Jordan commented on CASSANDRA-5825:


Its not trying to replace those, but when you are trying to figure out what 
happened 2 days ago, and you don't have external stat collection, having those 
numbers in there gives you a little more information.  You can see right now 
tpstats shows 1000 all time blocked XXX and 1 completeed YYY but if the 
node has been up for 4 weeks, you don't know if those 1000 blocked showed up 
all at once, and when you were in the bad things happen time, or if they 
accumulated over the full 4 weeks.

 StatusLogger should print out the All time blocked stat like tpstats does
 ---

 Key: CASSANDRA-5825
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5825
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Jeremiah Jordan
Assignee: Tyler Hobbs
Priority: Minor
  Labels: lhf
 Fix For: 1.2.9

 Attachments: 
 0001-Add-completed-total-blocked-to-TP-status-logs.patch, 
 0002-Add-dropped-message-counts-to-status-log.patch


 StatusLogger currently prints out Pool Name, Active, Pending, Blocked.
 We should change it to be Pool Name, Active, Pending, Completed, 
 Blocked, All time blocked like tpstats has.
 The DROPPED counts would be nice in there too.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5825) StatusLogger should print out the All time blocked stat like tpstats does


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

Jonathan Ellis commented on CASSANDRA-5825:
---

Hmm.

What about dropped messages?  We already log those every 5s, this is logging 
from the same source.

 StatusLogger should print out the All time blocked stat like tpstats does
 ---

 Key: CASSANDRA-5825
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5825
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Jeremiah Jordan
Assignee: Tyler Hobbs
Priority: Minor
  Labels: lhf
 Fix For: 1.2.9

 Attachments: 
 0001-Add-completed-total-blocked-to-TP-status-logs.patch, 
 0002-Add-dropped-message-counts-to-status-log.patch


 StatusLogger currently prints out Pool Name, Active, Pending, Blocked.
 We should change it to be Pool Name, Active, Pending, Completed, 
 Blocked, All time blocked like tpstats has.
 The DROPPED counts would be nice in there too.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5515) Track sstable coldness


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

Tyler Hobbs commented on CASSANDRA-5515:


bq. Maybe get fancy and do a reservoir-sampling histogram? Metrics makes that 
easy.

I could see that being useful during steady state, but there doesn't appear to 
be an easy way to serialize and rebuild those, which either means we would need 
a somewhat custom implementation, or we wouldn't have reliable information on 
startup.  (The custom implementation could support dump and restore, or perhaps 
just expose a notion of confidence.)

Perhaps we should spend some time looking at the use cases before investing too 
much effort in this?

 Track sstable coldness
 --

 Key: CASSANDRA-5515
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5515
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Jonathan Ellis
Assignee: Tyler Hobbs
 Fix For: 2.0.1

 Attachments: 0001-Track-row-read-counts-in-SSTR.patch


 Keeping a count of reads per-sstable would allow STCS to automatically ignore 
 cold data rather than recompacting it constantly with hot data, dramatically 
 reducing compaction load for typical time series applications and others with 
 time-correlated access patterns.  We would not need a separate age-tiered 
 compaction strategy.
 (This will really be useful in conjunction with CASSANDRA-5514.)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5515) Track sstable coldness


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

Jonathan Ellis commented on CASSANDRA-5515:
---

Fair enough.  Initially I only really care about supporting CASSANDRA-5519 and 
compaction making better decisions.

 Track sstable coldness
 --

 Key: CASSANDRA-5515
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5515
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Jonathan Ellis
Assignee: Tyler Hobbs
 Fix For: 2.0.1

 Attachments: 0001-Track-row-read-counts-in-SSTR.patch


 Keeping a count of reads per-sstable would allow STCS to automatically ignore 
 cold data rather than recompacting it constantly with hot data, dramatically 
 reducing compaction load for typical time series applications and others with 
 time-correlated access patterns.  We would not need a separate age-tiered 
 compaction strategy.
 (This will really be useful in conjunction with CASSANDRA-5514.)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5519) Reduce index summary memory use for cold sstables


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

Tyler Hobbs commented on CASSANDRA-5519:


An initial idea for the implementation:

Based on the recent (last 15m?) read rate (reads/sec), periodically down-sample 
the summary for SSTables which fall below the mean rate.  The down-sampling 
rate could use a sliding scale based on the ratio of the mean to that SSTable's 
rate.  As a example basic implementation, keep X% of the samples, where {{X = 
max(25, min(100, 100 * (rate / mean_rate)))}}, so the coldest SSTables keep 
only 25% of the samples in memory.

Presenting a way for the user to tune this (other than a simple on/off) is a 
little trickier.  Perhaps make the min (default 25%) adjustable?  Or start 
down-sampling at a configurable point (the default is the mean)?  Those could 
also be automatically adjusted based on memory pressure.

 Reduce index summary memory use for cold sstables
 -

 Key: CASSANDRA-5519
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5519
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Jonathan Ellis
Priority: Minor
 Fix For: 2.0.1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5515) Track sstable coldness

2013-08-01 Thread T Jake Luciani (JIRA)


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

T Jake Luciani commented on CASSANDRA-5515:
---

Before I forget, this is the logic for leveldb's hotness threshold for 
compaction

https://code.google.com/p/leveldb/source/browse/db/version_set.cc#606

 Track sstable coldness
 --

 Key: CASSANDRA-5515
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5515
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Jonathan Ellis
Assignee: Tyler Hobbs
 Fix For: 2.0.1

 Attachments: 0001-Track-row-read-counts-in-SSTR.patch


 Keeping a count of reads per-sstable would allow STCS to automatically ignore 
 cold data rather than recompacting it constantly with hot data, dramatically 
 reducing compaction load for typical time series applications and others with 
 time-correlated access patterns.  We would not need a separate age-tiered 
 compaction strategy.
 (This will really be useful in conjunction with CASSANDRA-5514.)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5515) Track sstable coldness


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

Jonathan Ellis commented on CASSANDRA-5515:
---

Interesting that Hyperdex said they do better without that: 
http://hackingdistributed.com/2013/06/17/hyperleveldb/

 Track sstable coldness
 --

 Key: CASSANDRA-5515
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5515
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Jonathan Ellis
Assignee: Tyler Hobbs
 Fix For: 2.0.1

 Attachments: 0001-Track-row-read-counts-in-SSTR.patch


 Keeping a count of reads per-sstable would allow STCS to automatically ignore 
 cold data rather than recompacting it constantly with hot data, dramatically 
 reducing compaction load for typical time series applications and others with 
 time-correlated access patterns.  We would not need a separate age-tiered 
 compaction strategy.
 (This will really be useful in conjunction with CASSANDRA-5514.)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (CASSANDRA-5654) [patch] improve performance of JdbcDecimal.decompose

2013-08-01 Thread Dave Brosius (JIRA)


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

Dave Brosius resolved CASSANDRA-5654.
-

Resolution: Duplicate

 [patch] improve performance of JdbcDecimal.decompose
 

 Key: CASSANDRA-5654
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5654
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.1.12, 1.2.5
Reporter: Julien Aymé
Assignee: Dave Brosius
Priority: Minor
 Attachments: cassandra-1.1-5654.diff


 JdbcDecimal.decompose creates a new byte array and copies byte per byte 
 instead of doing a bulk copying.
 This can lead to performance degradations when lots of calls are made.
 Patch will follow

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5515) Track sstable coldness


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

Tyler Hobbs commented on CASSANDRA-5515:


With that in mind, I'm leaning towards using Metric's 
[Meters|http://metrics.codahale.com/manual/core/#meters], which have pretty low 
overhead and would be be easy to dump and restore.  The only flaw is that they 
are hard-coded with 1m, 5m, and 15m windows; for compaction decisions, I feel 
like it would be nice to have a multi-hour window, and the 1 and 5m are 
probably too short to be useful for CASSANDRA-5519 (if we do something similar 
to my suggestion on that ticket).  We could of course subclass and hardcode 
with windows of our choosing.

 Track sstable coldness
 --

 Key: CASSANDRA-5515
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5515
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Jonathan Ellis
Assignee: Tyler Hobbs
 Fix For: 2.0.1

 Attachments: 0001-Track-row-read-counts-in-SSTR.patch


 Keeping a count of reads per-sstable would allow STCS to automatically ignore 
 cold data rather than recompacting it constantly with hot data, dramatically 
 reducing compaction load for typical time series applications and others with 
 time-correlated access patterns.  We would not need a separate age-tiered 
 compaction strategy.
 (This will really be useful in conjunction with CASSANDRA-5514.)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5515) Track sstable coldness

2013-08-01 Thread T Jake Luciani (JIRA)


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

T Jake Luciani commented on CASSANDRA-5515:
---

I'm not sure you need to track read across restarts, is there a compelling 
reason to do this?

 Track sstable coldness
 --

 Key: CASSANDRA-5515
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5515
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Jonathan Ellis
Assignee: Tyler Hobbs
 Fix For: 2.0.1

 Attachments: 0001-Track-row-read-counts-in-SSTR.patch


 Keeping a count of reads per-sstable would allow STCS to automatically ignore 
 cold data rather than recompacting it constantly with hot data, dramatically 
 reducing compaction load for typical time series applications and others with 
 time-correlated access patterns.  We would not need a separate age-tiered 
 compaction strategy.
 (This will really be useful in conjunction with CASSANDRA-5514.)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5515) Track sstable coldness


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

Tyler Hobbs commented on CASSANDRA-5515:


bq. I'm not sure you need to track read across restarts, is there a compelling 
reason to do this?

For 5519, it would be useful for determining appropriate initial sizes for the 
in-memory index summary.  For compaction strategies, it would allow us to have 
more informed compactions immediately after startup.

 Track sstable coldness
 --

 Key: CASSANDRA-5515
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5515
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Jonathan Ellis
Assignee: Tyler Hobbs
 Fix For: 2.0.1

 Attachments: 0001-Track-row-read-counts-in-SSTR.patch


 Keeping a count of reads per-sstable would allow STCS to automatically ignore 
 cold data rather than recompacting it constantly with hot data, dramatically 
 reducing compaction load for typical time series applications and others with 
 time-correlated access patterns.  We would not need a separate age-tiered 
 compaction strategy.
 (This will really be useful in conjunction with CASSANDRA-5514.)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5515) Track sstable coldness

2013-08-01 Thread T Jake Luciani (JIRA)


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

T Jake Luciani commented on CASSANDRA-5515:
---

that makes sense.

 Track sstable coldness
 --

 Key: CASSANDRA-5515
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5515
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Jonathan Ellis
Assignee: Tyler Hobbs
 Fix For: 2.0.1

 Attachments: 0001-Track-row-read-counts-in-SSTR.patch


 Keeping a count of reads per-sstable would allow STCS to automatically ignore 
 cold data rather than recompacting it constantly with hot data, dramatically 
 reducing compaction load for typical time series applications and others with 
 time-correlated access patterns.  We would not need a separate age-tiered 
 compaction strategy.
 (This will really be useful in conjunction with CASSANDRA-5514.)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5831) Running sstableupgrade on C* 1.0 data dir, before starting C* 1.2 for the first time breaks stuff


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

Tyler Hobbs commented on CASSANDRA-5831:


Hmm, there's one complication: {{sstableupgrade}} requires a keyspace and table 
to be specified, whereas the data directory migration is normally done all at 
once.  Changing the directory layout for only a single CF feels strange, but 
changing the layout for other keyspaces and CFs that you didn't specify also 
feels wrong.

 Running sstableupgrade on C* 1.0 data dir, before starting C* 1.2 for the 
 first time breaks stuff
 -

 Key: CASSANDRA-5831
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5831
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Reporter: Jeremiah Jordan
Assignee: Tyler Hobbs
Priority: Minor
 Fix For: 1.2.9

 Attachments: 
 0001-Check-for-current-directory-layout-before-upgrading.patch


 If you try to upgrade from C* 1.0.X to 1.2.X and run offline sstableupgrade 
 to try and migrate the sstables before starting 1.2.X for the first time, it 
 messes up the system folder, because it doesn't migrate it right, and then C* 
 1.2 can't start.
 sstableupgrade should either refuse to run against a C* 1.0 data folder, or 
 migrate stuff the right way.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4573) HSHA doesn't handle large messages gracefully


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

Tyler Hobbs commented on CASSANDRA-4573:


After a quick check, it looks like the CASSANDRA-5582 implementation also 
doesn't enforce the max frame size.

 HSHA doesn't handle large messages gracefully
 -

 Key: CASSANDRA-4573
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4573
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Tyler Hobbs
Assignee: Tyler Hobbs
 Attachments: repro.py


 HSHA doesn't seem to enforce any kind of max message length, and when 
 messages are too large, it doesn't fail gracefully.
 With debug logs enabled, you'll see this:
 {{DEBUG 13:13:31,805 Unexpected state 16}}
 Which seems to mean that there's a SelectionKey that's valid, but isn't ready 
 for reading, writing, or accepting.
 Client-side, you'll get this thrift error (while trying to read a frame as 
 part of {{recv_batch_mutate}}):
 {{TTransportException: TSocket read 0 bytes}}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5836) Seed nodes should be able to bootstrap without manual intervention

2013-08-01 Thread Robert Coli (JIRA)

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

Robert Coli commented on CASSANDRA-5836:

Replacing a seed node is a very common operation, and this best practice is
confusing/poorly documented. There are regular contacts to
#cassandra/cassandra-user@ where people ask how to replace a seed node, and are
confused by the answer. The workaround also means that, if you do not restart
your node after bootstrapping it (and changing the conf file back to indicate
to itself that it is a seed) the node runs until next restart without any
understanding that it is a seed node.

Being a seed node appears to mean two things :

1) I have myself as an entry in my own seed list, so I know that I am a seed.
2) Other nodes have me in their seed list, so they consider me a seed.

The current code checks for 1) and refuses to bootstrap. The workaround is to
remove the 1) state temporarily. But if it is unsafe to bootstrap a seed node
because of *either* 1) or 2), the workaround is unsafe.

Can you explicate the special cases here? I sincerely would like to understand
why the code tries to prevent a seed from bootstrapping when one can clearly,
and apparently safely, bootstrap a seed. :)

Seed nodes should be able to bootstrap without manual intervention
--

Key: CASSANDRA-5836
URL: https://issues.apache.org/jira/browse/CASSANDRA-5836
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Bill Hathaway
Priority: Minor

The current logic doesn't allow a seed node to be bootstrapped. If a user
wants to bootstrap a node configured as a seed (for example to replace a seed
node via replace_token), they first need to remove the node's own IP from the
seed list, and then start the bootstrap process. This seems like an
unnecessary step since a node never uses itself as a seed.
I think it would be a better experience if the logic was changed to allow a
seed node to bootstrap without manual intervention when there are other seed
nodes up in a ring.

[jira] [Commented] (CASSANDRA-5831) Running sstableupgrade on C* 1.0 data dir, before starting C* 1.2 for the first time breaks stuff


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

Jonathan Ellis commented on CASSANDRA-5831:
---

How does scrub deal with this?

 Running sstableupgrade on C* 1.0 data dir, before starting C* 1.2 for the 
 first time breaks stuff
 -

 Key: CASSANDRA-5831
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5831
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Reporter: Jeremiah Jordan
Assignee: Tyler Hobbs
Priority: Minor
 Fix For: 1.2.9

 Attachments: 
 0001-Check-for-current-directory-layout-before-upgrading.patch


 If you try to upgrade from C* 1.0.X to 1.2.X and run offline sstableupgrade 
 to try and migrate the sstables before starting 1.2.X for the first time, it 
 messes up the system folder, because it doesn't migrate it right, and then C* 
 1.2 can't start.
 sstableupgrade should either refuse to run against a C* 1.0 data folder, or 
 migrate stuff the right way.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (CASSANDRA-4573) HSHA doesn't handle large messages gracefully


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

Jonathan Ellis reassigned CASSANDRA-4573:
-

Assignee: Pavel Yaskevich  (was: Tyler Hobbs)

[~xedin], can you have a look?

 HSHA doesn't handle large messages gracefully
 -

 Key: CASSANDRA-4573
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4573
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Tyler Hobbs
Assignee: Pavel Yaskevich
 Attachments: repro.py


 HSHA doesn't seem to enforce any kind of max message length, and when 
 messages are too large, it doesn't fail gracefully.
 With debug logs enabled, you'll see this:
 {{DEBUG 13:13:31,805 Unexpected state 16}}
 Which seems to mean that there's a SelectionKey that's valid, but isn't ready 
 for reading, writing, or accepting.
 Client-side, you'll get this thrift error (while trying to read a frame as 
 part of {{recv_batch_mutate}}):
 {{TTransportException: TSocket read 0 bytes}}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5831) Running sstableupgrade on C* 1.0 data dir, before starting C* 1.2 for the first time breaks stuff


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

Tyler Hobbs commented on CASSANDRA-5831:


bq. How does scrub deal with this?

Good point. It just runs the full migration.  That still seems 
less-than-perfect, but at least the behavior would be consistent.

 Running sstableupgrade on C* 1.0 data dir, before starting C* 1.2 for the 
 first time breaks stuff
 -

 Key: CASSANDRA-5831
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5831
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Reporter: Jeremiah Jordan
Assignee: Tyler Hobbs
Priority: Minor
 Fix For: 1.2.9

 Attachments: 
 0001-Check-for-current-directory-layout-before-upgrading.patch


 If you try to upgrade from C* 1.0.X to 1.2.X and run offline sstableupgrade 
 to try and migrate the sstables before starting 1.2.X for the first time, it 
 messes up the system folder, because it doesn't migrate it right, and then C* 
 1.2 can't start.
 sstableupgrade should either refuse to run against a C* 1.0 data folder, or 
 migrate stuff the right way.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5831) Running sstableupgrade on C* 1.0 data dir, before starting C* 1.2 for the first time breaks stuff


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

Jonathan Ellis commented on CASSANDRA-5831:
---

Seems like if they're running upgrade then they've signaled their intent to be 
on the new version, so maybe just add a notice that we're moving *everything* 
to the new directory structure and call it good.

 Running sstableupgrade on C* 1.0 data dir, before starting C* 1.2 for the 
 first time breaks stuff
 -

 Key: CASSANDRA-5831
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5831
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Reporter: Jeremiah Jordan
Assignee: Tyler Hobbs
Priority: Minor
 Fix For: 1.2.9

 Attachments: 
 0001-Check-for-current-directory-layout-before-upgrading.patch


 If you try to upgrade from C* 1.0.X to 1.2.X and run offline sstableupgrade 
 to try and migrate the sstables before starting 1.2.X for the first time, it 
 messes up the system folder, because it doesn't migrate it right, and then C* 
 1.2 can't start.
 sstableupgrade should either refuse to run against a C* 1.0 data folder, or 
 migrate stuff the right way.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5831) Running sstableupgrade on C* 1.0 data dir, before starting C* 1.2 for the first time breaks stuff

2013-08-01 Thread Jeremiah Jordan (JIRA)


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

Jeremiah Jordan commented on CASSANDRA-5831:


Agreed.  Also, if you want to add a migrate all keyspaces option, I don't 
think anyone would complain.

 Running sstableupgrade on C* 1.0 data dir, before starting C* 1.2 for the 
 first time breaks stuff
 -

 Key: CASSANDRA-5831
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5831
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Reporter: Jeremiah Jordan
Assignee: Tyler Hobbs
Priority: Minor
 Fix For: 1.2.9

 Attachments: 
 0001-Check-for-current-directory-layout-before-upgrading.patch


 If you try to upgrade from C* 1.0.X to 1.2.X and run offline sstableupgrade 
 to try and migrate the sstables before starting 1.2.X for the first time, it 
 messes up the system folder, because it doesn't migrate it right, and then C* 
 1.2 can't start.
 sstableupgrade should either refuse to run against a C* 1.0 data folder, or 
 migrate stuff the right way.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-5831) Running sstableupgrade on C* 1.0 data dir, before starting C* 1.2 for the first time breaks stuff


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

Tyler Hobbs updated CASSANDRA-5831:
---

Attachment: (was: 
0001-Check-for-current-directory-layout-before-upgrading.patch)

 Running sstableupgrade on C* 1.0 data dir, before starting C* 1.2 for the 
 first time breaks stuff
 -

 Key: CASSANDRA-5831
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5831
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Reporter: Jeremiah Jordan
Assignee: Tyler Hobbs
Priority: Minor
 Fix For: 1.2.9


 If you try to upgrade from C* 1.0.X to 1.2.X and run offline sstableupgrade 
 to try and migrate the sstables before starting 1.2.X for the first time, it 
 messes up the system folder, because it doesn't migrate it right, and then C* 
 1.2 can't start.
 sstableupgrade should either refuse to run against a C* 1.0 data folder, or 
 migrate stuff the right way.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-5831) Running sstableupgrade on C* 1.0 data dir, before starting C* 1.2 for the first time breaks stuff


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

Tyler Hobbs updated CASSANDRA-5831:
---

Attachment: 0001-Handle-pre-1.1-data-directory-layout.patch

The new 0001 patch adds a {{\-\-migrate}} option to {{sstableupgrade}} and 
{{sstablescrub}}.  If that option is not used and a pre-1.1 layout is detected, 
both tools will error out and mention the {{\-\-migrate}} option.  If the 
option is used, all keyspaces and column families will be migrated.

 Running sstableupgrade on C* 1.0 data dir, before starting C* 1.2 for the 
 first time breaks stuff
 -

 Key: CASSANDRA-5831
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5831
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Reporter: Jeremiah Jordan
Assignee: Tyler Hobbs
Priority: Minor
 Fix For: 1.2.9

 Attachments: 0001-Handle-pre-1.1-data-directory-layout.patch


 If you try to upgrade from C* 1.0.X to 1.2.X and run offline sstableupgrade 
 to try and migrate the sstables before starting 1.2.X for the first time, it 
 messes up the system folder, because it doesn't migrate it right, and then C* 
 1.2 can't start.
 sstableupgrade should either refuse to run against a C* 1.0 data folder, or 
 migrate stuff the right way.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4573) HSHA doesn't handle large messages gracefully

2013-08-01 Thread Pavel Yaskevich (JIRA)


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

Pavel Yaskevich commented on CASSANDRA-4573:


It looks like strict read option was removed from TBinaryProtocol which has 
actually responsible for graceful failure, I also notice that 
Config.thrift_max_message_length_in_mb is marked as Deprecated, starting from 
1.1 I can bring that back but curious is there any good reason behind that? 

 HSHA doesn't handle large messages gracefully
 -

 Key: CASSANDRA-4573
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4573
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Tyler Hobbs
Assignee: Pavel Yaskevich
 Attachments: repro.py


 HSHA doesn't seem to enforce any kind of max message length, and when 
 messages are too large, it doesn't fail gracefully.
 With debug logs enabled, you'll see this:
 {{DEBUG 13:13:31,805 Unexpected state 16}}
 Which seems to mean that there's a SelectionKey that's valid, but isn't ready 
 for reading, writing, or accepting.
 Client-side, you'll get this thrift error (while trying to read a frame as 
 part of {{recv_batch_mutate}}):
 {{TTransportException: TSocket read 0 bytes}}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-5831) Running sstableupgrade on C* 1.0 data dir, before starting C* 1.2 for the first time breaks stuff


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

Jonathan Ellis updated CASSANDRA-5831:
--

Reviewer: jjordan

 Running sstableupgrade on C* 1.0 data dir, before starting C* 1.2 for the 
 first time breaks stuff
 -

 Key: CASSANDRA-5831
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5831
 Project: Cassandra
  Issue Type: Bug
  Components: Tools
Reporter: Jeremiah Jordan
Assignee: Tyler Hobbs
Priority: Minor
 Fix For: 1.2.9

 Attachments: 0001-Handle-pre-1.1-data-directory-layout.patch


 If you try to upgrade from C* 1.0.X to 1.2.X and run offline sstableupgrade 
 to try and migrate the sstables before starting 1.2.X for the first time, it 
 messes up the system folder, because it doesn't migrate it right, and then C* 
 1.2 can't start.
 sstableupgrade should either refuse to run against a C* 1.0 data folder, or 
 migrate stuff the right way.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4573) HSHA doesn't handle large messages gracefully


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

Jonathan Ellis commented on CASSANDRA-4573:
---

Those are not the same thing as frame length, see THRIFT-820 and CASSANDRA-5529.

 HSHA doesn't handle large messages gracefully
 -

 Key: CASSANDRA-4573
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4573
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Tyler Hobbs
Assignee: Pavel Yaskevich
 Attachments: repro.py


 HSHA doesn't seem to enforce any kind of max message length, and when 
 messages are too large, it doesn't fail gracefully.
 With debug logs enabled, you'll see this:
 {{DEBUG 13:13:31,805 Unexpected state 16}}
 Which seems to mean that there's a SelectionKey that's valid, but isn't ready 
 for reading, writing, or accepting.
 Client-side, you'll get this thrift error (while trying to read a frame as 
 part of {{recv_batch_mutate}}):
 {{TTransportException: TSocket read 0 bytes}}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-4573) HSHA doesn't handle large messages gracefully

2013-08-01 Thread Pavel Yaskevich (JIRA)


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

Pavel Yaskevich commented on CASSANDRA-4573:


I actually this I know what is the problem, I will work on solution for 
distruptor server asap.

 HSHA doesn't handle large messages gracefully
 -

 Key: CASSANDRA-4573
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4573
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Tyler Hobbs
Assignee: Pavel Yaskevich
 Attachments: repro.py


 HSHA doesn't seem to enforce any kind of max message length, and when 
 messages are too large, it doesn't fail gracefully.
 With debug logs enabled, you'll see this:
 {{DEBUG 13:13:31,805 Unexpected state 16}}
 Which seems to mean that there's a SelectionKey that's valid, but isn't ready 
 for reading, writing, or accepting.
 Client-side, you'll get this thrift error (while trying to read a frame as 
 part of {{recv_batch_mutate}}):
 {{TTransportException: TSocket read 0 bytes}}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (CASSANDRA-5561) Compaction strategy that minimizes re-compaction of old/frozen data

2013-08-01 Thread Aleksey Yeschenko (JIRA)

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

Aleksey Yeschenko reassigned CASSANDRA-5561:

Assignee: Aleksey Yeschenko

Compaction strategy that minimizes re-compaction of old/frozen data
---

Key: CASSANDRA-5561
URL: https://issues.apache.org/jira/browse/CASSANDRA-5561
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.2.3
Reporter: Tupshin Harper
Assignee: Aleksey Yeschenko
Fix For: 2.0.1

Neither LCS nor STCS are good for data that becomes immutable over time. The
most obvious case is for time-series data where the application can guarantee
that out-of-order delivery (to Cassandra) of events can't take place more
than N minutes/seconds/hours/days have elapsed after the real (wall time).
There are various approaches that could involve paying attention to the row
keys (if they include a time component) and/or the column name (if they are
TimeUUID or Integer based and are inherently time-ordered), but it might be
sufficient to just look at the timestamp of the columns themselves.
A possible approach:
1) Define an optional max-out-of-order window on a per-CF basis.
2) Use normal (LCS or STCS) compaction strategy for any SSTables that include
any columns younger than max-out-of-order-delivery).
3) Use alternate compaction strategy (will call it TWCS time window
compaction strategy for now) for any SSTables that only contain columns older
than max-out-of-order-delivery.
4) TWCS will only compact sstables containing data older than
max-out-of-order-delivery.
5) TWCS will only perform compaction to reduce row fragmentation (if there is
any by the time it gets to TWCS or to reduce the number of small sstables.
6) To minimize re-compaction in TWCS, it should aggresively try to compact as
many small sstables as possible into one large sstable that would never have
to get recompacted.
In the case of large datasets (e.g. 5TB per node) with LCS, there would be on
the order of seven levels, and hence seven separate writes of the same data
over time. With this approach, it should be possible to get about 3
compactions per column (2 in original compaction and one more once hitting
TWCS) in most cases, cutting the write workload by a factor of two or more
for high volume time-series applications.
Note that the only workaround I can currently suggest to minimize compaction
for these workloads is to programatically shard your data across time-window
ranges (e.g. new CF per week), but that pushes unnecessary writing and
querying logic out to the user and is not as convenient nor flexible.
Also note that I am not convinced that the approach I've suggested above is
the best/most general way to solve the problem, but it does appear to be a
relatively easy one to implement.

[jira] [Updated] (CASSANDRA-5818) Duplicated error messages on directory creation error at startup

2013-08-01 Thread Aleksey Yeschenko (JIRA)


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

Aleksey Yeschenko updated CASSANDRA-5818:
-

Fix Version/s: (was: 2.0 beta 2)
   2.0.1

 Duplicated error messages on directory creation error at startup
 

 Key: CASSANDRA-5818
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5818
 Project: Cassandra
  Issue Type: Bug
Reporter: Michaël Figuière
Priority: Trivial
 Fix For: 2.0.1


 When I start Cassandra without the appropriate OS access rights to the 
 default Cassandra directories, I get a flood of {{ERROR}} messages at 
 startup, whereas one per directory would be more appropriate. See bellow:
 {code}
 ERROR 13:37:39,792 Failed to create 
 /var/lib/cassandra/data/system/schema_triggers directory
 ERROR 13:37:39,797 Failed to create 
 /var/lib/cassandra/data/system/schema_triggers directory
 ERROR 13:37:39,798 Failed to create 
 /var/lib/cassandra/data/system/schema_triggers directory
 ERROR 13:37:39,798 Failed to create 
 /var/lib/cassandra/data/system/schema_triggers directory
 ERROR 13:37:39,799 Failed to create 
 /var/lib/cassandra/data/system/schema_triggers directory
 ERROR 13:37:39,800 Failed to create /var/lib/cassandra/data/system/batchlog 
 directory
 ERROR 13:37:39,801 Failed to create /var/lib/cassandra/data/system/batchlog 
 directory
 ERROR 13:37:39,801 Failed to create /var/lib/cassandra/data/system/batchlog 
 directory
 ERROR 13:37:39,802 Failed to create /var/lib/cassandra/data/system/batchlog 
 directory
 ERROR 13:37:39,802 Failed to create 
 /var/lib/cassandra/data/system/peer_events directory
 ERROR 13:37:39,803 Failed to create 
 /var/lib/cassandra/data/system/peer_events directory
 ERROR 13:37:39,803 Failed to create 
 /var/lib/cassandra/data/system/peer_events directory
 ERROR 13:37:39,804 Failed to create 
 /var/lib/cassandra/data/system/compactions_in_progress directory
 ERROR 13:37:39,805 Failed to create 
 /var/lib/cassandra/data/system/compactions_in_progress directory
 ERROR 13:37:39,805 Failed to create 
 /var/lib/cassandra/data/system/compactions_in_progress directory
 ERROR 13:37:39,806 Failed to create 
 /var/lib/cassandra/data/system/compactions_in_progress directory
 ERROR 13:37:39,807 Failed to create 
 /var/lib/cassandra/data/system/compactions_in_progress directory
 ERROR 13:37:39,808 Failed to create /var/lib/cassandra/data/system/hints 
 directory
 ERROR 13:37:39,809 Failed to create /var/lib/cassandra/data/system/hints 
 directory
 ERROR 13:37:39,809 Failed to create /var/lib/cassandra/data/system/hints 
 directory
 ERROR 13:37:39,811 Failed to create /var/lib/cassandra/data/system/hints 
 directory
 ERROR 13:37:39,811 Failed to create /var/lib/cassandra/data/system/hints 
 directory
 ERROR 13:37:39,812 Failed to create 
 /var/lib/cassandra/data/system/schema_keyspaces directory
 ERROR 13:37:39,812 Failed to create 
 /var/lib/cassandra/data/system/schema_keyspaces directory
 ERROR 13:37:39,813 Failed to create 
 /var/lib/cassandra/data/system/schema_keyspaces directory
 ERROR 13:37:39,814 Failed to create 
 /var/lib/cassandra/data/system/schema_keyspaces directory
 ERROR 13:37:39,814 Failed to create 
 /var/lib/cassandra/data/system/schema_keyspaces directory
 ERROR 13:37:39,815 Failed to create 
 /var/lib/cassandra/data/system/range_xfers directory
 ERROR 13:37:39,816 Failed to create 
 /var/lib/cassandra/data/system/range_xfers directory
 ERROR 13:37:39,817 Failed to create 
 /var/lib/cassandra/data/system/range_xfers directory
 ERROR 13:37:39,817 Failed to create 
 /var/lib/cassandra/data/system/schema_columnfamilies directory
 ERROR 13:37:39,818 Failed to create 
 /var/lib/cassandra/data/system/schema_columnfamilies directory
 ERROR 13:37:39,818 Failed to create 
 /var/lib/cassandra/data/system/schema_columnfamilies directory
 ERROR 13:37:39,820 Failed to create 
 /var/lib/cassandra/data/system/schema_columnfamilies directory
 ERROR 13:37:39,821 Failed to create 
 /var/lib/cassandra/data/system/schema_columnfamilies directory
 ERROR 13:37:39,821 Failed to create 
 /var/lib/cassandra/data/system/schema_columnfamilies directory
 ERROR 13:37:39,822 Failed to create 
 /var/lib/cassandra/data/system/schema_columnfamilies directory
 ERROR 13:37:39,822 Failed to create 
 /var/lib/cassandra/data/system/schema_columnfamilies directory
 ERROR 13:37:39,823 Failed to create 
 /var/lib/cassandra/data/system/schema_columnfamilies directory
 ERROR 13:37:39,824 Failed to create 
 /var/lib/cassandra/data/system/schema_columnfamilies directory
 ERROR 13:37:39,824 Failed to create 
 /var/lib/cassandra/data/system/schema_columnfamilies directory
 ERROR 13:37:39,825 Failed to create 
 /var/lib/cassandra/data/system/schema_columnfamilies directory
 ERROR 13:37:39,825 Failed to

git commit: fix logging format string

2013-08-01 Thread dbrosius

Updated Branches:
  refs/heads/cassandra-1.2 299396537 - 9ff7d6f02


fix logging format string


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

Branch: refs/heads/cassandra-1.2
Commit: 9ff7d6f0296c3f304cb9ab18966686daf72dffb7
Parents: 2993965
Author: Dave Brosius dbros...@apache.org
Authored: Thu Aug 1 22:07:09 2013 -0400
Committer: Dave Brosius dbros...@apache.org
Committed: Thu Aug 1 22:07:09 2013 -0400

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


http://git-wip-us.apache.org/repos/asf/cassandra/blob/9ff7d6f0/src/java/org/apache/cassandra/service/StorageProxy.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageProxy.java 
b/src/java/org/apache/cassandra/service/StorageProxy.java
index 28e2af5..126bb38 100644
--- a/src/java/org/apache/cassandra/service/StorageProxy.java
+++ b/src/java/org/apache/cassandra/service/StorageProxy.java
@@ -1519,7 +1519,7 @@ public class StorageProxy implements StorageProxyMBean
  */
 public static void truncateBlocking(String keyspace, String cfname) throws 
UnavailableException, TimeoutException, IOException
 {
-logger.debug(Starting a blocking truncate operation on keyspace {}, 
CF , keyspace, cfname);
+logger.debug(Starting a blocking truncate operation on keyspace {}, 
CF {}, keyspace, cfname);
 if (isAnyHostDown())
 {
 logger.info(Cannot perform truncate, some hosts are down);

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

2013-08-01 Thread dbrosius

Merge branch 'cassandra-1.2' into trunk


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

Branch: refs/heads/trunk
Commit: be8c9abf96662541b7265912e5e1576d32c587ff
Parents: dbe53c8 9ff7d6f
Author: Dave Brosius dbros...@apache.org
Authored: Thu Aug 1 22:08:24 2013 -0400
Committer: Dave Brosius dbros...@apache.org
Committed: Thu Aug 1 22:08:24 2013 -0400

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


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

[1/2] git commit: fix logging format string

2013-08-01 Thread dbrosius

Updated Branches:
  refs/heads/trunk dbe53c811 - be8c9abf9


fix logging format string


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

Branch: refs/heads/trunk
Commit: 9ff7d6f0296c3f304cb9ab18966686daf72dffb7
Parents: 2993965
Author: Dave Brosius dbros...@apache.org
Authored: Thu Aug 1 22:07:09 2013 -0400
Committer: Dave Brosius dbros...@apache.org
Committed: Thu Aug 1 22:07:09 2013 -0400

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


http://git-wip-us.apache.org/repos/asf/cassandra/blob/9ff7d6f0/src/java/org/apache/cassandra/service/StorageProxy.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageProxy.java 
b/src/java/org/apache/cassandra/service/StorageProxy.java
index 28e2af5..126bb38 100644
--- a/src/java/org/apache/cassandra/service/StorageProxy.java
+++ b/src/java/org/apache/cassandra/service/StorageProxy.java
@@ -1519,7 +1519,7 @@ public class StorageProxy implements StorageProxyMBean
  */
 public static void truncateBlocking(String keyspace, String cfname) throws 
UnavailableException, TimeoutException, IOException
 {
-logger.debug(Starting a blocking truncate operation on keyspace {}, 
CF , keyspace, cfname);
+logger.debug(Starting a blocking truncate operation on keyspace {}, 
CF {}, keyspace, cfname);
 if (isAnyHostDown())
 {
 logger.info(Cannot perform truncate, some hosts are down);

[jira] [Commented] (CASSANDRA-5701) Apache.Cassandra.Cassandra.get_count will disconnect but not throw InvalidRequestException when column family is not exist.

2013-08-01 Thread yuemaoxing (JIRA)


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

yuemaoxing commented on CASSANDRA-5701:
---

Uh...

 Apache.Cassandra.Cassandra.get_count will disconnect but not throw 
 InvalidRequestException when column family is not exist.
 ---

 Key: CASSANDRA-5701
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5701
 Project: Cassandra
  Issue Type: Bug
  Components: API
Affects Versions: 1.2.4
 Environment: cassandra server : 1.2.4
 and cassandra1.2.5 has same bug.
 client : C# client
Reporter: yuemaoxing
   Original Estimate: 24h
  Remaining Estimate: 24h

 When I use get_count interface which is defined in Cassandra.thrift, the 
 Cassandra Server(1.2.4) close the connection from Client when column family 
 is not exist in that keyspace but not throw InvalidRequestException. 
 It seemed the get_count method in cassandra.thrift.CassandraServer.java did 
 not validate parameters(ThriftValidation.validateColumnFamily) in this method.
 system.log:
 ERROR [RPC-Thread:3373] 2013-06-26 14:23:09,264 TNonblockingServer.java (line 
 638) Unexpected exception while invoking!
 java.lang.IllegalArgumentException: Unknown table/cf pair (Keyspace1.Standard)
   at org.apache.cassandra.db.Table.getColumnFamilyStore(Table.java:165)
   at 
 org.apache.cassandra.thrift.CassandraServer.get_count(CassandraServer.java:471)
   at 
 org.apache.cassandra.thrift.Cassandra$Processor$get_count.getResult(Cassandra.java:3381)
   at 
 org.apache.cassandra.thrift.Cassandra$Processor$get_count.getResult(Cassandra.java:3369)
   at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
   at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
   at 
 org.apache.thrift.server.TNonblockingServer$FrameBuffer.invoke(TNonblockingServer.java:632)
   at 
 org.apache.cassandra.thrift.CustomTHsHaServer$Invocation.run(CustomTHsHaServer.java:109)
   at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown 
 Source)
   at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
   at java.lang.Thread.run(Unknown Source)
 Please check this bug, thanks!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4445) balance utility for vnodes


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

Jonathan Ellis updated CASSANDRA-4445:
--

Fix Version/s: (was: 1.2.9)
   2.0.1

 balance utility for vnodes
 --

 Key: CASSANDRA-4445
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4445
 Project: Cassandra
  Issue Type: Sub-task
  Components: Core
Affects Versions: 1.2.0 beta 1
Reporter: Brandon Williams
Priority: Minor
 Fix For: 2.0.1


 We need a 'balance' utility similar to move without a token, in the cases 
 where entropy is not your friend and gives you an unbalanced cluster (I've 
 seen up to a 7% discrepancy myself)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (CASSANDRA-5811) NPE during upgrade


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

Jonathan Ellis reassigned CASSANDRA-5811:
-

Assignee: Aleksey Yeschenko

 NPE during upgrade
 --

 Key: CASSANDRA-5811
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5811
 Project: Cassandra
  Issue Type: Bug
Reporter: Brandon Williams
Assignee: Aleksey Yeschenko
 Fix For: 1.2.9


 The upgrade_through_versions dtest occasionally fails with the following 
 error (on the 1.1 side):
 {noformat}
 ERROR [InternalResponseStage:2] 2013-07-26 12:51:10,145 
 AbstractCassandraDaemon.java (line 135) Exception in thread 
 Thread[InternalResponseStage:2,5,main]
 java.lang.NullPointerException
 at 
 org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
 at 
 org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:124)
 at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(JdbcUTF8.java:77)
 at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(JdbcUTF8.java:97)
 at org.apache.cassandra.db.marshal.UTF8Type.compose(UTF8Type.java:35)
 at 
 org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:87)
 at org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:256)
 at org.apache.cassandra.db.DefsTable.mergeKeyspaces(DefsTable.java:397)
 at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:373)
 at org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:352)
 at 
 org.apache.cassandra.service.MigrationManager$MigrationTask$1.response(MigrationManager.java:453)
 at 
 org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:45)
 at 
 org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:722)
 {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4445) balance utility for vnodes


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

Jonathan Ellis updated CASSANDRA-4445:
--

Issue Type: New Feature  (was: Sub-task)
Parent: (was: CASSANDRA-4119)

 balance utility for vnodes
 --

 Key: CASSANDRA-4445
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4445
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Affects Versions: 1.2.0 beta 1
Reporter: Brandon Williams
Priority: Minor
 Fix For: 2.0.1


 We need a 'balance' utility similar to move without a token, in the cases 
 where entropy is not your friend and gives you an unbalanced cluster (I've 
 seen up to a 7% discrepancy myself)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-5725) Silently failing messages in case of schema not fully propagated


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

Jonathan Ellis updated CASSANDRA-5725:
--


Still working on this, [~sbtourist]?

 Silently failing messages in case of schema not fully propagated
 

 Key: CASSANDRA-5725
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5725
 Project: Cassandra
  Issue Type: Bug
Reporter: Sergio Bossa
 Fix For: 1.2.9

 Attachments: 5725-0001.patch


 When a new keyspace and/or column family is created on a multi nodes cluster 
 (at least three), and then a mutation is executed on such new column family, 
 the operations sometimes silently fails by timing out.
 I tracked this down to the schema not being fully propagated to all nodes. 
 Here's what happens:
 1) Node 1 receives the create keyspace/column family request.
 2) The same node receives a mutation request at CL.QUORUM and sends to other 
 nodes too.
 3) Upon receiving the mutation request, other nodes try to deserialize it and 
 fail in doing so if the schema is not fully propagated, i.e. because they 
 don't find the mutated column family.
 4) The connection between node 1 and the failed node is dropped, and the 
 request on the former hangs until timing out.
 Here is the underlying exception, I had to tweak several log levels to get 
 it: 
 {noformat}
 INFO 13:11:39,441 IOException reading from socket; closing
 org.apache.cassandra.db.UnknownColumnFamilyException: Couldn't find 
 cfId=a31c7604-0e40-393b-82d7-ba3d910ad50a
   at 
 org.apache.cassandra.db.ColumnFamilySerializer.deserializeCfId(ColumnFamilySerializer.java:184)
   at 
 org.apache.cassandra.db.ColumnFamilySerializer.deserialize(ColumnFamilySerializer.java:94)
   at 
 org.apache.cassandra.db.RowMutation$RowMutationSerializer.deserialize(RowMutation.java:397)
   at 
 org.apache.cassandra.db.RowMutation$RowMutationSerializer.deserialize(RowMutation.java:407)
   at 
 org.apache.cassandra.db.RowMutation$RowMutationSerializer.deserialize(RowMutation.java:367)
   at org.apache.cassandra.net.MessageIn.read(MessageIn.java:94)
   at 
 org.apache.cassandra.net.IncomingTcpConnection.receiveMessage(IncomingTcpConnection.java:207)
   at 
 org.apache.cassandra.net.IncomingTcpConnection.handleModernVersion(IncomingTcpConnection.java:139)
   at 
 org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:82)
 {noformat}
 Finally, there's probably a correlated failure happening during repairs of 
 newly created/mutated column family, causing the repair process to hang 
 forever as follows:
 {noformat}
 AntiEntropySessions:1 daemon prio=5 tid=7fe981148000 nid=0x11abea000 in 
 Object.wait() [11abe9000]
java.lang.Thread.State: WAITING (on object monitor)
   at java.lang.Object.wait(Native Method)
   - waiting on 7c6200840 (a org.apache.cassandra.utils.SimpleCondition)
   at java.lang.Object.wait(Object.java:485)
   at 
 org.apache.cassandra.utils.SimpleCondition.await(SimpleCondition.java:34)
   - locked 7c6200840 (a org.apache.cassandra.utils.SimpleCondition)
   at 
 org.apache.cassandra.service.AntiEntropyService$RepairSession.runMayThrow(AntiEntropyService.java:695)
   at 
 org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
   at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
   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:895)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
   at java.lang.Thread.run(Thread.java:680)
 http-8983-1 daemon prio=5 tid=7fe97d24d000 nid=0x11a5c8000 in Object.wait() 
 [11a5c6000]
java.lang.Thread.State: WAITING (on object monitor)
   at java.lang.Object.wait(Native Method)
   - waiting on 7c620db58 (a org.apache.cassandra.utils.SimpleCondition)
   at java.lang.Object.wait(Object.java:485)
   at 
 org.apache.cassandra.utils.SimpleCondition.await(SimpleCondition.java:34)
   - locked 7c620db58 (a org.apache.cassandra.utils.SimpleCondition)
   at 
 org.apache.cassandra.service.StorageService$4.runMayThrow(StorageService.java:2442)
   at 
 org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
   at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
   at java.util.concurrent.FutureTask.run(FutureTask.java:138)
   at 
 org.apache.cassandra.service.StorageService.forceTableRepairRange(StorageService.java:2409)
   at

[jira] [Resolved] (CASSANDRA-5523) Prevent repair among the nodes of different version


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

Jonathan Ellis resolved CASSANDRA-5523.
---

   Resolution: Fixed
Fix Version/s: (was: 1.2.9)

Wontfixing since we should be able to do cross-version repair in 2.0.  Please 
reopen if I've misunderstood.

 Prevent repair among the nodes of different version
 ---

 Key: CASSANDRA-5523
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5523
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 1.2.4
Reporter: Yuki Morishita
Assignee: Yuki Morishita
Priority: Minor
  Labels: repair
 Attachments: 5523-1.2.txt


 Since streaming file to the node of different version is not allowed, and in 
 fact it would be the cause of repair hang, there is no point to allow 
 repairing among the nodes of different versions.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (CASSANDRA-5716) Remark on cassandra-5273 : Hanging system after OutOfMemory. Server cannot die due to uncaughtException handling

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

Jonathan Ellis resolved CASSANDRA-5716.
---

Resolution: Fixed
Fix Version/s: (was: 1.2.9)
1.2.7

Remark on cassandra-5273 : Hanging system after OutOfMemory. Server cannot
die due to uncaughtException handling

Key: CASSANDRA-5716
URL: https://issues.apache.org/jira/browse/CASSANDRA-5716
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.6
Environment: linux
Reporter: Ignace Desimpel
Assignee: Jonathan Ellis
Priority: Minor
Fix For: 1.2.7

Possible incorrect handling of an OOM as a result of modifications made for
issue cassandra-5273.
I could reproduce the OOM, with the patch of Cassandra-5273 applied.
The good news is that, at least in my case, it works fine : the system did
die !

However, due to multiple uncaughtException handling, multiple threads are
calling the exitThread.start() routine, causing an IllegalStateException.
There are some other exceptions also, but that seems logical. Also, after
calling the start() function, the thread(s) will continue to run, and that
could not be wanted.

Below I pasted the stack trace.
Just for your information, after all this works, and I could restart the
Cassandra server and redo the OOM
[stack trace moved to
http://aep.appspot.com/display/mQFNFHUh1VvQJYGcxRK0lQSM2j8/ ]

[jira] [Created] (CASSANDRA-5839) Save repair data to system table

Jonathan Ellis created CASSANDRA-5839:
-

 Summary: Save repair data to system table
 Key: CASSANDRA-5839
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5839
 Project: Cassandra
  Issue Type: New Feature
  Components: Core, Tools
Reporter: Jonathan Ellis
Priority: Minor
 Fix For: 2.0.1


As noted in CASSANDRA-2405, it would be useful to store repair results, 
particularly with sub-range repair available (CASSANDRA-5280).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-5839) Save repair data to system table


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

Jonathan Ellis commented on CASSANDRA-5839:
---

Something like this:

{code}
CREATE TABLE repair_sessions (
  keyspace text,
  columnfamily text,
  id timeuuid,
  range_begin text,
  range_end text,
  started_at timestamp,
  finished_at timestamp,
  PRIMARY KEY ((keyspace, columnfamily), id)
);
{code}

One interesting question is, do we make this per-machine or normally 
replicated?  The latter makes querying it much simpler since you don't have to 
aggregate and de-duplicate across the cluster.

 Save repair data to system table
 

 Key: CASSANDRA-5839
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5839
 Project: Cassandra
  Issue Type: New Feature
  Components: Core, Tools
Reporter: Jonathan Ellis
Priority: Minor
 Fix For: 2.0.1


 As noted in CASSANDRA-2405, it would be useful to store repair results, 
 particularly with sub-range repair available (CASSANDRA-5280).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (CASSANDRA-2405) should expose 'time since last successful repair' for easier aes monitoring


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

Jonathan Ellis resolved CASSANDRA-2405.
---

   Resolution: Duplicate
Fix Version/s: (was: 2.0.1)
 Assignee: (was: Sylvain Lebresne)

Created CASSANDRA-5839 to pick this up again.  I think there's enough baggage 
here (discussion of supercolumns, DCT) that it's worth starting fresh.

 should expose 'time since last successful repair' for easier aes monitoring
 ---

 Key: CASSANDRA-2405
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2405
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Peter Schuller
 Attachments: CASSANDRA-2405.patch, CASSANDRA-2405-v2.patch, 
 CASSANDRA-2405-v3.patch, CASSANDRA-2405-v4.patch


 The practical implementation issues of actually ensuring repair runs is 
 somewhat of an undocumented/untreated issue.
 One hopefully low hanging fruit would be to at least expose the time since 
 last successful repair for a particular column family, to make it easier to 
 write a correct script to monitor for lack of repair in a non-buggy fashion.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-4573) HSHA doesn't handle large messages gracefully

2013-08-01 Thread Pavel Yaskevich (JIRA)


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

Pavel Yaskevich updated CASSANDRA-4573:
---

Attachment: disruptor-thrift-server-0.2.2-SNAPSHOT.jar
CASSANDRA-4573.patch

[~thobbs] Please try trunk with attached patch and replace 
thrift-server-0.2.1.jar in lib/ with the one attached. This would detect frame 
size violation right when it's read from the socket and report an error as well 
as close connection.

 HSHA doesn't handle large messages gracefully
 -

 Key: CASSANDRA-4573
 URL: https://issues.apache.org/jira/browse/CASSANDRA-4573
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Tyler Hobbs
Assignee: Pavel Yaskevich
 Attachments: CASSANDRA-4573.patch, 
 disruptor-thrift-server-0.2.2-SNAPSHOT.jar, repro.py


 HSHA doesn't seem to enforce any kind of max message length, and when 
 messages are too large, it doesn't fail gracefully.
 With debug logs enabled, you'll see this:
 {{DEBUG 13:13:31,805 Unexpected state 16}}
 Which seems to mean that there's a SelectionKey that's valid, but isn't ready 
 for reading, writing, or accepting.
 Client-side, you'll get this thrift error (while trying to read a frame as 
 part of {{recv_batch_mutate}}):
 {{TTransportException: TSocket read 0 bytes}}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (CASSANDRA-5818) Duplicated error messages on directory creation error at startup


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

Jonathan Ellis reassigned CASSANDRA-5818:
-

Assignee: Aleksey Yeschenko

 Duplicated error messages on directory creation error at startup
 

 Key: CASSANDRA-5818
 URL: https://issues.apache.org/jira/browse/CASSANDRA-5818
 Project: Cassandra
  Issue Type: Bug
Reporter: Michaël Figuière
Assignee: Aleksey Yeschenko
Priority: Trivial
 Fix For: 2.0.1


 When I start Cassandra without the appropriate OS access rights to the 
 default Cassandra directories, I get a flood of {{ERROR}} messages at 
 startup, whereas one per directory would be more appropriate. See bellow:
 {code}
 ERROR 13:37:39,792 Failed to create 
 /var/lib/cassandra/data/system/schema_triggers directory
 ERROR 13:37:39,797 Failed to create 
 /var/lib/cassandra/data/system/schema_triggers directory
 ERROR 13:37:39,798 Failed to create 
 /var/lib/cassandra/data/system/schema_triggers directory
 ERROR 13:37:39,798 Failed to create 
 /var/lib/cassandra/data/system/schema_triggers directory
 ERROR 13:37:39,799 Failed to create 
 /var/lib/cassandra/data/system/schema_triggers directory
 ERROR 13:37:39,800 Failed to create /var/lib/cassandra/data/system/batchlog 
 directory
 ERROR 13:37:39,801 Failed to create /var/lib/cassandra/data/system/batchlog 
 directory
 ERROR 13:37:39,801 Failed to create /var/lib/cassandra/data/system/batchlog 
 directory
 ERROR 13:37:39,802 Failed to create /var/lib/cassandra/data/system/batchlog 
 directory
 ERROR 13:37:39,802 Failed to create 
 /var/lib/cassandra/data/system/peer_events directory
 ERROR 13:37:39,803 Failed to create 
 /var/lib/cassandra/data/system/peer_events directory
 ERROR 13:37:39,803 Failed to create 
 /var/lib/cassandra/data/system/peer_events directory
 ERROR 13:37:39,804 Failed to create 
 /var/lib/cassandra/data/system/compactions_in_progress directory
 ERROR 13:37:39,805 Failed to create 
 /var/lib/cassandra/data/system/compactions_in_progress directory
 ERROR 13:37:39,805 Failed to create 
 /var/lib/cassandra/data/system/compactions_in_progress directory
 ERROR 13:37:39,806 Failed to create 
 /var/lib/cassandra/data/system/compactions_in_progress directory
 ERROR 13:37:39,807 Failed to create 
 /var/lib/cassandra/data/system/compactions_in_progress directory
 ERROR 13:37:39,808 Failed to create /var/lib/cassandra/data/system/hints 
 directory
 ERROR 13:37:39,809 Failed to create /var/lib/cassandra/data/system/hints 
 directory
 ERROR 13:37:39,809 Failed to create /var/lib/cassandra/data/system/hints 
 directory
 ERROR 13:37:39,811 Failed to create /var/lib/cassandra/data/system/hints 
 directory
 ERROR 13:37:39,811 Failed to create /var/lib/cassandra/data/system/hints 
 directory
 ERROR 13:37:39,812 Failed to create 
 /var/lib/cassandra/data/system/schema_keyspaces directory
 ERROR 13:37:39,812 Failed to create 
 /var/lib/cassandra/data/system/schema_keyspaces directory
 ERROR 13:37:39,813 Failed to create 
 /var/lib/cassandra/data/system/schema_keyspaces directory
 ERROR 13:37:39,814 Failed to create 
 /var/lib/cassandra/data/system/schema_keyspaces directory
 ERROR 13:37:39,814 Failed to create 
 /var/lib/cassandra/data/system/schema_keyspaces directory
 ERROR 13:37:39,815 Failed to create 
 /var/lib/cassandra/data/system/range_xfers directory
 ERROR 13:37:39,816 Failed to create 
 /var/lib/cassandra/data/system/range_xfers directory
 ERROR 13:37:39,817 Failed to create 
 /var/lib/cassandra/data/system/range_xfers directory
 ERROR 13:37:39,817 Failed to create 
 /var/lib/cassandra/data/system/schema_columnfamilies directory
 ERROR 13:37:39,818 Failed to create 
 /var/lib/cassandra/data/system/schema_columnfamilies directory
 ERROR 13:37:39,818 Failed to create 
 /var/lib/cassandra/data/system/schema_columnfamilies directory
 ERROR 13:37:39,820 Failed to create 
 /var/lib/cassandra/data/system/schema_columnfamilies directory
 ERROR 13:37:39,821 Failed to create 
 /var/lib/cassandra/data/system/schema_columnfamilies directory
 ERROR 13:37:39,821 Failed to create 
 /var/lib/cassandra/data/system/schema_columnfamilies directory
 ERROR 13:37:39,822 Failed to create 
 /var/lib/cassandra/data/system/schema_columnfamilies directory
 ERROR 13:37:39,822 Failed to create 
 /var/lib/cassandra/data/system/schema_columnfamilies directory
 ERROR 13:37:39,823 Failed to create 
 /var/lib/cassandra/data/system/schema_columnfamilies directory
 ERROR 13:37:39,824 Failed to create 
 /var/lib/cassandra/data/system/schema_columnfamilies directory
 ERROR 13:37:39,824 Failed to create 
 /var/lib/cassandra/data/system/schema_columnfamilies directory
 ERROR 13:37:39,825 Failed to create 
 /var/lib/cassandra/data/system/schema_columnfamilies directory
 ERROR 13:37:39,825 Failed

[jira] [Assigned] (CASSANDRA-5019) Still too much object allocation on reads