[Cassandra Wiki] Trivial Update of Freya24W by Freya24W
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The Freya24W page has been changed by Freya24W: http://wiki.apache.org/cassandra/Freya24W New page: Name: Freya FiteBR My age: 27BR Country: AustraliaBR Town: Whitlands BR ZIP: 3678BR Street: 14 Paradise Falls RoadBR BR my webpage :: [[http://www.idolaremaja.com/blog/view/80432/the-story-behind-the-fat-loss-factor-victory|Read More At this website]]
[Cassandra Wiki] Trivial Update of Daniele19 by Daniele19
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The Daniele19 page has been changed by Daniele19: http://wiki.apache.org/cassandra/Daniele19 New page: My name: Maribel LewBR Age: 29BR Country: FranceBR City: Douai BR Post code: 59500BR Street: 84 rue des lieutemants ThomazoBR BR Also visit my blog post; [[http://pinoyagribusiness.com/forum/profile.html;a=profileu=24950|please click the up coming document]]
[jira] [Commented] (CASSANDRA-5431) cassandra-shuffle with JMX usernames and passwords
[ https://issues.apache.org/jira/browse/CASSANDRA-5431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13625225#comment-13625225 ] Michał Michalski commented on CASSANDRA-5431: - As far as I remember I wrote a patch for this some time ago when experimenting a bit with switching to vnodes. If you did not start to work on this task (so I won't double your work ;-) ), I'll check it later today. cassandra-shuffle with JMX usernames and passwords --- Key: CASSANDRA-5431 URL: https://issues.apache.org/jira/browse/CASSANDRA-5431 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.3 Reporter: Eric Dong Attachments: CASSANDRA-5431-whitespace.patch Unlike nodetool, cassandra-shuffle doesn't allow passing in a JMX username and password. This stops those who want to switch to vnodes from doing so if JMX access requires a username and a password. Patch to 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-5415) Batch with timestamp failed
[
https://issues.apache.org/jira/browse/CASSANDRA-5415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13625228#comment-13625228
]
Sylvain Lebresne commented on CASSANDRA-5415:
-
+1
Batch with timestamp failed
---
Key: CASSANDRA-5415
URL: https://issues.apache.org/jira/browse/CASSANDRA-5415
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.3
Reporter: Alexey Tereschenko
Assignee: Aleksey Yeschenko
Priority: Minor
Fix For: 1.2.4
Attachments: 5415.txt
When I create a prepared statement with the following CQL3 using Thrift
protocol:
{code}
BEGIN BATCH USING TIMESTAMP number
some INSERT INTO or UPDATE statements
APPLY BATCH
{code}
and execute this statement in a loop, I randomly get the error:
*InvalidRequestException(why:Timestamp must be set either on BATCH or
individual statements)*
All statements inside the batch have no individual USING TIMESTAMP.
--
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
[Cassandra Wiki] Trivial Update of CarlosMcc by CarlosMcc
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The CarlosMcc page has been changed by CarlosMcc: http://wiki.apache.org/cassandra/CarlosMcc New page: Thoes のカップル カタログ ブーツ UGG に属している 伝統的な。 彼ら 組み込む ゴム底しかかとし、が の深さ ステッチ 動作 上、外装。BR BR Also visit my web-site ... [[http://www.agubuto.com/|アグ 激安]]
[jira] [Commented] (CASSANDRA-5378) Fat Client: No longer works in 1.2
[ https://issues.apache.org/jira/browse/CASSANDRA-5378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13625254#comment-13625254 ] Sylvain Lebresne commented on CASSANDRA-5378: - I'm not sure what you are talking about. The example above have always worked and does not require the row key to be added to the indexedNames (which is an addition of this patch). The row key is primarily indexed but it's not indexed by a secondary index. And adding a secondary index on the row key is not something supported (largely because it would be useless). So anyway, I have removed that line in commit 69f05a704aafa90f2151db721312f3c5907abb2f if only because that restore the behavior of before that patch and let all cql dtests pass. If you still think there is a problem, please open a separate issue with a test case showing the problem you are talking about. Fat Client: No longer works in 1.2 -- Key: CASSANDRA-5378 URL: https://issues.apache.org/jira/browse/CASSANDRA-5378 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.0 Reporter: Carl Yeksigian Assignee: Carl Yeksigian Labels: client Fix For: 1.2.4 Attachments: 5378-1.2.txt, 5378.txt, 5378-v2.txt The current client only example doesn't compile. After doing some updates, the fat client still won't work, mainly because the schema is not being pushed to the fat client. I've made changes to the client to support CQL3 commands, to the ServiceManager to wait until a migration has completed before starting the client, and to the MigrationManager to not try to pull schemas from a fat client. -- 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-5378) Fat Client: No longer works in 1.2
[ https://issues.apache.org/jira/browse/CASSANDRA-5378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne resolved CASSANDRA-5378. - Resolution: Fixed Fat Client: No longer works in 1.2 -- Key: CASSANDRA-5378 URL: https://issues.apache.org/jira/browse/CASSANDRA-5378 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.0 Reporter: Carl Yeksigian Assignee: Carl Yeksigian Labels: client Fix For: 1.2.4 Attachments: 5378-1.2.txt, 5378.txt, 5378-v2.txt The current client only example doesn't compile. After doing some updates, the fat client still won't work, mainly because the schema is not being pushed to the fat client. I've made changes to the client to support CQL3 commands, to the ServiceManager to wait until a migration has completed before starting the client, and to the MigrationManager to not try to pull schemas from a fat client. -- 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
[1/2] git commit: Revert adding the key alias to the 2ndary indexes names (from 5378 patch)
Updated Branches:
refs/heads/trunk bc6b5f492 - 23d15ee4e
Revert adding the key alias to the 2ndary indexes names (from 5378 patch)
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/69f05a70
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/69f05a70
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/69f05a70
Branch: refs/heads/trunk
Commit: 69f05a704aafa90f2151db721312f3c5907abb2f
Parents: 56f35db
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Mon Apr 8 11:39:16 2013 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Mon Apr 8 11:39:30 2013 +0200
--
.../cassandra/cql3/statements/SelectStatement.java |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/69f05a70/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
index 093f245..061e0ac 100644
--- a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
@@ -1061,7 +1061,6 @@ public class SelectStatement implements CQLStatement
stmt.isKeyRange = true;
boolean hasEq = false;
SetByteBuffer indexedNames = new HashSetByteBuffer();
-indexedNames.add(cfm.getKeyName());
for (ColumnDefinition cfdef :
cfm.getColumn_metadata().values())
{
if (cfdef.getIndexType() != null)
[Cassandra Wiki] Trivial Update of MelodeeMa by MelodeeMa
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The MelodeeMa page has been changed by MelodeeMa: http://wiki.apache.org/cassandra/MelodeeMa New page: I'm a retired Franchisor, Business Advisor, Humanitarian and I run a Think Tank, as well as doing lots of Traveling, Writing, Cycling, Flying, Volunteering enjoy life to the fullest.BR BR Here is my web-site; [[http://www.squidoo.com/motorola-earpiece-for-2-way-radios|motorola earpieces for radios]]
buildbot failure in ASF Buildbot on cassandra-trunk
The Buildbot has detected a new failure on builder cassandra-trunk while building cassandra. Full details are available at: http://ci.apache.org/builders/cassandra-trunk/builds/2538 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: portunus_ubuntu Build Reason: scheduler Build Source Stamp: [branch trunk] 23d15ee4e03151ff9fef3acae06fc391a42894be Blamelist: Sylvain Lebresne sylv...@datastax.com BUILD FAILED: failed shell sincerely, -The Buildbot
[jira] [Commented] (CASSANDRA-5074) Add an official way to disable compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-5074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13625263#comment-13625263 ] Sylvain Lebresne commented on CASSANDRA-5074: - The general idea lgtm. A few remarks though: * There is no handling of CQL3 (which is in the package org.apache.cassandra.cql3). I'll not that for CQL3, this setting should probably be a 'compaction' option, not at top-level one. Thruth being told, maybe it would be cleaner to have that be a compaction option in the code too (handled by AbstractCompactionStrategy)? * Currently, whether compaction is disabled or not is checked by the compaction strategy themselves. In particular, SizeTiered directly check the min and max thresholds (rather than calling isCompactionDisabled) in getNextBackgroundSSTables, so that needs to be fixed. Furthermore, those checks are redundant with the newly added checks in CompactionManager. And since there's the new 'isActive' flag that also mean don't create a compaction task, maybe it would be simpler to create an AbstractCompactionStrategy.isEnabled() method that would return 'isActive !isAutoCompactionDisabled()' and use that exclusively. * We should probably now refuse setting the min/max thresholds to 0 everywhere (and add a mention in the NEWS file). * In nodeCmd, the convention for methods that take a keyspace and column family argument is that if they are not given, the method applies to all keyspace/CF. Could be handy here too. * Nit: For the enableAutoCompaction with an argument, we can add a @VisibleForTesting annotation. Add an official way to disable compaction - Key: CASSANDRA-5074 URL: https://issues.apache.org/jira/browse/CASSANDRA-5074 Project: Cassandra Issue Type: Bug Reporter: Jonathan Ellis Assignee: Marcus Eriksson Priority: Minor Fix For: 2.0 Attachments: 0001-CASSANDRA-5074-make-it-possible-to-disable-autocompa.patch We've traditionally used min or max compaction threshold = 0 to disable compaction, but this isn't exactly intuitive and it's inconsistently implemented -- allowed from jmx, not allowed from cli. -- 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
[Cassandra Wiki] Trivial Update of TereseCUM by TereseCUM
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The TereseCUM page has been changed by TereseCUM: http://wiki.apache.org/cassandra/TereseCUM New page: I'm kind of new here so please make me welcome, you can call me Austin I recently signed up for the 167mail.com account but have been having problems so I don't always acquire all the messages sent to me.BR BR I have been active on the web for about 6 years but have only started out a blog internet site hence will be thrilled if you take a look and sign upBR BR Feel free to visit my web-site ... [[http://www.im-logi.co.uk|Social Media Blog]]
[Cassandra Wiki] Trivial Update of EllieCono by EllieCono
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The EllieCono page has been changed by EllieCono: http://wiki.apache.org/cassandra/EllieCono New page: BR BR Here is my web-site - [[http://getfreeitunecodes.blogspot.com/|how to get f˛ree itnes codes]]
[jira] [Updated] (CASSANDRA-5349) Add binary protocol support for bind variables to non-prepared statements
[ https://issues.apache.org/jira/browse/CASSANDRA-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-5349: --- Attachment: 0001-CASSANDRA-5349-binary-protocol-support-for-binding-v.patch Add binary protocol support for bind variables to non-prepared statements - Key: CASSANDRA-5349 URL: https://issues.apache.org/jira/browse/CASSANDRA-5349 Project: Cassandra Issue Type: Task Components: API Affects Versions: 1.2.0 Reporter: Jonathan Ellis Assignee: Marcus Eriksson Priority: Minor Fix For: 1.2.4 Attachments: 0001-CASSANDRA-5349-binary-protocol-support-for-binding-v.patch Currently, the binary protocol allows requests as string or [prepared statement] id + bind vars. Allowing string + bind vars as well would simplify life for users with one-off statements and not have to choose between adding boilerplate for PS, and having to manually escape parameters, which is particularly painful for binary data. -- 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] [Created] (CASSANDRA-5436) Binary protocol versioning
Marcus Eriksson created CASSANDRA-5436: -- Summary: Binary protocol versioning Key: CASSANDRA-5436 URL: https://issues.apache.org/jira/browse/CASSANDRA-5436 Project: Cassandra Issue Type: Improvement Reporter: Marcus Eriksson There should be a way to version the binary protocol, CASSANDRA-5349 adds a message that breaks compatibility (QueryMessage) and the ticket half-handles versioning - it allows old clients to connect and execute queries (by always replying in the same version as the message sent by the client), it does not allow new clients to connect to old servers though. -- 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] [Created] (CASSANDRA-5437) multiget specific key filtering
Brooke Bryan created CASSANDRA-5437: --- Summary: multiget specific key filtering Key: CASSANDRA-5437 URL: https://issues.apache.org/jira/browse/CASSANDRA-5437 Project: Cassandra Issue Type: Improvement Reporter: Brooke Bryan Priority: Minor Currently, you are able to specify a list of columns, or a slice when pulling back keys from a multiget, however, we find ourselves pulling back a lot more data than we actually need when columns overlap. We currently have 2 options (as far as im aware). 1. perform multiple get calls, and get the required data back, but connect to thrift more 2. perform a multiget, and get more data due to column crossovers, but in a single request. Similar to a batch mutation, a batch read would solve this problem perfectly. e.g. read = [ 'columnFamily' = [ 'key' = ColumnPath, 'key2' = SlicePredicate, 'key3' = ColumnPath ] ]; result = batch_read(read); //result 'columnFamily' = [ 'key' = [1 = 'a',2 = 'b',3 = 'c'], 'key2' = [4 = 'd',5 = 'e'], 'key3' = [1 = 'a',3 = 'c'] ] -- 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
[Cassandra Wiki] Trivial Update of AnnmarieH by AnnmarieH
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The AnnmarieH page has been changed by AnnmarieH: http://wiki.apache.org/cassandra/AnnmarieH New page: Independence-born Shuuya is hooked on Magnetic Messaging audio books and studying an instrument.BR Last but not least the thing that he treasure most is spending time with his companions.BR BR Also visit my site [[http://spazzam1.com/profile/laurenekea|click the following page]]
[Cassandra Wiki] Trivial Update of AnnettaCo by AnnettaCo
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The AnnettaCo page has been changed by AnnettaCo: http://wiki.apache.org/cassandra/AnnettaCo?action=diffrev1=1rev2=3 - I am 18 years old and my name is Annetta Colby.BR - I life in Vaterstetten (Germany).BR + My name: Brenda BallBR + Age: 28BR + Country: United StatesBR + Town: Florida BR + ZIP: 43545BR + Street: 2045 Hill StreetBR BR - Feel free to surf to my blog post ... [[http://goalonline.net/read_blog/19990/speedy-secrets-of-airport-parking-examined|just click the next website page]] + my blog - [[http://www.iphonerecoveryspecialist.com/index.php?option=com_blogview=commentspid=48772Itemid=0|Read the Full Article]]
git commit: Fix prepared BATCH statements with batch-level timestamps
Updated Branches:
refs/heads/cassandra-1.2 69f05a704 - 1429c54b0
Fix prepared BATCH statements with batch-level timestamps
patch by Aleksey Yeschenko; reviewed by Sylvain Lebresne for
CASSANDRA-5415
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/1429c54b
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/1429c54b
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/1429c54b
Branch: refs/heads/cassandra-1.2
Commit: 1429c54b01f6116ecb95f33f6c656e9d1f310137
Parents: 69f05a7
Author: Aleksey Yeschenko alek...@apache.org
Authored: Mon Apr 8 15:46:58 2013 +0300
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Mon Apr 8 15:46:58 2013 +0300
--
CHANGES.txt|1 +
.../cassandra/cql3/statements/BatchStatement.java |5 +
2 files changed, 2 insertions(+), 4 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/1429c54b/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 12f38b6..5347f91 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -30,6 +30,7 @@
* Add null syntax support in CQL3 for inserts (CASSANDRA-3783)
* Allow unauthenticated set_keyspace() calls (CASSANDRA-5423)
* Fix potential incremental backups race (CASSANDRA-5410)
+ * Fix prepared BATCH statements with batch-level timestamps (CASSANDRA-5415)
Merged from 1.1:
* cli: Quote ks and cf names in schema output when needed (CASSANDRA-5052)
* Fix bad default for min/max timestamp in SSTableMetadata (CASSANDRA-5372)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/1429c54b/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java
b/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java
index 6200237..f93eb63 100644
--- a/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java
@@ -95,11 +95,8 @@ public class BatchStatement extends ModificationStatement
MapPairString, ByteBuffer, IMutation mutations = new
HashMapPairString, ByteBuffer, IMutation();
for (ModificationStatement statement : statements)
{
-if (isSetTimestamp())
-statement.setTimestamp(getTimestamp(now));
-
// Group mutation together, otherwise they won't get applied
atomically
-for (IMutation m : statement.getMutations(variables, local, cl,
now))
+for (IMutation m : statement.getMutations(variables, local, cl,
getTimestamp(now)))
{
if (m instanceof CounterMutation type != Type.COUNTER)
throw new InvalidRequestException(Counter mutations are
only allowed in COUNTER batches);
[2/2] git commit: Merge branch 'cassandra-1.2' into trunk
Merge branch 'cassandra-1.2' into trunk
Conflicts:
src/java/org/apache/cassandra/cql3/statements/BatchStatement.java
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/71e764cb
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/71e764cb
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/71e764cb
Branch: refs/heads/trunk
Commit: 71e764cb04d291597af8d6b65044bf5ae09360b2
Parents: 23d15ee 1429c54
Author: Aleksey Yeschenko alek...@apache.org
Authored: Mon Apr 8 15:58:24 2013 +0300
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Mon Apr 8 15:58:24 2013 +0300
--
CHANGES.txt|1 +
.../cassandra/cql3/statements/BatchStatement.java |5 +
2 files changed, 2 insertions(+), 4 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/71e764cb/CHANGES.txt
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/71e764cb/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java
--
diff --cc src/java/org/apache/cassandra/cql3/statements/BatchStatement.java
index 6987bf6,f93eb63..d5038da
--- a/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java
@@@ -96,11 -95,8 +96,8 @@@ public class BatchStatement extends Mod
MapPairString, ByteBuffer, IMutation mutations = new
HashMapPairString, ByteBuffer, IMutation();
for (ModificationStatement statement : statements)
{
- if (isSetTimestamp())
- statement.setTimestamp(getTimestamp(now));
-
// Group mutation together, otherwise they won't get applied
atomically
- for (IMutation m : statement.getMutationsInternal(variables,
local, cl, now, true))
-for (IMutation m : statement.getMutations(variables, local, cl,
getTimestamp(now)))
++for (IMutation m : statement.getMutationsInternal(variables,
local, cl, getTimestamp(now), true))
{
if (m instanceof CounterMutation type != Type.COUNTER)
throw new InvalidRequestException(Counter mutations are
only allowed in COUNTER batches);
[1/2] git commit: Fix prepared BATCH statements with batch-level timestamps
Updated Branches:
refs/heads/trunk 23d15ee4e - 71e764cb0
Fix prepared BATCH statements with batch-level timestamps
patch by Aleksey Yeschenko; reviewed by Sylvain Lebresne for
CASSANDRA-5415
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/1429c54b
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/1429c54b
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/1429c54b
Branch: refs/heads/trunk
Commit: 1429c54b01f6116ecb95f33f6c656e9d1f310137
Parents: 69f05a7
Author: Aleksey Yeschenko alek...@apache.org
Authored: Mon Apr 8 15:46:58 2013 +0300
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Mon Apr 8 15:46:58 2013 +0300
--
CHANGES.txt|1 +
.../cassandra/cql3/statements/BatchStatement.java |5 +
2 files changed, 2 insertions(+), 4 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/1429c54b/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 12f38b6..5347f91 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -30,6 +30,7 @@
* Add null syntax support in CQL3 for inserts (CASSANDRA-3783)
* Allow unauthenticated set_keyspace() calls (CASSANDRA-5423)
* Fix potential incremental backups race (CASSANDRA-5410)
+ * Fix prepared BATCH statements with batch-level timestamps (CASSANDRA-5415)
Merged from 1.1:
* cli: Quote ks and cf names in schema output when needed (CASSANDRA-5052)
* Fix bad default for min/max timestamp in SSTableMetadata (CASSANDRA-5372)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/1429c54b/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java
b/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java
index 6200237..f93eb63 100644
--- a/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java
@@ -95,11 +95,8 @@ public class BatchStatement extends ModificationStatement
MapPairString, ByteBuffer, IMutation mutations = new
HashMapPairString, ByteBuffer, IMutation();
for (ModificationStatement statement : statements)
{
-if (isSetTimestamp())
-statement.setTimestamp(getTimestamp(now));
-
// Group mutation together, otherwise they won't get applied
atomically
-for (IMutation m : statement.getMutations(variables, local, cl,
now))
+for (IMutation m : statement.getMutations(variables, local, cl,
getTimestamp(now)))
{
if (m instanceof CounterMutation type != Type.COUNTER)
throw new InvalidRequestException(Counter mutations are
only allowed in COUNTER batches);
[jira] [Updated] (CASSANDRA-5250) Improve LeveledScanner work estimation
[ https://issues.apache.org/jira/browse/CASSANDRA-5250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-5250: Fix Version/s: 2.0 Improve LeveledScanner work estimation -- Key: CASSANDRA-5250 URL: https://issues.apache.org/jira/browse/CASSANDRA-5250 Project: Cassandra Issue Type: Improvement Reporter: Jonathan Ellis Assignee: Marcus Eriksson Labels: compaction Fix For: 2.0 Attachments: 0001-CASSANDRA-5250.patch, 0001-CASSANDRA-5250-v2.patch, 0001-CASSANDRA-5250-v4.patch, 5250-v3.txt See https://issues.apache.org/jira/browse/CASSANDRA-5222?focusedCommentId=13577420page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13577420 -- 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
[Cassandra Wiki] Trivial Update of JacklynHa by JacklynHa
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The JacklynHa page has been changed by JacklynHa: http://wiki.apache.org/cassandra/JacklynHa New page: Dannie Echavarria is his identify but it's not the most masucline name out there. Some time back he chose to live in Tennessee and he will never move. Meter studying is his working day occupation now. It really is not a frequent issue but what he likes undertaking is to perform footbal and he's been doing it for fairly a even though.BR You can always discover his website here: http://www.xoomshop.com/B007261A36/Samsung_DV300F_Dual_View_Smart_Camera___Black_EC_DV300FBPBUS.htmlBR BR Here is my site [[http://www.xoomshop.com/B007261A36/Samsung_DV300F_Dual_View_Smart_Camera___Black_EC_DV300FBPBUS.html|click through the next webpage]]
[Cassandra Wiki] Trivial Update of Leading_Digital_Cameras_For_2012 by JacklynHa
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The Leading_Digital_Cameras_For_2012 page has been changed by JacklynHa: http://wiki.apache.org/cassandra/Leading_Digital_Cameras_For_2012 New page: The application ought to include things like essential tools like cropping or chopping a portion from the photograph in 1 straightforward phase. There have to be a gadget to combine several components from a variety of pictures to make a collage. It can be important to have a guide adjustment unit for brightness and contrast. [[http://www.xoomshop.com/B007261A36/Samsung_DV300F_Dual_View_Smart_Camera___Black_EC_DV300FBPBUS.html|click through the next webpage]]. You may need a application editing gadget that allows you modify the colour stability and saturation. Filtering resources will ideally contain customized, CC or Wratten filters. The unit that allows you to change the impression coloration to black and white have to include several enhancing selections. Two on the most common are greyscale and duotones.BR BR Other crucial Electronic Art tools that may help you in creating creative statements with your photos incorporate worldwide or selective dodging, burning, blurring and mosaic. More advanced modifying plans incorporate vignetting, linen, solarizing, posterizing and embossing. Most wordprocessing and picture modifying software furnish photograph administration choices these days that enable for you to area an image in entrance of textual content, in-line with textual content or powering text. Sophisticated desk-leading publishing computer software will provide text and image containers to manually place your material.BR BR And, if you are really have to stick tightly to a budget but want to get a great reward for consider the Electrical power Shot SX230 HS 12MP Digital Digicam with HS System and Digic four Picture Processor at $199. This splendor in fact shoots at 12.one MP, offers autostablizing, a 14X optical zoom program and it is completely ready to deal with not only your one-shot, but video requirements. For our funds, this 1 is more than the top for your reward checklist.BR BR When [[HTTP://Www.Xoomshop.com/B0078KP0SM/Pentax_Optio_WG_2_Digital_Camera__Black.html|xoomshop.com]] were new, the biggest challenge was to discover the camera that presented the most megapixels. The pixels are the dots that sort the image on the display. Far more dots indicate a higher resolution of your picture. Nearly all cameras today provide a least of ten megapixels. That resolution implies that 10 million dots fill the laptop screen for every single shot on the digital camera.BR BR A dwell-preview digital camera, also referred to as a electronic nonetheless camera, can make reference to the products that have an Liquid crystal display monitor on the again. This is utilised for framing, previewing just before taking photos and examining the photographs right after they have been taken. The photos can be transferred to a pc or laptop computer by using the USB mass storage unit course.BR BR Several. Images may be set in t-shirts, materials generating immediately into simple puzzles. Image Puzzles are created via creating photos upon any difficult element of cardboard, and cutting the photo straight into bits, These kinds of the make excellent loved ones provides.BR BR DigitalCameraReview has presented us a wonderful comparison of five of the top point and shoot cameras. The affordable rates variety from $75 to $415. Based on which functions you decide on, you can get a wonderful minor compact digital camera that is light-weight and cost-effective.BR BR There ought to be no difficulty in uploading images with the other equipment. The card or stick that retailers the memory of the electronic electronic camera should be suitable with the form of media to be utilised. The variety of battery utilized with the inexpensive camera is a one regular knowledge you need to know when buying. There is a variation in utilizing high priced batteries and rechargeable types. The photographer with the passion for taking high good quality photographs will uncover cheap electronic sort cameras similar to massive-stop kinds in effectiveness. Images journals and digital digital camera buyer's guides assist in the assortment. If and only when they have good good quality basic qualities.
buildbot success in ASF Buildbot on cassandra-trunk
The Buildbot has detected a restored build on builder cassandra-trunk while building cassandra. Full details are available at: http://ci.apache.org/builders/cassandra-trunk/builds/2539 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: portunus_ubuntu Build Reason: scheduler Build Source Stamp: [branch trunk] 71e764cb04d291597af8d6b65044bf5ae09360b2 Blamelist: Aleksey Yeschenko alek...@apache.org Build succeeded! sincerely, -The Buildbot
[jira] [Updated] (CASSANDRA-5349) Add binary protocol support for bind variables to non-prepared statements
[ https://issues.apache.org/jira/browse/CASSANDRA-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-5349: Fix Version/s: (was: 1.2.4) 2.0 Add binary protocol support for bind variables to non-prepared statements - Key: CASSANDRA-5349 URL: https://issues.apache.org/jira/browse/CASSANDRA-5349 Project: Cassandra Issue Type: Task Components: API Affects Versions: 1.2.0 Reporter: Jonathan Ellis Assignee: Marcus Eriksson Priority: Minor Fix For: 2.0 Attachments: 0001-CASSANDRA-5349-binary-protocol-support-for-binding-v.patch Currently, the binary protocol allows requests as string or [prepared statement] id + bind vars. Allowing string + bind vars as well would simplify life for users with one-off statements and not have to choose between adding boilerplate for PS, and having to manually escape parameters, which is particularly painful for binary data. -- 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-5430) Make Auth.SUPERUSER_SETUP_DELAY configurable
[ https://issues.apache.org/jira/browse/CASSANDRA-5430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13625362#comment-13625362 ] Aleksey Yeschenko commented on CASSANDRA-5430: -- Can you clarify? I don't exactly understand what you mean. Make Auth.SUPERUSER_SETUP_DELAY configurable Key: CASSANDRA-5430 URL: https://issues.apache.org/jira/browse/CASSANDRA-5430 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.2.2 Reporter: John Sanda Assignee: Aleksey Yeschenko Priority: Minor Labels: authentication Fix For: 1.2.4 Attachments: 5430.txt I would like to make SUPERUSER_SETUP_DELAY configurable for automated tests. I have tests that stand up a local cluster, and sometimes if I just run a single test class, the total execution time to stand up the (usually two) nodes and run the tests takes less than 20 seconds. I am running on fast hardware, so I can probably get by with a lower value in most cases, but maybe one of my teammates runs on slower hardware and needs a larger value. I do not see this as a problem for production use. It would just be nice to have it configurable for dev environments. 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] [Created] (CASSANDRA-5438) possibly wrong stream id when cassandra reports an error
Sorin Manolache created CASSANDRA-5438: -- Summary: possibly wrong stream id when cassandra reports an error Key: CASSANDRA-5438 URL: https://issues.apache.org/jira/browse/CASSANDRA-5438 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.3 Environment: Linux x86_64 Reporter: Sorin Manolache I use the binary protocol. I send a correct prepare request on stream 6 (packets 7 and 9 in the attached pcap). Then I send a malformed execute request on stream 7 (packets 13 and 15). The server responds with an error response (packet 17). The stream id field of the response contains 0. Shouldn't it contain 7, the id of the execute request? The pcap file is here: https://www.dropbox.com/s/lvo2kie7k3owvf8/cassandra_1.2.3.pcap -- 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-5436) Binary protocol versioning
[ https://issues.apache.org/jira/browse/CASSANDRA-5436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13625365#comment-13625365 ] Sylvain Lebresne commented on CASSANDRA-5436: - Actually, would you mind pull out the versioning bits from CASSANDRA-5349 and move it there? I'd like to handle that part correctly (including forking the doc, etc...) before starting to add too much new stuffs. bq. it does not allow new clients to connect to old servers though Well they can connect, they will just get a ProtocolException with Invalid or unsupported protocol version :). More seriously, I'm not sure we can do much better, new clients will have to talk the old protocol to talk to old servers. That being say, the exception we currently throw is not as helpful as can be because we include which version we don't speak but not which version we speak. I don't know, maybe adding some '[supported_version=...]' to the error string could be enough (though slightly ugly, granted). Binary protocol versioning -- Key: CASSANDRA-5436 URL: https://issues.apache.org/jira/browse/CASSANDRA-5436 Project: Cassandra Issue Type: Improvement Reporter: Marcus Eriksson There should be a way to version the binary protocol, CASSANDRA-5349 adds a message that breaks compatibility (QueryMessage) and the ticket half-handles versioning - it allows old clients to connect and execute queries (by always replying in the same version as the message sent by the client), it does not allow new clients to connect to old servers though. -- 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-5438) possibly wrong stream id when cassandra reports an error
[ https://issues.apache.org/jira/browse/CASSANDRA-5438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne resolved CASSANDRA-5438. - Resolution: Duplicate I highly suspect this has been fixed by CASSANDRA-5164. You can try against the current 1.2 tip if you want, but otherwise 1.2.4 should hopefully be out soonish. Of course, if CASSANDRA-5164 doesn't fix it, feel free to re-open. possibly wrong stream id when cassandra reports an error Key: CASSANDRA-5438 URL: https://issues.apache.org/jira/browse/CASSANDRA-5438 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.3 Environment: Linux x86_64 Reporter: Sorin Manolache I use the binary protocol. I send a correct prepare request on stream 6 (packets 7 and 9 in the attached pcap). Then I send a malformed execute request on stream 7 (packets 13 and 15). The server responds with an error response (packet 17). The stream id field of the response contains 0. Shouldn't it contain 7, the id of the execute request? The pcap file is here: https://www.dropbox.com/s/lvo2kie7k3owvf8/cassandra_1.2.3.pcap -- 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-4914) Aggregate functions in CQL
[ https://issues.apache.org/jira/browse/CASSANDRA-4914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13625382#comment-13625382 ] Sylvain Lebresne commented on CASSANDRA-4914: - bq. For this, the proposal is to add a new AggregateFunction interface for a function like SUM, which is an extension of Function which takes many arguments? That's what I had in mind yes. Though AggregateFunction might not be a direct subclass of Function, maybe they'll just extend the same abstract class/interface, I haven't looked that closely. bq. the aggregate function would be iteratively called on each grouping. Is that accurate? Exactly. Basically I'm suggesting that the grouping itself can be done separately by the Selection object since it's completely generic, it doesn't depend on which aggregate function you'll execute. Aggregate functions in CQL -- Key: CASSANDRA-4914 URL: https://issues.apache.org/jira/browse/CASSANDRA-4914 Project: Cassandra Issue Type: Bug Reporter: Vijay Assignee: Vijay Fix For: 2.0 The requirement is to do aggregation of data in Cassandra (Wide row of column values of int, double, float etc). With some basic agree gate functions like AVG, SUM, Mean, Min, Max, etc (for the columns within a row). Example: SELECT * FROM emp WHERE empID IN (130) ORDER BY deptID DESC; empid | deptid | first_name | last_name | salary ---+++---+ 130 | 3 | joe| doe | 10.1 130 | 2 | joe| doe |100 130 | 1 | joe| doe | 1e+03 SELECT sum(salary), empid FROM emp WHERE empID IN (130); sum(salary) | empid -+ 1110.1| 130 -- 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-5430) Make Auth.SUPERUSER_SETUP_DELAY configurable
[
https://issues.apache.org/jira/browse/CASSANDRA-5430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13625413#comment-13625413
]
Jonathan Ellis commented on CASSANDRA-5430:
---
{code}
public synchronized void initServer() throws ConfigurationException
{
initServer(RING_DELAY);
}
public synchronized void initServer(int delay) throws ConfigurationException
{
...
{code}
Normal startup calls initServer(). Test code calls initServer(0).
Make Auth.SUPERUSER_SETUP_DELAY configurable
Key: CASSANDRA-5430
URL: https://issues.apache.org/jira/browse/CASSANDRA-5430
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.2.2
Reporter: John Sanda
Assignee: Aleksey Yeschenko
Priority: Minor
Labels: authentication
Fix For: 1.2.4
Attachments: 5430.txt
I would like to make SUPERUSER_SETUP_DELAY configurable for automated tests.
I have tests that stand up a local cluster, and sometimes if I just run a
single test class, the total execution time to stand up the (usually two)
nodes and run the tests takes less than 20 seconds. I am running on fast
hardware, so I can probably get by with a lower value in most cases, but
maybe one of my teammates runs on slower hardware and needs a larger value.
I do not see this as a problem for production use. It would just be nice to
have it configurable for dev environments.
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] [Commented] (CASSANDRA-5430) Make Auth.SUPERUSER_SETUP_DELAY configurable
[ https://issues.apache.org/jira/browse/CASSANDRA-5430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13625419#comment-13625419 ] Aleksey Yeschenko commented on CASSANDRA-5430: -- Right. I'm aware of that. I assumed you were referring to us overriding cassandra.ring_delay_ms in dtests and not to junit. So, I'm not sure that this is relevant. I think what jsanda wants is to be able to externally override S_S_DELAY. We decided it was not worth doing it just for the sake of dtests, but dtests are not the only usecase, so I'm open to allowing that (via cassandra.superuser_setup_delay_ms property). Make Auth.SUPERUSER_SETUP_DELAY configurable Key: CASSANDRA-5430 URL: https://issues.apache.org/jira/browse/CASSANDRA-5430 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.2.2 Reporter: John Sanda Assignee: Aleksey Yeschenko Priority: Minor Labels: authentication Fix For: 1.2.4 Attachments: 5430.txt I would like to make SUPERUSER_SETUP_DELAY configurable for automated tests. I have tests that stand up a local cluster, and sometimes if I just run a single test class, the total execution time to stand up the (usually two) nodes and run the tests takes less than 20 seconds. I am running on fast hardware, so I can probably get by with a lower value in most cases, but maybe one of my teammates runs on slower hardware and needs a larger value. I do not see this as a problem for production use. It would just be nice to have it configurable for dev environments. 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] [Commented] (CASSANDRA-5430) Make Auth.SUPERUSER_SETUP_DELAY configurable
[ https://issues.apache.org/jira/browse/CASSANDRA-5430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13625429#comment-13625429 ] Jonathan Ellis commented on CASSANDRA-5430: --- That's reasonable. Make Auth.SUPERUSER_SETUP_DELAY configurable Key: CASSANDRA-5430 URL: https://issues.apache.org/jira/browse/CASSANDRA-5430 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.2.2 Reporter: John Sanda Assignee: Aleksey Yeschenko Priority: Minor Labels: authentication Fix For: 1.2.4 Attachments: 5430.txt I would like to make SUPERUSER_SETUP_DELAY configurable for automated tests. I have tests that stand up a local cluster, and sometimes if I just run a single test class, the total execution time to stand up the (usually two) nodes and run the tests takes less than 20 seconds. I am running on fast hardware, so I can probably get by with a lower value in most cases, but maybe one of my teammates runs on slower hardware and needs a larger value. I do not see this as a problem for production use. It would just be nice to have it configurable for dev environments. 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] [Commented] (CASSANDRA-4885) Remove or rework per-row bloom filters
[ https://issues.apache.org/jira/browse/CASSANDRA-4885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13625435#comment-13625435 ] Jonathan Ellis commented on CASSANDRA-4885: --- Is this still a problem or was it fixed by the CASSANDRA-5385 stuff? Remove or rework per-row bloom filters -- Key: CASSANDRA-4885 URL: https://issues.apache.org/jira/browse/CASSANDRA-4885 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Assignee: Jason Brown Fix For: 2.0 Attachments: 0001-CASSANRDA-4885-Remove-per-row-bloom-filter.patch, 0002-CASSANRDA-4885-update-test.patch, 4885-v1.patch, 4885-v2.patch Per-row bloom filters may be a misfeature. On small rows we don't create them. On large rows we essentially only do slice queries that can't take advantage of it. And on very large rows if we ever did deserialize it, the performance hit of doing so would outweigh the benefit of skipping the actual read. -- 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-5277) rename AntiEntropyService
[ https://issues.apache.org/jira/browse/CASSANDRA-5277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-5277. --- Resolution: Fixed rename AntiEntropyService - Key: CASSANDRA-5277 URL: https://issues.apache.org/jira/browse/CASSANDRA-5277 Project: Cassandra Issue Type: Task Components: Core Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Labels: repair Fix For: 2.0 Maybe ActiveRepairService or ManualRepairService. AntiEntropy doesn't help anyone find it who knows they want to find the repair code. -- 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-5371) Perform size-tiered compactions in L0
[ https://issues.apache.org/jira/browse/CASSANDRA-5371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13625443#comment-13625443 ] T Jake Luciani commented on CASSANDRA-5371: --- I'm going to test this out to show how it helps our workload. In the meantime I think this is fine to commit for 2.0 if you'd like to get it in now. Perform size-tiered compactions in L0 - Key: CASSANDRA-5371 URL: https://issues.apache.org/jira/browse/CASSANDRA-5371 Project: Cassandra Issue Type: Bug Components: Core Reporter: Jonathan Ellis Assignee: Jonathan Ellis Fix For: 2.0 Attachments: HybridCompactionStrategy.java If LCS gets behind, read performance deteriorates as we have to check bloom filters on man sstables in L0. For wide rows, this can mean having to seek for each one since the BF doesn't help us reject much. Performing size-tiered compaction in L0 will mitigate this until we can catch up on merging it into higher levels. -- 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-4316) Compaction Throttle too bursty with large rows
[ https://issues.apache.org/jira/browse/CASSANDRA-4316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4316: -- Fix Version/s: (was: 1.2.4) 2.0 Compaction Throttle too bursty with large rows -- Key: CASSANDRA-4316 URL: https://issues.apache.org/jira/browse/CASSANDRA-4316 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.8.0 Reporter: Wayne Lewis Assignee: Yuki Morishita Fix For: 2.0 Attachments: 4316-1.2.txt, 4316-1.2-v2.txt In org.apache.cassandra.db.compaction.CompactionIterable the check for compaction throttling occurs once every 1000 rows. In our workload this is much too large as we have many large rows (16 - 100 MB). With a 100 MB row, about 100 GB is read (and possibly written) before the compaction throttle sleeps. This causes bursts of essentially unthrottled compaction IO followed by a long sleep which yields inconsistence performance and high error rates during the bursts. We applied a workaround to check throttle every row which solved our performance and error issues: line 116 in org.apache.cassandra.db.compaction.CompactionIterable: if ((row++ % 1000) == 0) replaced with if ((row++ % 1) == 0) I think the better solution is to calculate how often throttle should be checked based on the throttle rate to apply sleeps more consistently. E.g. if 16MB/sec is the limit then check for sleep after every 16MB is read so sleeps are spaced out about every second. -- 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-5220) Repair improvements when using vnodes
[ https://issues.apache.org/jira/browse/CASSANDRA-5220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-5220: -- Fix Version/s: (was: 1.2.4) 2.0 Repair improvements when using vnodes - Key: CASSANDRA-5220 URL: https://issues.apache.org/jira/browse/CASSANDRA-5220 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.2.0 beta 1 Reporter: Brandon Williams Assignee: Yuki Morishita Fix For: 2.0 Currently when using vnodes, repair takes much longer to complete than without them. This appears at least in part because it's using a session per range and processing them sequentially. This generates a lot of log spam with vnodes, and while being gentler and lighter on hard disk deployments, ssd-based deployments would often prefer that repair be as fast as possible. -- 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
[Cassandra Wiki] Trivial Update of LenoreRut by LenoreRut
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The LenoreRut page has been changed by LenoreRut: http://wiki.apache.org/cassandra/LenoreRut New page: real estate investment grand rapids michiganBR brHow can they possibly be indifferent to your urban center that will increases quicker compared to all other locations asia?BR Buyers want to own purchase about several places which are developing swifter in addition to more rapidly. It is because the value appreciation over these parts is far better and they also reassure greater profits on the shareholders. This is actually the same goes with virtually all Properties around Pune also.BR Your shareholders will obtain excellent earnings from them purchase of Pune and there isn't any doubt with this. You can view several approaching non commercial projects as well as private plans in Pune are usually about the modern specifications as well as folks will have the capacity to direct a lifetime of convenience and comfort from the town undoubtedly. brbrBR property photographyBR brSeveral confusion occurs within the steps involved in making profits turning house. Those who focus on discovering great buy real estate, get yourself a pay for long term contract, and then sell on the agreement prior to taking name to the residence are known as Bird Most dogs. These kind of starting real estate traders get started with nothing all the way down by: Choosing a supplier within anxiety having a good deal real estate Acquiring your profits commitment Advertising their particular agreement for close to $500 so that you can $5,500 to the seasoned real estate buyer Isn't real estate flipping illegal?BR Flipping real estate isn't illegitimate. Nevertheless, quite a few unethical traders wholly commited home loan scam in making quick cash. Some of these investors, handling lenders in addition to appraisers, sold again residences to rubbish potential buyers growing the house cost and home customer's skills.BR Generally most of these dwelling expenses didn't have any revenue or even very little money down. Whenever all these new property homeowners late about the payment, the particular mortgage lenders lost income for the reason that house has not been really worth higher out the door cost. [[http://www.tunmirerealty.com/|worth homes for sale fort]] brbrBR real estate property on-lineBR brThere are numerous end-users in addition to buyers that possess some components inside city even if to merely steer an opportune and cozy living because of their confined salary. His or her income is minimal and they are certain that are going to struggle to guide a life of comfort in some other towns. Pune Property is remarkably reasonably priced as well as the property pricing is reduced in comparability for some other prime cities asia. If the Real Estate in Pune started out escalating the located standard of the people in addition acquired improved. They will meet up with his or her everyday demands in just a limited time while all of the required situations are presented in in the vicinity of location to every one homeowner. In order to be sure you have a amazing lifestyle within the metropolis therefore there's no need in order to be reluctant within switching your own home for this metropolis.BR BR brbrBR property san antonioBR brFirst, it is advisable to select a adviser who will be under legal standing authorized and also properly qualified. While there may be tons, or perhaps 1000's, associated with by law authorized agents in your community, not every one of choices appropriately skilled. As an example, reported by Boise Local mls files, there are approximately 2300 trained real estate realtors in Boise, Los angeles. Surprisingly, virtually 700 realtors (40%) did not stand for only one seller last year inside of a done transaction-and exclusively 167 (7%) displayed over 12 sellers this past year. Placed yet another way, if you only go with a real estate adviser with the telephone book when your checklist realtor, there is a 5 around Ten probability of deciding on one that didn't possibly market only one property in 2009.BR brbrBR http://lunarjespershamsterdagbok.se/link/2500 http://www.business-market.eu/index.php?do=/blog/397261/mt-enjoyable-oh-virginia-homes/ http://home-busi.essweb.com/NYF2010/index.php?option=com_blogview=commentspid=34655Itemid=0 http://www.business-market.eu/index.php?BR BR do=/blog/397591/bracket-enjoyable-home-rentals/BR http://mysexyvidz.com/index.php?do=/blog/19750/housing-ask/BR BR Also visit my web-site ... [[http://shahinshahryha.ir/index.php?do=/blog/146988/mt-pleasant-property-income/|real estate right now north carolina]]
[jira] [Updated] (CASSANDRA-5430) Make Auth.SUPERUSER_SETUP_DELAY configurable
[ https://issues.apache.org/jira/browse/CASSANDRA-5430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-5430: - Attachment: 5430-v2.txt Make Auth.SUPERUSER_SETUP_DELAY configurable Key: CASSANDRA-5430 URL: https://issues.apache.org/jira/browse/CASSANDRA-5430 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.2.2 Reporter: John Sanda Assignee: Aleksey Yeschenko Priority: Minor Labels: authentication Fix For: 1.2.4 Attachments: 5430.txt, 5430-v2.txt I would like to make SUPERUSER_SETUP_DELAY configurable for automated tests. I have tests that stand up a local cluster, and sometimes if I just run a single test class, the total execution time to stand up the (usually two) nodes and run the tests takes less than 20 seconds. I am running on fast hardware, so I can probably get by with a lower value in most cases, but maybe one of my teammates runs on slower hardware and needs a larger value. I do not see this as a problem for production use. It would just be nice to have it configurable for dev environments. 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] [Commented] (CASSANDRA-5430) Make Auth.SUPERUSER_SETUP_DELAY configurable
[ https://issues.apache.org/jira/browse/CASSANDRA-5430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13625493#comment-13625493 ] Jonathan Ellis commented on CASSANDRA-5430: --- +1 Make Auth.SUPERUSER_SETUP_DELAY configurable Key: CASSANDRA-5430 URL: https://issues.apache.org/jira/browse/CASSANDRA-5430 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.2.2 Reporter: John Sanda Assignee: Aleksey Yeschenko Priority: Minor Labels: authentication Fix For: 1.2.4 Attachments: 5430.txt, 5430-v2.txt I would like to make SUPERUSER_SETUP_DELAY configurable for automated tests. I have tests that stand up a local cluster, and sometimes if I just run a single test class, the total execution time to stand up the (usually two) nodes and run the tests takes less than 20 seconds. I am running on fast hardware, so I can probably get by with a lower value in most cases, but maybe one of my teammates runs on slower hardware and needs a larger value. I do not see this as a problem for production use. It would just be nice to have it configurable for dev environments. 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
[Cassandra Wiki] Trivial Update of JewelBeta by JewelBeta
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The JewelBeta page has been changed by JewelBeta: http://wiki.apache.org/cassandra/JewelBeta New page: There is nothing to write about me really.BR I enjoy of finally being a part of apache.org.BR BR BR I just wish I am useful in one way .BR BR Take a look at my webpage [[http://ucgi.mishima-stable.co.jp/cgi-bin/aska.cgi|please click the next page]]
git commit: Allow overriding superuser setup delay
Updated Branches:
refs/heads/cassandra-1.2 1429c54b0 - 22d107ff5
Allow overriding superuser setup delay
patch by Aleksey Yeschenko; reviewed by Jonathan Ellis for
CASSANDRA-5430
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/22d107ff
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/22d107ff
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/22d107ff
Branch: refs/heads/cassandra-1.2
Commit: 22d107ff5276658a9d2927c29e9ecc53d63b150e
Parents: 1429c54
Author: Aleksey Yeschenko alek...@apache.org
Authored: Mon Apr 8 19:16:06 2013 +0300
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Mon Apr 8 19:16:06 2013 +0300
--
CHANGES.txt|1 +
NEWS.txt |5 +
src/java/org/apache/cassandra/auth/Auth.java |8
.../cassandra/auth/PasswordAuthenticator.java | 10 --
4 files changed, 14 insertions(+), 10 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/22d107ff/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 5347f91..81d57ef 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -31,6 +31,7 @@
* Allow unauthenticated set_keyspace() calls (CASSANDRA-5423)
* Fix potential incremental backups race (CASSANDRA-5410)
* Fix prepared BATCH statements with batch-level timestamps (CASSANDRA-5415)
+ * Allow overriding superuser setup delay (CASSANDRA-5430)
Merged from 1.1:
* cli: Quote ks and cf names in schema output when needed (CASSANDRA-5052)
* Fix bad default for min/max timestamp in SSTableMetadata (CASSANDRA-5372)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/22d107ff/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index b53411b..6509d6e 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -17,6 +17,11 @@ Upgrading
on the current version (which is usually what you want). Use the new -a
flag to recover the old behavior of rewriting all sstables.
+Features
+
+- superuser setup delay (10 seconds) can now be overridden using
+ 'cassandra.superuser_setup_delay_ms' property.
+
1.2.3
=
http://git-wip-us.apache.org/repos/asf/cassandra/blob/22d107ff/src/java/org/apache/cassandra/auth/Auth.java
--
diff --git a/src/java/org/apache/cassandra/auth/Auth.java
b/src/java/org/apache/cassandra/auth/Auth.java
index d8e79ca..7ec5a33 100644
--- a/src/java/org/apache/cassandra/auth/Auth.java
+++ b/src/java/org/apache/cassandra/auth/Auth.java
@@ -43,7 +43,7 @@ public class Auth
public static final String DEFAULT_SUPERUSER_NAME = cassandra;
-private static final long SUPERUSER_SETUP_DELAY = 10; // seconds.
+public static final long SUPERUSER_SETUP_DELAY =
Long.getLong(cassandra.superuser_setup_delay_ms, 1);
public static final String AUTH_KS = system_auth;
public static final String USERS_CF = users;
@@ -148,14 +148,14 @@ public class Auth
if
(DatabaseDescriptor.getSeeds().contains(FBUtilities.getBroadcastAddress()) ||
!DatabaseDescriptor.isAutoBootstrap())
{
StorageService.tasks.schedule(new Runnable()
- {
+ {
public void run()
{
setupDefaultSuperuser();
- }
+ }
},
SUPERUSER_SETUP_DELAY,
- TimeUnit.SECONDS);
+ TimeUnit.MILLISECONDS);
}
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/22d107ff/src/java/org/apache/cassandra/auth/PasswordAuthenticator.java
--
diff --git a/src/java/org/apache/cassandra/auth/PasswordAuthenticator.java
b/src/java/org/apache/cassandra/auth/PasswordAuthenticator.java
index e6e28ae..01adb1b 100644
--- a/src/java/org/apache/cassandra/auth/PasswordAuthenticator.java
+++ b/src/java/org/apache/cassandra/auth/PasswordAuthenticator.java
@@ -48,8 +48,6 @@ public class PasswordAuthenticator implements IAuthenticator
{
private static final Logger logger =
LoggerFactory.getLogger(PasswordAuthenticator.class);
-private static final long DEFAULT_USER_SETUP_DELAY = 10; // seconds
-
// 2 ** GENSALT_LOG2_ROUNS rounds of hashing will be
[1/2] git commit: Allow overriding superuser setup delay
Updated Branches:
refs/heads/trunk 71e764cb0 - 52443c800
Allow overriding superuser setup delay
patch by Aleksey Yeschenko; reviewed by Jonathan Ellis for
CASSANDRA-5430
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/22d107ff
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/22d107ff
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/22d107ff
Branch: refs/heads/trunk
Commit: 22d107ff5276658a9d2927c29e9ecc53d63b150e
Parents: 1429c54
Author: Aleksey Yeschenko alek...@apache.org
Authored: Mon Apr 8 19:16:06 2013 +0300
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Mon Apr 8 19:16:06 2013 +0300
--
CHANGES.txt|1 +
NEWS.txt |5 +
src/java/org/apache/cassandra/auth/Auth.java |8
.../cassandra/auth/PasswordAuthenticator.java | 10 --
4 files changed, 14 insertions(+), 10 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/22d107ff/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 5347f91..81d57ef 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -31,6 +31,7 @@
* Allow unauthenticated set_keyspace() calls (CASSANDRA-5423)
* Fix potential incremental backups race (CASSANDRA-5410)
* Fix prepared BATCH statements with batch-level timestamps (CASSANDRA-5415)
+ * Allow overriding superuser setup delay (CASSANDRA-5430)
Merged from 1.1:
* cli: Quote ks and cf names in schema output when needed (CASSANDRA-5052)
* Fix bad default for min/max timestamp in SSTableMetadata (CASSANDRA-5372)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/22d107ff/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index b53411b..6509d6e 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -17,6 +17,11 @@ Upgrading
on the current version (which is usually what you want). Use the new -a
flag to recover the old behavior of rewriting all sstables.
+Features
+
+- superuser setup delay (10 seconds) can now be overridden using
+ 'cassandra.superuser_setup_delay_ms' property.
+
1.2.3
=
http://git-wip-us.apache.org/repos/asf/cassandra/blob/22d107ff/src/java/org/apache/cassandra/auth/Auth.java
--
diff --git a/src/java/org/apache/cassandra/auth/Auth.java
b/src/java/org/apache/cassandra/auth/Auth.java
index d8e79ca..7ec5a33 100644
--- a/src/java/org/apache/cassandra/auth/Auth.java
+++ b/src/java/org/apache/cassandra/auth/Auth.java
@@ -43,7 +43,7 @@ public class Auth
public static final String DEFAULT_SUPERUSER_NAME = cassandra;
-private static final long SUPERUSER_SETUP_DELAY = 10; // seconds.
+public static final long SUPERUSER_SETUP_DELAY =
Long.getLong(cassandra.superuser_setup_delay_ms, 1);
public static final String AUTH_KS = system_auth;
public static final String USERS_CF = users;
@@ -148,14 +148,14 @@ public class Auth
if
(DatabaseDescriptor.getSeeds().contains(FBUtilities.getBroadcastAddress()) ||
!DatabaseDescriptor.isAutoBootstrap())
{
StorageService.tasks.schedule(new Runnable()
- {
+ {
public void run()
{
setupDefaultSuperuser();
- }
+ }
},
SUPERUSER_SETUP_DELAY,
- TimeUnit.SECONDS);
+ TimeUnit.MILLISECONDS);
}
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/22d107ff/src/java/org/apache/cassandra/auth/PasswordAuthenticator.java
--
diff --git a/src/java/org/apache/cassandra/auth/PasswordAuthenticator.java
b/src/java/org/apache/cassandra/auth/PasswordAuthenticator.java
index e6e28ae..01adb1b 100644
--- a/src/java/org/apache/cassandra/auth/PasswordAuthenticator.java
+++ b/src/java/org/apache/cassandra/auth/PasswordAuthenticator.java
@@ -48,8 +48,6 @@ public class PasswordAuthenticator implements IAuthenticator
{
private static final Logger logger =
LoggerFactory.getLogger(PasswordAuthenticator.class);
-private static final long DEFAULT_USER_SETUP_DELAY = 10; // seconds
-
// 2 ** GENSALT_LOG2_ROUNS rounds of hashing will be performed.
private
[2/2] 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/52443c80 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/52443c80 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/52443c80 Branch: refs/heads/trunk Commit: 52443c8006b0d98a28e26a63bc977e0c51a45520 Parents: 71e764c 22d107f Author: Aleksey Yeschenko alek...@apache.org Authored: Mon Apr 8 19:17:47 2013 +0300 Committer: Aleksey Yeschenko alek...@apache.org Committed: Mon Apr 8 19:17:47 2013 +0300 -- CHANGES.txt|1 + NEWS.txt |5 + src/java/org/apache/cassandra/auth/Auth.java |8 .../cassandra/auth/PasswordAuthenticator.java | 10 -- 4 files changed, 14 insertions(+), 10 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/52443c80/CHANGES.txt -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/52443c80/NEWS.txt --
[jira] [Updated] (CASSANDRA-5431) cassandra-shuffle with JMX usernames and passwords
[ https://issues.apache.org/jira/browse/CASSANDRA-5431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michał Michalski updated CASSANDRA-5431: Attachment: 5431-v2.txt Yup, I have it (updated to make it apply on your whitespace patch). cassandra-shuffle with JMX usernames and passwords --- Key: CASSANDRA-5431 URL: https://issues.apache.org/jira/browse/CASSANDRA-5431 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.3 Reporter: Eric Dong Attachments: 5431-v2.txt, CASSANDRA-5431-whitespace.patch Unlike nodetool, cassandra-shuffle doesn't allow passing in a JMX username and password. This stops those who want to switch to vnodes from doing so if JMX access requires a username and a password. Patch to 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-4885) Remove or rework per-row bloom filters
[ https://issues.apache.org/jira/browse/CASSANDRA-4885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13625514#comment-13625514 ] Jason Brown commented on CASSANDRA-4885: CASSANDRA-5385 resolved this guy, as well. Remove or rework per-row bloom filters -- Key: CASSANDRA-4885 URL: https://issues.apache.org/jira/browse/CASSANDRA-4885 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Assignee: Jason Brown Fix For: 2.0 Attachments: 0001-CASSANRDA-4885-Remove-per-row-bloom-filter.patch, 0002-CASSANRDA-4885-update-test.patch, 4885-v1.patch, 4885-v2.patch Per-row bloom filters may be a misfeature. On small rows we don't create them. On large rows we essentially only do slice queries that can't take advantage of it. And on very large rows if we ever did deserialize it, the performance hit of doing so would outweigh the benefit of skipping the actual read. -- 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-4885) Remove or rework per-row bloom filters
[ https://issues.apache.org/jira/browse/CASSANDRA-4885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Brown resolved CASSANDRA-4885. Resolution: Fixed Remove or rework per-row bloom filters -- Key: CASSANDRA-4885 URL: https://issues.apache.org/jira/browse/CASSANDRA-4885 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Assignee: Jason Brown Fix For: 2.0 Attachments: 0001-CASSANRDA-4885-Remove-per-row-bloom-filter.patch, 0002-CASSANRDA-4885-update-test.patch, 4885-v1.patch, 4885-v2.patch Per-row bloom filters may be a misfeature. On small rows we don't create them. On large rows we essentially only do slice queries that can't take advantage of it. And on very large rows if we ever did deserialize it, the performance hit of doing so would outweigh the benefit of skipping the actual read. -- 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-5062) Support CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13625529#comment-13625529 ] Sylvain Lebresne commented on CASSANDRA-5062: - A few other remarks on v3: * In SP.cas(), after having read the CASed values, I don't think Objects.equals() will work because of the timestamps. Which makes me remark that in theory having the API take a ColumnFamily as 'expected' is slightly weird because we will ignore the timestamps (I don't suppose the intent was to take them into account). Not a huge big deal (and not one we'll have on the CQL side), so probably not worth complicating said API, but may be worth a comment. * Also, the timestamp of the columns we write during the commit should be the ballot timestamp. I don't see it done by the patch. * SystemTable.savePaxosCommit doesn't seem to delete in_progress_ballot (it deletes 'proposal' only). * In SystemTable.loadPaxosState, we must be careful that UntypedResultSet.Row doesn't handle null well (and Row.fromBytes doesn't either). * It's more of a nit, but I think there is a bunch of places where we could reuse the new Commit class. In particular, ProposeRequest is kind of a duplicate. But there is a few other places too (the propose and commit method in PaxosState could take a Commit directly, in PrepareCallback, the inProgress ballot and update could be grouped, ...). * Also, the paxos state CF basically holds 2 pairs of ballot/update, the in_progress ones and the MRC ones. Could be nice to name them to reflect that symetry (something like in_progress_ballot/in_progress_upd/most_recent_commit_ballot/most_recent_commit_upd)? * The patch has minors updates to the cassandra.in.sh file that should probably be reverted. For the record, I'm not a fan of having PaxosState share buckets (versus directly reading the SystemTable). I kind of understand the reasoning of keeping things in memory, but I can't stop to think that it's premature optimisation (that creates artificial contention and make the code slightly harder to reason about imo). Anyway, as far as I can tell it's not incorrect, but I'm not totally sold on it. Also, I think we're lacking something around reads and around CL.SERIAL. I think we at least need to support CL.SERIAL reads, that would have to go through paxos (so they play inProgress values). But I would a relatively big fan to also allow a (non-SERIAL) CL in cas() that would be applied to the final commit of the cas write. That way, if you have a successful cas call at CL.QUORUM, you can do a normal QUORUM read and be guaranteed to see your value, which is nice (of course, if the cas write actually timeout, you'd have to do a SERIAL read to check the up to date state, but at least in the normal non-failing case you don't need SERIAL reads). Support CAS --- Key: CASSANDRA-5062 URL: https://issues.apache.org/jira/browse/CASSANDRA-5062 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Jonathan Ellis Fix For: 2.0 Attachments: half-baked commit 1.jpg, half-baked commit 2.jpg, half-baked commit 3.jpg Strong consistency is not enough to prevent race conditions. The classic example is user account creation: we want to ensure usernames are unique, so we only want to signal account creation success if nobody else has created the account yet. But naive read-then-write allows clients to race and both think they have a green light to create. -- 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: Change version for 1.2.4 release
Updated Branches: refs/heads/cassandra-1.2 22d107ff5 - 2e96d0711 Change version for 1.2.4 release Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/2e96d071 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/2e96d071 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/2e96d071 Branch: refs/heads/cassandra-1.2 Commit: 2e96d07114dc88f85e56d88f7322a6b91da36c0d Parents: 22d107f Author: Sylvain Lebresne sylv...@datastax.com Authored: Mon Apr 8 18:55:06 2013 +0200 Committer: Sylvain Lebresne sylv...@datastax.com Committed: Mon Apr 8 18:55:06 2013 +0200 -- build.xml|2 +- debian/changelog |6 ++ 2 files changed, 7 insertions(+), 1 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/2e96d071/build.xml -- diff --git a/build.xml b/build.xml index a57d669..3491431 100644 --- a/build.xml +++ b/build.xml @@ -25,7 +25,7 @@ property name=debuglevel value=source,lines,vars/ !-- default version and SCM information -- -property name=base.version value=1.2.3/ +property name=base.version value=1.2.4/ property name=scm.connection value=scm:git://git.apache.org/cassandra.git/ property name=scm.developerConnection value=scm:git://git.apache.org/cassandra.git/ property name=scm.url value=http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=tree/ http://git-wip-us.apache.org/repos/asf/cassandra/blob/2e96d071/debian/changelog -- diff --git a/debian/changelog b/debian/changelog index e0bc2a7..c8a62fa 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +cassandra (1.2.4) unstable; urgency=low + + * New release + + -- Sylvain Lebresne slebre...@apache.org Mon, 08 Apr 2013 18:52:23 +0200 + cassandra (1.2.3) unstable; urgency=low * New release
Git Push Summary
Updated Tags: refs/tags/1.2.4-tentative [created] 2e96d0711
[jira] [Commented] (CASSANDRA-5431) cassandra-shuffle with JMX usernames and passwords
[ https://issues.apache.org/jira/browse/CASSANDRA-5431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13625607#comment-13625607 ] Eric Dong commented on CASSANDRA-5431: -- Hi Michał, Thanks for the information--- I have not started work on this, so please feel free to submit your patch! cassandra-shuffle with JMX usernames and passwords --- Key: CASSANDRA-5431 URL: https://issues.apache.org/jira/browse/CASSANDRA-5431 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.3 Reporter: Eric Dong Attachments: 5431-v2.txt, CASSANDRA-5431-whitespace.patch Unlike nodetool, cassandra-shuffle doesn't allow passing in a JMX username and password. This stops those who want to switch to vnodes from doing so if JMX access requires a username and a password. Patch to 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
[2/2] git commit: r/m unused SimpleFuture
r/m unused SimpleFuture
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/220a828b
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/220a828b
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/220a828b
Branch: refs/heads/trunk
Commit: 220a828b7045c1e178d23bc6820b15e7725598d1
Parents: 75d5639
Author: Jonathan Ellis jbel...@apache.org
Authored: Mon Apr 8 13:20:11 2013 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Mon Apr 8 13:20:11 2013 -0500
--
.../cassandra/db/compaction/CompactionManager.java | 37 ---
1 files changed, 0 insertions(+), 37 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/220a828b/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
--
diff --git a/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
b/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
index 4b5ebbe..21bbb8e 100644
--- a/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
+++ b/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
@@ -864,43 +864,6 @@ public class CompactionManager implements
CompactionManagerMBean
return metrics.completedTasks.value();
}
-private static class SimpleFuture implements Future
-{
-private Runnable runnable;
-
-private SimpleFuture(Runnable r)
-{
-runnable = r;
-}
-
-public boolean cancel(boolean mayInterruptIfRunning)
-{
-throw new IllegalStateException(May not call
SimpleFuture.cancel());
-}
-
-public boolean isCancelled()
-{
-return false;
-}
-
-public boolean isDone()
-{
-return runnable == null;
-}
-
-public Object get() throws InterruptedException, ExecutionException
-{
-runnable.run();
-runnable = null;
-return runnable;
-}
-
-public Object get(long timeout, TimeUnit unit) throws
InterruptedException, ExecutionException, TimeoutException
-{
-throw new IllegalStateException(May not call
SimpleFuture.get(long, TimeUnit));
-}
-}
-
private static class CleanupInfo extends CompactionInfo.Holder
{
private final SSTableReader sstable;
[1/2] git commit: Leveled compaction performs size-tiered compactions in L0 patch by tjake and jbellis for CASSANDRA-5371
Updated Branches:
refs/heads/trunk 52443c800 - 220a828b7
Leveled compaction performs size-tiered compactions in L0
patch by tjake and jbellis for CASSANDRA-5371
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/75d56390
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/75d56390
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/75d56390
Branch: refs/heads/trunk
Commit: 75d5639014a4680f2a734b4ec9b452ed0cfff058
Parents: 52443c8
Author: Jonathan Ellis jbel...@apache.org
Authored: Mon Apr 8 13:19:40 2013 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Mon Apr 8 13:19:40 2013 -0500
--
CHANGES.txt|1 +
.../org/apache/cassandra/db/ColumnFamilyStore.java | 21 -
src/java/org/apache/cassandra/db/DataTracker.java | 13 +++
.../db/compaction/AbstractCompactionStrategy.java | 23 ++---
.../cassandra/db/compaction/CompactionManager.java | 26 ++
.../cassandra/db/compaction/CompactionTask.java| 18 -
.../db/compaction/LeveledCompactionStrategy.java | 23 +++--
.../db/compaction/LeveledCompactionTask.java |9 ++-
.../cassandra/db/compaction/LeveledManifest.java | 64 +-
.../apache/cassandra/db/compaction/Scrubber.java |4 +-
.../compaction/SizeTieredCompactionStrategy.java | 48 ++-
.../cassandra/io/sstable/SSTableMetadata.java | 21 +
.../apache/cassandra/io/sstable/SSTableReader.java | 28 +--
.../SizeTieredCompactionStrategyTest.java | 23 ++
14 files changed, 188 insertions(+), 134 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/75d56390/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 8ecabd6..5c9bbd4 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.0
+ * Leveled compaction performs size-tiered compactions in L0 (CASSANDRA-5371)
* Add yaml network topology snitch for mixed ec2/other envs (CASSANDRA-5339)
* Log when a node is down longer than the hint window (CASSANDRA-4554)
* Optimize tombstone creation for ExpiringColumns (CASSANDRA-4917)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/75d56390/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
--
diff --git a/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
b/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
index 0c4a4ea..fe6dca0 100644
--- a/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
+++ b/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
@@ -2079,27 +2079,6 @@ public class ColumnFamilyStore implements
ColumnFamilyStoreMBean
return intern(name);
}
-public SSTableWriter createCompactionWriter(OperationType operationType,
long estimatedRows, File location, CollectionSSTableReader sstables)
-{
-ReplayPosition rp = ReplayPosition.getReplayPosition(sstables);
-SSTableMetadata.Collector sstableMetadataCollector =
SSTableMetadata.createCollector().replayPosition(rp);
-
sstableMetadataCollector.sstableLevel(compactionStrategy.getNextLevel(sstables,
operationType));
-
-// Get the max timestamp of the precompacted sstables
-// and adds generation of live ancestors
-for (SSTableReader sstable : sstables)
-{
-
sstableMetadataCollector.addAncestor(sstable.descriptor.generation);
-for (Integer i : sstable.getAncestors())
-{
-if (new
File(sstable.descriptor.withGeneration(i).filenameFor(Component.DATA)).exists())
-sstableMetadataCollector.addAncestor(i);
-}
-}
-
-return new SSTableWriter(getTempSSTablePath(location), estimatedRows,
metadata, partitioner, sstableMetadataCollector);
-}
-
public IterableColumnFamilyStore concatWithIndexes()
{
return Iterables.concat(indexManager.getIndexesBackedByCfs(),
Collections.singleton(this));
http://git-wip-us.apache.org/repos/asf/cassandra/blob/75d56390/src/java/org/apache/cassandra/db/DataTracker.java
--
diff --git a/src/java/org/apache/cassandra/db/DataTracker.java
b/src/java/org/apache/cassandra/db/DataTracker.java
index f206973..8cc78b4 100644
--- a/src/java/org/apache/cassandra/db/DataTracker.java
+++ b/src/java/org/apache/cassandra/db/DataTracker.java
@@ -22,6 +22,7 @@ import java.util.*;
import java.util.concurrent.CopyOnWriteArrayList;
import java.util.concurrent.atomic.AtomicReference;
+import com.google.common.base.Predicate;
import com.google.common.collect.*;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
[jira] [Created] (CASSANDRA-5439) allow STCS options to apply to the L0 compaction performed by LCS
Jonathan Ellis created CASSANDRA-5439: - Summary: allow STCS options to apply to the L0 compaction performed by LCS Key: CASSANDRA-5439 URL: https://issues.apache.org/jira/browse/CASSANDRA-5439 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 2.0 Reporter: Jonathan Ellis Assignee: Carl Yeksigian Priority: Minor Fix For: 2.0 (See CASSANDRA-5371) -- 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-5371) Perform size-tiered compactions in L0
[ https://issues.apache.org/jira/browse/CASSANDRA-5371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-5371. --- Resolution: Fixed All right. Rebased and committed, and created CASSANDRA-5439 for the options application. Perform size-tiered compactions in L0 - Key: CASSANDRA-5371 URL: https://issues.apache.org/jira/browse/CASSANDRA-5371 Project: Cassandra Issue Type: Bug Components: Core Reporter: Jonathan Ellis Assignee: Jonathan Ellis Fix For: 2.0 Attachments: HybridCompactionStrategy.java If LCS gets behind, read performance deteriorates as we have to check bloom filters on man sstables in L0. For wide rows, this can mean having to seek for each one since the BF doesn't help us reject much. Performing size-tiered compaction in L0 will mitigate this until we can catch up on merging it into higher levels. -- 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: fix build post-rebase
Updated Branches:
refs/heads/trunk 220a828b7 - 4902bdc7b
fix build post-rebase
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/4902bdc7
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/4902bdc7
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/4902bdc7
Branch: refs/heads/trunk
Commit: 4902bdc7b97d8f514724ebf1ccb2598f8e69d64d
Parents: 220a828
Author: Jonathan Ellis jbel...@apache.org
Authored: Mon Apr 8 13:36:04 2013 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Mon Apr 8 13:36:04 2013 -0500
--
.../org/apache/cassandra/db/ColumnFamilyStore.java | 10 +-
src/java/org/apache/cassandra/db/DataTracker.java | 10 +-
.../db/compaction/AbstractCompactionTask.java |9 -
.../cassandra/db/compaction/CompactionManager.java | 14 +++---
.../cassandra/db/compaction/CompactionTask.java|4 ++--
.../compaction/SizeTieredCompactionStrategy.java |2 +-
6 files changed, 24 insertions(+), 25 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4902bdc7/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
--
diff --git a/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
b/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
index fe6dca0..516fcd6 100644
--- a/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
+++ b/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
@@ -1894,15 +1894,15 @@ public class ColumnFamilyStore implements
ColumnFamilyStoreMBean
}
}
-public CollectionSSTableReader markAllCompacting()
+public IterableSSTableReader markAllCompacting()
{
-CallableCollectionSSTableReader callable = new
CallableCollectionSSTableReader()
+CallableIterableSSTableReader callable = new
CallableIterableSSTableReader()
{
-public CollectionSSTableReader call() throws Exception
+public IterableSSTableReader call() throws Exception
{
assert data.getCompacting().isEmpty() : data.getCompacting();
-CollectionSSTableReader sstables =
AbstractCompactionStrategy.filterSuspectSSTables(getSSTables());
-if (sstables.isEmpty())
+IterableSSTableReader sstables =
AbstractCompactionStrategy.filterSuspectSSTables(getSSTables());
+if (Iterables.isEmpty(sstables))
return null;
boolean success = data.markCompacting(sstables);
assert success : something marked things compacting while
compactions are disabled;
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4902bdc7/src/java/org/apache/cassandra/db/DataTracker.java
--
diff --git a/src/java/org/apache/cassandra/db/DataTracker.java
b/src/java/org/apache/cassandra/db/DataTracker.java
index 8cc78b4..27c0480 100644
--- a/src/java/org/apache/cassandra/db/DataTracker.java
+++ b/src/java/org/apache/cassandra/db/DataTracker.java
@@ -186,13 +186,13 @@ public class DataTracker
* unmarkCompacting, but since we will never call markCompacted on a
sstable marked
* as compacting (unless there is a serious bug), we can skip this.
*/
-public boolean markCompacting(CollectionSSTableReader sstables)
+public boolean markCompacting(IterableSSTableReader sstables)
{
-assert sstables != null !sstables.isEmpty();
+assert sstables != null !Iterables.isEmpty(sstables);
View currentView = view.get();
SetSSTableReader inactive =
Sets.difference(ImmutableSet.copyOf(sstables), currentView.compacting);
-if (inactive.size() sstables.size())
+if (inactive.size() Iterables.size(sstables))
return false;
View newView = currentView.markCompacting(inactive);
@@ -203,7 +203,7 @@ public class DataTracker
* Removes files from compacting status: this is different from
'markCompacted'
* because it should be run regardless of whether a compaction succeeded.
*/
-public void unmarkCompacting(CollectionSSTableReader unmark)
+public void unmarkCompacting(IterableSSTableReader unmark)
{
if (!cfstore.isValid())
{
@@ -533,7 +533,7 @@ public class DataTracker
return new View(memtable, memtablesPendingFlush, sstables,
compactingNew, intervalTree);
}
-public View unmarkCompacting(CollectionSSTableReader tounmark)
+public View unmarkCompacting(IterableSSTableReader tounmark)
{
SetSSTableReader compactingNew =
ImmutableSet.copyOf(Sets.difference(compacting, ImmutableSet.copyOf(tounmark)));
buildbot failure in ASF Buildbot on cassandra-trunk
The Buildbot has detected a new failure on builder cassandra-trunk while building cassandra. Full details are available at: http://ci.apache.org/builders/cassandra-trunk/builds/2541 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: portunus_ubuntu Build Reason: scheduler Build Source Stamp: [branch trunk] 220a828b7045c1e178d23bc6820b15e7725598d1 Blamelist: Jonathan Ellis jbel...@apache.org BUILD FAILED: failed sincerely, -The Buildbot
[jira] [Commented] (CASSANDRA-4932) Agree on a gcbefore/expirebefore value for all replica during validation compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-4932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13625659#comment-13625659 ] Yuki Morishita commented on CASSANDRA-4932: --- Overall, it looks good. Is it better to calculate gc_before just before sending TreeRequest rather than doing it in RepairJob constructor? RepairJobs for all given CFs are created at once, but those are executed one by one. Agree on a gcbefore/expirebefore value for all replica during validation compaction Key: CASSANDRA-4932 URL: https://issues.apache.org/jira/browse/CASSANDRA-4932 Project: Cassandra Issue Type: Improvement Reporter: Sylvain Lebresne Assignee: Marcus Eriksson Priority: Minor Fix For: 2.0 Attachments: 0001-CASSANDRA-4932.patch CASSANDRA-4905 made it so that we don't include gcable tombstones in merkle tree digests because otherwise the fact that a gcable tombstone exists in a given node depends on the local scheduling of compactions, which make the merkle-tree digets depends on that which is bad. However, we still depends on a value of gcbefore/expirebefore that is computed locally on the node. This is not a huge deal because each node should compute those value roughly at the same time so the discrepancies shouldn't exceed a few hundreds of milliseconds in general and a few seconds if we're unlucky. Still, it's fairly easy to fix this problem by having the repair coordinator pick the gcbefore/expirebefore and share that with all the replica. It does require sending that info on the wire though, so will require a new messaging version and thus can only be done in a major cycle. -- 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] [Comment Edited] (CASSANDRA-4932) Agree on a gcbefore/expirebefore value for all replica during validation compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-4932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13625659#comment-13625659 ] Yuki Morishita edited comment on CASSANDRA-4932 at 4/8/13 6:49 PM: --- Overall, it looks good. But is it better to calculate gc_before just before sending TreeRequest rather than doing it in RepairJob constructor? RepairJobs for all given CFs are created at once, but those are executed one by one. was (Author: yukim): Overall, it looks good. Is it better to calculate gc_before just before sending TreeRequest rather than doing it in RepairJob constructor? RepairJobs for all given CFs are created at once, but those are executed one by one. Agree on a gcbefore/expirebefore value for all replica during validation compaction Key: CASSANDRA-4932 URL: https://issues.apache.org/jira/browse/CASSANDRA-4932 Project: Cassandra Issue Type: Improvement Reporter: Sylvain Lebresne Assignee: Marcus Eriksson Priority: Minor Fix For: 2.0 Attachments: 0001-CASSANDRA-4932.patch CASSANDRA-4905 made it so that we don't include gcable tombstones in merkle tree digests because otherwise the fact that a gcable tombstone exists in a given node depends on the local scheduling of compactions, which make the merkle-tree digets depends on that which is bad. However, we still depends on a value of gcbefore/expirebefore that is computed locally on the node. This is not a huge deal because each node should compute those value roughly at the same time so the discrepancies shouldn't exceed a few hundreds of milliseconds in general and a few seconds if we're unlucky. Still, it's fairly easy to fix this problem by having the repair coordinator pick the gcbefore/expirebefore and share that with all the replica. It does require sending that info on the wire though, so will require a new messaging version and thus can only be done in a major cycle. -- 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-5433) Nodetool - Human Readable
[ https://issues.apache.org/jira/browse/CASSANDRA-5433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13625696#comment-13625696 ] Brandon Williams commented on CASSANDRA-5433: - I don't think this is unreasonable, but if we're going to do it, we should do it all the way -- not just compactionstats, but cfstats, etc. Nodetool - Human Readable - Key: CASSANDRA-5433 URL: https://issues.apache.org/jira/browse/CASSANDRA-5433 Project: Cassandra Issue Type: Improvement Reporter: Brooke Bryan Priority: Trivial Attachments: humanreadablecompactionstats.patch Would be great to have a human readable option in nodetool to easily look stats without having to convert bytes to MB/GB etc in your head :) We have several internal scripts we use to parse the output to a more readable output, and would be useful for it to be part of nodetool itself. -- 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
[Cassandra Wiki] Trivial Update of WillieSch by WillieSch
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The WillieSch page has been changed by WillieSch: http://wiki.apache.org/cassandra/WillieSch New page: My name is Rachael Mcclelland. I life in Hegi (Switzerland).BR BR BR my blog; [[http://www.gamermates.de//index.php//index.php//index.php/index.php?page=UseruserID=3451|http://www.gamermates.de/]]
[jira] [Commented] (CASSANDRA-5437) multiget specific key filtering
[ https://issues.apache.org/jira/browse/CASSANDRA-5437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13625699#comment-13625699 ] Brandon Williams commented on CASSANDRA-5437: - There is a third option, and it's the best: perform gets and parallelize them yourself. Here's why: if you perform a multiget on [x,y,z] keys and x and y are fine, but z times out, all you get is an exception. If you had done parallel gets yourself, you'd have gotten x and y, then retried z, but since you used multiget now you have to retry the entire query again. That said, I don't think we have any plans to change or improve the thrift interface at this point. multiget specific key filtering --- Key: CASSANDRA-5437 URL: https://issues.apache.org/jira/browse/CASSANDRA-5437 Project: Cassandra Issue Type: Improvement Reporter: Brooke Bryan Priority: Minor Currently, you are able to specify a list of columns, or a slice when pulling back keys from a multiget, however, we find ourselves pulling back a lot more data than we actually need when columns overlap. We currently have 2 options (as far as im aware). 1. perform multiple get calls, and get the required data back, but connect to thrift more 2. perform a multiget, and get more data due to column crossovers, but in a single request. Similar to a batch mutation, a batch read would solve this problem perfectly. e.g. read = [ 'columnFamily' = [ 'key' = ColumnPath, 'key2' = SlicePredicate, 'key3' = ColumnPath ] ]; result = batch_read(read); //result 'columnFamily' = [ 'key' = [1 = 'a',2 = 'b',3 = 'c'], 'key2' = [4 = 'd',5 = 'e'], 'key3' = [1 = 'a',3 = 'c'] ] -- 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-4932) Agree on a gcbefore/expirebefore value for all replica during validation compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-4932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-4932: --- Attachment: 0001-CASSANDRA-4932-v2.patch v2 moves gcBefore calculation to just before sending out tree requests Agree on a gcbefore/expirebefore value for all replica during validation compaction Key: CASSANDRA-4932 URL: https://issues.apache.org/jira/browse/CASSANDRA-4932 Project: Cassandra Issue Type: Improvement Reporter: Sylvain Lebresne Assignee: Marcus Eriksson Priority: Minor Fix For: 2.0 Attachments: 0001-CASSANDRA-4932.patch, 0001-CASSANDRA-4932-v2.patch CASSANDRA-4905 made it so that we don't include gcable tombstones in merkle tree digests because otherwise the fact that a gcable tombstone exists in a given node depends on the local scheduling of compactions, which make the merkle-tree digets depends on that which is bad. However, we still depends on a value of gcbefore/expirebefore that is computed locally on the node. This is not a huge deal because each node should compute those value roughly at the same time so the discrepancies shouldn't exceed a few hundreds of milliseconds in general and a few seconds if we're unlucky. Still, it's fairly easy to fix this problem by having the repair coordinator pick the gcbefore/expirebefore and share that with all the replica. It does require sending that info on the wire though, so will require a new messaging version and thus can only be done in a major cycle. -- 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-5431) cassandra-shuffle with JMX usernames and passwords
[ https://issues.apache.org/jira/browse/CASSANDRA-5431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michał Michalski updated CASSANDRA-5431: Attachment: 5431-v3.txt OK. Attaching merged patch. cassandra-shuffle with JMX usernames and passwords --- Key: CASSANDRA-5431 URL: https://issues.apache.org/jira/browse/CASSANDRA-5431 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.3 Reporter: Eric Dong Attachments: 5431-v2.txt, 5431-v3.txt, CASSANDRA-5431-whitespace.patch Unlike nodetool, cassandra-shuffle doesn't allow passing in a JMX username and password. This stops those who want to switch to vnodes from doing so if JMX access requires a username and a password. Patch to 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] [Updated] (CASSANDRA-5436) Binary protocol versioning
[ https://issues.apache.org/jira/browse/CASSANDRA-5436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-5436: --- Attachment: 0001-CASSANDRA-5436.patch adds basic versioning * adds version parameter to decode to be able to read an old message * sets a version on the incoming message, to be able to serialize for an old client. version on message defaults to CURRENT_VERSION Binary protocol versioning -- Key: CASSANDRA-5436 URL: https://issues.apache.org/jira/browse/CASSANDRA-5436 Project: Cassandra Issue Type: Improvement Reporter: Marcus Eriksson Attachments: 0001-CASSANDRA-5436.patch There should be a way to version the binary protocol, CASSANDRA-5349 adds a message that breaks compatibility (QueryMessage) and the ticket half-handles versioning - it allows old clients to connect and execute queries (by always replying in the same version as the message sent by the client), it does not allow new clients to connect to old servers though. -- 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
[Cassandra Wiki] Trivial Update of EYXNina by EYXNina
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The EYXNina page has been changed by EYXNina: http://wiki.apache.org/cassandra/EYXNina New page: Nothing to tell about me I think.BR Lovely to be a member of this community.BR I really wish Im useful in some way .BR BR Here is my website: [[http://lib.ybust.edu.cn/?document_srl=736mid=sub06_01sort_index=regdateorder_type=desc|Learn Additional]]
[jira] [Commented] (CASSANDRA-5436) Binary protocol versioning
[ https://issues.apache.org/jira/browse/CASSANDRA-5436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13625816#comment-13625816 ] Marcus Eriksson commented on CASSANDRA-5436: i think we could allow new clients to talk to old servers by letting the server tell the client what version it is. Now the client sends a StartupMessage, and if that has the wrong version, we just disconnect, would perhaps be nice if the server ignored this version if it is higher than what it supports and replies with a Ready/Authenticate-message with CURRENT_VERSION, just to allow clients to adapt for the rest of the communication. Might be adding a bunch of unnecessary complexity though Binary protocol versioning -- Key: CASSANDRA-5436 URL: https://issues.apache.org/jira/browse/CASSANDRA-5436 Project: Cassandra Issue Type: Improvement Reporter: Marcus Eriksson Attachments: 0001-CASSANDRA-5436.patch There should be a way to version the binary protocol, CASSANDRA-5349 adds a message that breaks compatibility (QueryMessage) and the ticket half-handles versioning - it allows old clients to connect and execute queries (by always replying in the same version as the message sent by the client), it does not allow new clients to connect to old servers though. -- 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-5431) cassandra-shuffle with JMX usernames and passwords
[ https://issues.apache.org/jira/browse/CASSANDRA-5431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-5431: -- Reviewer: dbrosius cassandra-shuffle with JMX usernames and passwords --- Key: CASSANDRA-5431 URL: https://issues.apache.org/jira/browse/CASSANDRA-5431 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.3 Reporter: Eric Dong Assignee: Michał Michalski Attachments: 5431-v2.txt, 5431-v3.txt, CASSANDRA-5431-whitespace.patch Unlike nodetool, cassandra-shuffle doesn't allow passing in a JMX username and password. This stops those who want to switch to vnodes from doing so if JMX access requires a username and a password. Patch to 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-3533) TimeoutException when there is a firewall issue.
[ https://issues.apache.org/jira/browse/CASSANDRA-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13625848#comment-13625848 ] Jonathan Ellis commented on CASSANDRA-3533: --- I'm fine with empty message payload; WriteResponse for instance does that (in 1.2+) and it works fine. But I'm not actually sure how this fixes the assertion error -- where would the null EchoMessage come from? Even the v1 serialize does not return null. TimeoutException when there is a firewall issue. Key: CASSANDRA-3533 URL: https://issues.apache.org/jira/browse/CASSANDRA-3533 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Vijay Assignee: Vijay Priority: Minor Fix For: 2.0 Attachments: 0001-3533-v2.patch, 0001-CASSANDRA-3533.patch, 3533.txt When one node in the cluster is not able to talk to the other DC/RAC due to firewall or network related issue (StorageProxy calls fail), and the nodes are NOT marked down because at least one node in the cluster can talk to the other DC/RAC, we get timeoutException instead of throwing a unavailableException. The problem with this: 1) It is hard to monitor/identify these errors. 2) It is hard to diffrentiate from the client if the node being bad vs a bad query. 3) when this issue happens we have to wait for at-least the RPC timeout time to know that the query wont succeed. Possible Solution: when marking a node down we might want to check if the node is actually alive by trying to communicate to it? So we can be sure that the node is actually alive. -- 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-5427) CustomTThreadPoolServer.java (line 210) Error occurred during processing of message.
[ https://issues.apache.org/jira/browse/CASSANDRA-5427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13625852#comment-13625852 ] J.B. Langston commented on CASSANDRA-5427: -- This bug is specific to DSE 3.0 and is not present in Apache Cassandra. The DSE bug number is DSP-1662. This error is known to occur when using Hector. The error is benign and will be fixed in 3.0.1. Until then, you can silence the error by adding the following line to your log4j-server.properties: log4j.logger.org.apache.cassandra.thrift.CustomTThreadPoolServer=FATAL Here is the developer's explanation: The root cause is a bug in TPreviewableTransport causing the previewing of the stream to be not fully transparent to the transports higher in the transport stack. The negotiating transport needs to preview a first few bytes of the content that the client sends to the server, in order to detect the transport negotiation header. In case the client does not want to do any protocol negotiation, like Hector, or some monitoring tools, the negotiating layer should be invisible and pass data to/from the higher levels transparently. Actually it almost does so. The only problem happens when while previewing it reaches the end of the stream. If EOF is reached, it throws an exception instead of just silently ignoring and letting the higher level to decide. This is harmless, because the stream is closed by the client, and the higher level transport would close the server-end of the stream anyway, just without logging any exceptions. CustomTThreadPoolServer.java (line 210) Error occurred during processing of message. Key: CASSANDRA-5427 URL: https://issues.apache.org/jira/browse/CASSANDRA-5427 Project: Cassandra Issue Type: Bug Components: Config, Core Affects Versions: 1.1.9 Environment: DSE 3.0, Hector Client 1.1-2, Cassandra 1.1.9, Linux 64 bit, Heap 4 GB, Total RAM 8 GB, 2 Core (its a test environment). Reporter: Tushar Agrawal We are getting lot of following errors. We tried to change the thrift_framed_transport_size_in_mb and thrift_max_message_length_in_mb to 30 and 32 respectively without any success. Our message size is about 20 KB and we even tried to reduce it to 10 KB. We have 27 fixed columns and no secondary indexes. ERROR [Thrift:110] 2013-04-04 19:11:40,882 CustomTThreadPoolServer.java (line 210) Error occurred during processing of message. java.lang.RuntimeException: Failed to open server transport. at com.datastax.bdp.transport.server.TNegotiatingServerTransport$Factory.getTransport(TNegotiatingServerTransport.java:285) at com.datastax.bdp.transport.server.TNegotiatingServerTransport$Factory.getTransport(TNegotiatingServerTransport.java:257) at org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:184) 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) Caused by: org.apache.thrift.transport.TTransportException: java.net.SocketException: Connection reset at org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.java:129) at com.datastax.bdp.transport.server.TPreviewableTransport.read(TPreviewableTransport.java:88) at org.apache.thrift.transport.TTransport.readAll(TTransport.java:84) at com.datastax.bdp.transport.server.TPreviewableTransport.preview(TPreviewableTransport.java:44) at com.datastax.bdp.transport.server.TNegotiatingServerTransport.open(TNegotiatingServerTransport.java:169) at com.datastax.bdp.transport.server.TNegotiatingServerTransport$Factory.getTransport(TNegotiatingServerTransport.java:278) ... 5 more Caused by: java.net.SocketException: Connection reset at java.net.SocketInputStream.read(Unknown Source) at java.io.BufferedInputStream.fill(Unknown Source) at java.io.BufferedInputStream.read1(Unknown Source) at java.io.BufferedInputStream.read(Unknown Source) at org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.java:127) ... 10 more -- 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] [Comment Edited] (CASSANDRA-5427) CustomTThreadPoolServer.java (line 210) Error occurred during processing of message.
[ https://issues.apache.org/jira/browse/CASSANDRA-5427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13625852#comment-13625852 ] J.B. Langston edited comment on CASSANDRA-5427 at 4/8/13 9:33 PM: -- This bug is specific to DSE 3.0 and is not present in Apache Cassandra. The DSE bug number is DSP-1662. This error is known to occur when using Hector and also if a monitoring agent connects to the thrift port to see if it is alive. The error is benign and will be fixed in 3.0.1. Until then, you can silence the error by adding the following line to your log4j-server.properties: log4j.logger.org.apache.cassandra.thrift.CustomTThreadPoolServer=FATAL Here is the developer's explanation: The root cause is a bug in TPreviewableTransport causing the previewing of the stream to be not fully transparent to the transports higher in the transport stack. The negotiating transport needs to preview a first few bytes of the content that the client sends to the server, in order to detect the transport negotiation header. In case the client does not want to do any protocol negotiation, like Hector, or some monitoring tools, the negotiating layer should be invisible and pass data to/from the higher levels transparently. Actually it almost does so. The only problem happens when while previewing it reaches the end of the stream. If EOF is reached, it throws an exception instead of just silently ignoring and letting the higher level to decide. This is harmless, because the stream is closed by the client, and the higher level transport would close the server-end of the stream anyway, just without logging any exceptions. was (Author: jblangs...@datastax.com): This bug is specific to DSE 3.0 and is not present in Apache Cassandra. The DSE bug number is DSP-1662. This error is known to occur when using Hector. The error is benign and will be fixed in 3.0.1. Until then, you can silence the error by adding the following line to your log4j-server.properties: log4j.logger.org.apache.cassandra.thrift.CustomTThreadPoolServer=FATAL Here is the developer's explanation: The root cause is a bug in TPreviewableTransport causing the previewing of the stream to be not fully transparent to the transports higher in the transport stack. The negotiating transport needs to preview a first few bytes of the content that the client sends to the server, in order to detect the transport negotiation header. In case the client does not want to do any protocol negotiation, like Hector, or some monitoring tools, the negotiating layer should be invisible and pass data to/from the higher levels transparently. Actually it almost does so. The only problem happens when while previewing it reaches the end of the stream. If EOF is reached, it throws an exception instead of just silently ignoring and letting the higher level to decide. This is harmless, because the stream is closed by the client, and the higher level transport would close the server-end of the stream anyway, just without logging any exceptions. CustomTThreadPoolServer.java (line 210) Error occurred during processing of message. Key: CASSANDRA-5427 URL: https://issues.apache.org/jira/browse/CASSANDRA-5427 Project: Cassandra Issue Type: Bug Components: Config, Core Affects Versions: 1.1.9 Environment: DSE 3.0, Hector Client 1.1-2, Cassandra 1.1.9, Linux 64 bit, Heap 4 GB, Total RAM 8 GB, 2 Core (its a test environment). Reporter: Tushar Agrawal We are getting lot of following errors. We tried to change the thrift_framed_transport_size_in_mb and thrift_max_message_length_in_mb to 30 and 32 respectively without any success. Our message size is about 20 KB and we even tried to reduce it to 10 KB. We have 27 fixed columns and no secondary indexes. ERROR [Thrift:110] 2013-04-04 19:11:40,882 CustomTThreadPoolServer.java (line 210) Error occurred during processing of message. java.lang.RuntimeException: Failed to open server transport. at com.datastax.bdp.transport.server.TNegotiatingServerTransport$Factory.getTransport(TNegotiatingServerTransport.java:285) at com.datastax.bdp.transport.server.TNegotiatingServerTransport$Factory.getTransport(TNegotiatingServerTransport.java:257) at org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:184) 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) Caused by: org.apache.thrift.transport.TTransportException: java.net.SocketException:
[jira] [Commented] (CASSANDRA-5051) Allow automatic cleanup after gc_grace
[
https://issues.apache.org/jira/browse/CASSANDRA-5051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13625862#comment-13625862
]
Jonathan Ellis commented on CASSANDRA-5051:
---
bq. may be it will help if you add the following line in line 169
(testCleanupDuringRangeMovement)
That does help. I think the test and the code are both wrong. :)
First, the code is wrong because the range being moved is going from node 2's
range to node 3. The local node's range ({{[01 .. 02)}}) is unaffected by
the bootstrap here. Only node 3 should add that range to its don't throw this
away on cleanup list. (So, just don't drop the destination part of
TM.getPendingRanges and this will be trivial to calculate.)
Second, the test is wrong because (as written) it should only retain keys from
{{[01 .. 02]}}. What we actually need to test is making the local node the one
bootstrapping (i.e., having a pending range entry).
Allow automatic cleanup after gc_grace
--
Key: CASSANDRA-5051
URL: https://issues.apache.org/jira/browse/CASSANDRA-5051
Project: Cassandra
Issue Type: New Feature
Components: Core
Reporter: Brandon Williams
Assignee: Vijay
Labels: vnodes
Fix For: 2.0
Attachments: 0001-5051-v4.patch, 0001-5051-with-test-fixes.patch,
0001-CASSANDRA-5051.patch, 0002-5051-remove-upgradesstable.patch,
0002-5051-remove-upgradesstable-v4.patch, 0004-5051-additional-test-v4.patch,
5051-v2.txt
When using vnodes, after adding a new node you have to run cleanup on all the
machines, because you don't know which are affected and chances are it was
most if not all of them. As an alternative to this intensive process, we
could allow cleanup during compaction if the data is older than gc_grace (or
perhaps some other time period since people tend to use gc_grace hacks to get
rid of tombstones.)
--
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-5427) CustomTThreadPoolServer.java (line 210) Error occurred during processing of message.
[ https://issues.apache.org/jira/browse/CASSANDRA-5427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-5427. --- Resolution: Not A Problem Thanks, JB. CustomTThreadPoolServer.java (line 210) Error occurred during processing of message. Key: CASSANDRA-5427 URL: https://issues.apache.org/jira/browse/CASSANDRA-5427 Project: Cassandra Issue Type: Bug Components: Config, Core Affects Versions: 1.1.9 Environment: DSE 3.0, Hector Client 1.1-2, Cassandra 1.1.9, Linux 64 bit, Heap 4 GB, Total RAM 8 GB, 2 Core (its a test environment). Reporter: Tushar Agrawal We are getting lot of following errors. We tried to change the thrift_framed_transport_size_in_mb and thrift_max_message_length_in_mb to 30 and 32 respectively without any success. Our message size is about 20 KB and we even tried to reduce it to 10 KB. We have 27 fixed columns and no secondary indexes. ERROR [Thrift:110] 2013-04-04 19:11:40,882 CustomTThreadPoolServer.java (line 210) Error occurred during processing of message. java.lang.RuntimeException: Failed to open server transport. at com.datastax.bdp.transport.server.TNegotiatingServerTransport$Factory.getTransport(TNegotiatingServerTransport.java:285) at com.datastax.bdp.transport.server.TNegotiatingServerTransport$Factory.getTransport(TNegotiatingServerTransport.java:257) at org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:184) 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) Caused by: org.apache.thrift.transport.TTransportException: java.net.SocketException: Connection reset at org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.java:129) at com.datastax.bdp.transport.server.TPreviewableTransport.read(TPreviewableTransport.java:88) at org.apache.thrift.transport.TTransport.readAll(TTransport.java:84) at com.datastax.bdp.transport.server.TPreviewableTransport.preview(TPreviewableTransport.java:44) at com.datastax.bdp.transport.server.TNegotiatingServerTransport.open(TNegotiatingServerTransport.java:169) at com.datastax.bdp.transport.server.TNegotiatingServerTransport$Factory.getTransport(TNegotiatingServerTransport.java:278) ... 5 more Caused by: java.net.SocketException: Connection reset at java.net.SocketInputStream.read(Unknown Source) at java.io.BufferedInputStream.fill(Unknown Source) at java.io.BufferedInputStream.read1(Unknown Source) at java.io.BufferedInputStream.read(Unknown Source) at org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.java:127) ... 10 more -- 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-4932) Agree on a gcbefore/expirebefore value for all replica during validation compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-4932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13625880#comment-13625880 ] Yuki Morishita commented on CASSANDRA-4932: --- +1 Agree on a gcbefore/expirebefore value for all replica during validation compaction Key: CASSANDRA-4932 URL: https://issues.apache.org/jira/browse/CASSANDRA-4932 Project: Cassandra Issue Type: Improvement Reporter: Sylvain Lebresne Assignee: Marcus Eriksson Priority: Minor Fix For: 2.0 Attachments: 0001-CASSANDRA-4932.patch, 0001-CASSANDRA-4932-v2.patch CASSANDRA-4905 made it so that we don't include gcable tombstones in merkle tree digests because otherwise the fact that a gcable tombstone exists in a given node depends on the local scheduling of compactions, which make the merkle-tree digets depends on that which is bad. However, we still depends on a value of gcbefore/expirebefore that is computed locally on the node. This is not a huge deal because each node should compute those value roughly at the same time so the discrepancies shouldn't exceed a few hundreds of milliseconds in general and a few seconds if we're unlucky. Still, it's fairly easy to fix this problem by having the repair coordinator pick the gcbefore/expirebefore and share that with all the replica. It does require sending that info on the wire though, so will require a new messaging version and thus can only be done in a major cycle. -- 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-5062) Support CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13625888#comment-13625888 ] Jonathan Ellis commented on CASSANDRA-5062: --- Working on the code, but I don't think PaxosState introduces artificial contention in the sense that we do need to serialize paxos operations, so this is definitely better than One Big Lock. (I also like bounding the number of in-progress paxos states we have.) Support CAS --- Key: CASSANDRA-5062 URL: https://issues.apache.org/jira/browse/CASSANDRA-5062 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Jonathan Ellis Fix For: 2.0 Attachments: half-baked commit 1.jpg, half-baked commit 2.jpg, half-baked commit 3.jpg Strong consistency is not enough to prevent race conditions. The classic example is user account creation: we want to ensure usernames are unique, so we only want to signal account creation success if nobody else has created the account yet. But naive read-then-write allows clients to race and both think they have a green light to create. -- 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-5062) Support CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13625891#comment-13625891 ] Jonathan Ellis commented on CASSANDRA-5062: --- bq. Also, I think we're lacking something around reads and around CL.SERIAL. I think we at least need to support CL.SERIAL reads, that would have to go through paxos (so they play inProgress values). But I would a relatively big fan to also allow a (non-SERIAL) CL in cas() that would be applied to the final commit of the cas write Yes, I think I mentioned both of these as stuff that is missing. Would rather make them follow-on tickets. Support CAS --- Key: CASSANDRA-5062 URL: https://issues.apache.org/jira/browse/CASSANDRA-5062 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Jonathan Ellis Fix For: 2.0 Attachments: half-baked commit 1.jpg, half-baked commit 2.jpg, half-baked commit 3.jpg Strong consistency is not enough to prevent race conditions. The classic example is user account creation: we want to ensure usernames are unique, so we only want to signal account creation success if nobody else has created the account yet. But naive read-then-write allows clients to race and both think they have a green light to create. -- 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-3533) TimeoutException when there is a firewall issue.
[
https://issues.apache.org/jira/browse/CASSANDRA-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13625896#comment-13625896
]
Vijay commented on CASSANDRA-3533:
--
{quote}
where would the null EchoMessage come from? Even the v1 serialize does not
return null.
{quote}
{code}
if (payloadSize == 0 || serializer == null)
return create(from, null, parameters, verb, version);
T2 payload = serializer.deserialize(in, version);
{code}
if the payload is 0 then we wont deserialize, thats where it comes from :)
I will remove the assertion if thats all we need to do from the original patch.
TimeoutException when there is a firewall issue.
Key: CASSANDRA-3533
URL: https://issues.apache.org/jira/browse/CASSANDRA-3533
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Vijay
Assignee: Vijay
Priority: Minor
Fix For: 2.0
Attachments: 0001-3533-v2.patch, 0001-CASSANDRA-3533.patch, 3533.txt
When one node in the cluster is not able to talk to the other DC/RAC due to
firewall or network related issue (StorageProxy calls fail), and the nodes
are NOT marked down because at least one node in the cluster can talk to the
other DC/RAC, we get timeoutException instead of throwing a
unavailableException.
The problem with this:
1) It is hard to monitor/identify these errors.
2) It is hard to diffrentiate from the client if the node being bad vs a bad
query.
3) when this issue happens we have to wait for at-least the RPC timeout time
to know that the query wont succeed.
Possible Solution: when marking a node down we might want to check if the
node is actually alive by trying to communicate to it? So we can be sure that
the node is actually alive.
--
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] [Comment Edited] (CASSANDRA-3533) TimeoutException when there is a firewall issue.
[
https://issues.apache.org/jira/browse/CASSANDRA-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13625896#comment-13625896
]
Vijay edited comment on CASSANDRA-3533 at 4/8/13 10:05 PM:
---
{quote}
where would the null EchoMessage come from? Even the v1 serialize does not
return null.
{quote}
in o.a.c.n.MessageIn
{code}
if (payloadSize == 0 || serializer == null)
return create(from, null, parameters, verb, version);
T2 payload = serializer.deserialize(in, version);
{code}
if the payload is 0 then we wont deserialize, thats where it comes from :)
I will remove the assertion if thats all we need to do from the original patch.
was (Author: vijay2...@yahoo.com):
{quote}
where would the null EchoMessage come from? Even the v1 serialize does not
return null.
{quote}
{code}
if (payloadSize == 0 || serializer == null)
return create(from, null, parameters, verb, version);
T2 payload = serializer.deserialize(in, version);
{code}
if the payload is 0 then we wont deserialize, thats where it comes from :)
I will remove the assertion if thats all we need to do from the original patch.
TimeoutException when there is a firewall issue.
Key: CASSANDRA-3533
URL: https://issues.apache.org/jira/browse/CASSANDRA-3533
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Vijay
Assignee: Vijay
Priority: Minor
Fix For: 2.0
Attachments: 0001-3533-v2.patch, 0001-CASSANDRA-3533.patch, 3533.txt
When one node in the cluster is not able to talk to the other DC/RAC due to
firewall or network related issue (StorageProxy calls fail), and the nodes
are NOT marked down because at least one node in the cluster can talk to the
other DC/RAC, we get timeoutException instead of throwing a
unavailableException.
The problem with this:
1) It is hard to monitor/identify these errors.
2) It is hard to diffrentiate from the client if the node being bad vs a bad
query.
3) when this issue happens we have to wait for at-least the RPC timeout time
to know that the query wont succeed.
Possible Solution: when marking a node down we might want to check if the
node is actually alive by trying to communicate to it? So we can be sure that
the node is actually alive.
--
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-5431) cassandra-shuffle with JMX usernames and passwords
[ https://issues.apache.org/jira/browse/CASSANDRA-5431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13625917#comment-13625917 ] Dave Brosius commented on CASSANDRA-5431: - There's quite a bunch of miscellaneous formatting changes in 5431-v3.txt that obfuscate this patch. Mind reposting a patch with only the changes for the patch itself? cassandra-shuffle with JMX usernames and passwords --- Key: CASSANDRA-5431 URL: https://issues.apache.org/jira/browse/CASSANDRA-5431 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.3 Reporter: Eric Dong Assignee: Michał Michalski Attachments: 5431-v2.txt, 5431-v3.txt, CASSANDRA-5431-whitespace.patch Unlike nodetool, cassandra-shuffle doesn't allow passing in a JMX username and password. This stops those who want to switch to vnodes from doing so if JMX access requires a username and a password. Patch to 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-5062) Support CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13625923#comment-13625923 ] Jonathan Ellis commented on CASSANDRA-5062: --- bq. In SP.preparePaxos, if we throw if !mostRecentCommitHasQuorum and since PrepareCallback only waits for quorum response We wait for as many nodes as were alive at the start of the paxos request. bq. I think it is necessary to re-prepare after the commits anyway because those commit will erase the paxos state on the replica, so some of the promise we got are not valid anymore. We don't erase the promise, and we shouldn't, because that would allow us to accept an out-of-date propose (that got delayed in the intertubes from another proposer, for example -- does not require buggy proposers). bq. So retrying server side seems to me like the right and the most efficient one. All right, although pushing the side effect back to the client also makes it much less likely to race with a proposer that has interrupted us. Added some sleep(0.100) to attempt to make this less problematic. bq. When getting the prepare response, I think that as soon as we get a response that is not promised, we can stop waiting for the other responses. Agreed, but the logic to do this gets kind of ugly. Don't think it's worth addressing. bq. the timestamp of the columns we write during the commit should be the ballot timestamp What does this buy us? I don't think we need to allow mixing CAS/non-CAS on a row, and it would make using non-clock-timestamps impossible. bq. SystemTable.savePaxosCommit doesn't seem to delete in_progress_ballot As above, this is deliberate. bq. there is a bunch of places where we could reuse the new Commit class I prefer to keep ballot/proposal separate except for the MRC since promise/accept are done at different times. Support CAS --- Key: CASSANDRA-5062 URL: https://issues.apache.org/jira/browse/CASSANDRA-5062 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Jonathan Ellis Fix For: 2.0 Attachments: half-baked commit 1.jpg, half-baked commit 2.jpg, half-baked commit 3.jpg Strong consistency is not enough to prevent race conditions. The classic example is user account creation: we want to ensure usernames are unique, so we only want to signal account creation success if nobody else has created the account yet. But naive read-then-write allows clients to race and both think they have a green light to create. -- 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-5431) cassandra-shuffle with JMX usernames and passwords
[ https://issues.apache.org/jira/browse/CASSANDRA-5431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13625928#comment-13625928 ] Jonathan Ellis commented on CASSANDRA-5431: --- v2 is just the changes, v3 is changes squashed with the whitespace patch. cassandra-shuffle with JMX usernames and passwords --- Key: CASSANDRA-5431 URL: https://issues.apache.org/jira/browse/CASSANDRA-5431 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.3 Reporter: Eric Dong Assignee: Michał Michalski Attachments: 5431-v2.txt, 5431-v3.txt, CASSANDRA-5431-whitespace.patch Unlike nodetool, cassandra-shuffle doesn't allow passing in a JMX username and password. This stops those who want to switch to vnodes from doing so if JMX access requires a username and a password. Patch to 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-3533) TimeoutException when there is a firewall issue.
[ https://issues.apache.org/jira/browse/CASSANDRA-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13625927#comment-13625927 ] Jonathan Ellis commented on CASSANDRA-3533: --- SGTM. TimeoutException when there is a firewall issue. Key: CASSANDRA-3533 URL: https://issues.apache.org/jira/browse/CASSANDRA-3533 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Vijay Assignee: Vijay Priority: Minor Fix For: 2.0 Attachments: 0001-3533-v2.patch, 0001-CASSANDRA-3533.patch, 3533.txt When one node in the cluster is not able to talk to the other DC/RAC due to firewall or network related issue (StorageProxy calls fail), and the nodes are NOT marked down because at least one node in the cluster can talk to the other DC/RAC, we get timeoutException instead of throwing a unavailableException. The problem with this: 1) It is hard to monitor/identify these errors. 2) It is hard to diffrentiate from the client if the node being bad vs a bad query. 3) when this issue happens we have to wait for at-least the RPC timeout time to know that the query wont succeed. Possible Solution: when marking a node down we might want to check if the node is actually alive by trying to communicate to it? So we can be sure that the node is actually alive. -- 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
[Cassandra Wiki] Trivial Update of MarcoS31 by MarcoS31
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The MarcoS31 page has been changed by MarcoS31: http://wiki.apache.org/cassandra/MarcoS31 New page: Name: Marco WiltBR My age: 25BR Country: GermanyBR Home town: Nohen BR Post code: 55767BR Address: Meininger Strasse 96BR BR Feel free to surf to my page; [[http://www.healthreviewscam.com/somanabolic-muscle-maximizer-review/|muscle maximizer somanabolic review]]
[Cassandra Wiki] Trivial Update of Outlines_For_fast_Solutions_Pertaining_to_customized_fat_loss_review by MarcoS31
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The Outlines_For_fast_Solutions_Pertaining_to_customized_fat_loss_review page has been changed by MarcoS31: http://wiki.apache.org/cassandra/Outlines_For_fast_Solutions_Pertaining_to_customized_fat_loss_review New page: Everyone differs, states Doctor. Dan Pompa. Some everyone is gonna be inspired by concern. Some people will be determined through the reports We reveal through people in whose life possess transformed on account of our collaborative therapy. Some people are encouraged merely by expressing 'I want to do this specific in my family members.' I try going to upon all of the locations so an individual will probably be encouraged some way.In .BR BR Individually, the kyle leon review fat loss factor staff has to be terminated or reassigned along with other locations where it might possibly add to the companys net profit. Its pharmaceutical economics modeling and knowledge manipulations seem dubious, that's why it appears ethically questionable to evaluate data considering the intended goal of proving an kyle leon review drug rejected in clinical trials has some medical benefit that doctors around the field overlooked. BR BR There are so many products available on the internet that goals your current kitty's most typical customized fat loss review concerns, as well as i will explain a lot of them for your requirements. To start with, ensure that you fight off ones kitty's bugs, since these unwanted organisms is often an annoying attack for the family pet. The net online store Nutrecare gives goods like Frontline Kitten Spot On, that is officially used on cats as small as 60 days. BR BR In the event that all of these signs circumstance, maybe you should obtain a hygrometer (wetness meter) and also try taking a little blood pressure measurements to determine if humidity would be the bring about. Using better technology available there's no need for your customized fat loss review to help go through.BR BR Here's more info on [[http://www.healthreviewscam.com/somanabolic-muscle-maximizer-review/|muscle maximizer somanabolic review]] take a look at http://www.healthreviewscam.com/fat-loss-factor-review/
[jira] [Created] (CASSANDRA-5440) ISE during short reads
Brandon Williams created CASSANDRA-5440:
---
Summary: ISE during short reads
Key: CASSANDRA-5440
URL: https://issues.apache.org/jira/browse/CASSANDRA-5440
Project: Cassandra
Issue Type: Bug
Reporter: Brandon Williams
Assignee: Brandon Williams
On trunk:
{noformat}
ERROR [Thrift:2] 2013-04-08 15:06:56,468 ProcessFunction.java (line 41)
Internal error processing execute_cql3_query
java.lang.IllegalStateException
at java.util.AbstractList$Itr.remove(AbstractList.java:356)
at
org.apache.cassandra.db.filter.SliceQueryFilter.trim(SliceQueryFilter.java:187)
at
org.apache.cassandra.db.SliceFromReadCommand.maybeTrim(SliceFromReadCommand.java:101)
at
org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:902)
at org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:831)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:128)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:56)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:130)
at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:141)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql3_query(CassandraServer.java:1836)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(Cassandra.java:4232)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(Cassandra.java:4216)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:199)
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:662)
{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] [Commented] (CASSANDRA-5440) ISE during short reads
[
https://issues.apache.org/jira/browse/CASSANDRA-5440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13625978#comment-13625978
]
Brandon Williams commented on CASSANDRA-5440:
-
I'll bisect this.
ISE during short reads
--
Key: CASSANDRA-5440
URL: https://issues.apache.org/jira/browse/CASSANDRA-5440
Project: Cassandra
Issue Type: Bug
Reporter: Brandon Williams
Assignee: Brandon Williams
On trunk:
{noformat}
ERROR [Thrift:2] 2013-04-08 15:06:56,468 ProcessFunction.java (line 41)
Internal error processing execute_cql3_query
java.lang.IllegalStateException
at java.util.AbstractList$Itr.remove(AbstractList.java:356)
at
org.apache.cassandra.db.filter.SliceQueryFilter.trim(SliceQueryFilter.java:187)
at
org.apache.cassandra.db.SliceFromReadCommand.maybeTrim(SliceFromReadCommand.java:101)
at
org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:902)
at org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:831)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:128)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:56)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:130)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:141)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql3_query(CassandraServer.java:1836)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(Cassandra.java:4232)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(Cassandra.java:4216)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:199)
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:662)
{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] [Commented] (CASSANDRA-5062) Support CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13625980#comment-13625980 ] Jonathan Ellis commented on CASSANDRA-5062: --- Pushed updates to https://github.com/jbellis/cassandra/commits/5062-4 and created subtasks. (Rebased again to get CASSANDRA-3783.) Support CAS --- Key: CASSANDRA-5062 URL: https://issues.apache.org/jira/browse/CASSANDRA-5062 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Jonathan Ellis Fix For: 2.0 Attachments: half-baked commit 1.jpg, half-baked commit 2.jpg, half-baked commit 3.jpg Strong consistency is not enough to prevent race conditions. The classic example is user account creation: we want to ensure usernames are unique, so we only want to signal account creation success if nobody else has created the account yet. But naive read-then-write allows clients to race and both think they have a green light to create. -- 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] [Created] (CASSANDRA-5441) Add support for read at CL.SERIAL
Jonathan Ellis created CASSANDRA-5441: - Summary: Add support for read at CL.SERIAL Key: CASSANDRA-5441 URL: https://issues.apache.org/jira/browse/CASSANDRA-5441 Project: Cassandra Issue Type: Sub-task Reporter: Jonathan Ellis -- 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] [Created] (CASSANDRA-5442) Add support for specifying CAS commit CL
Jonathan Ellis created CASSANDRA-5442: - Summary: Add support for specifying CAS commit CL Key: CASSANDRA-5442 URL: https://issues.apache.org/jira/browse/CASSANDRA-5442 Project: Cassandra Issue Type: Sub-task Reporter: Jonathan Ellis -- 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] [Created] (CASSANDRA-5443) Add CAS CQL support
Jonathan Ellis created CASSANDRA-5443: - Summary: Add CAS CQL support Key: CASSANDRA-5443 URL: https://issues.apache.org/jira/browse/CASSANDRA-5443 Project: Cassandra Issue Type: Sub-task Reporter: Jonathan Ellis -- 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
[Cassandra Wiki] Trivial Update of bexozyxkutu088 by bexozyxkutu088
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The bexozyxkutu088 page has been changed by bexozyxkutu088: http://wiki.apache.org/cassandra/bexozyxkutu088?action=diffrev1=5rev2=7 - I am a Seo expert delivering wonderful products along with suggestions for everyone which desires to produce good money off their own web sites.BR + I'm a Search engine optimisation professional providing fantastic equipment as well as advices for everyone that will wants to create a higher income off their particular websites.BR BR + Review my website [[http://scrapebrokers.com/october-autoapprove-scrapebox-list|Clicking Here]] - BR - My web site; [[http://scrapebrokers.com/tag/scrapebox-autoapprove-list|Recommended Internet page]]
[Cassandra Wiki] Trivial Update of TristanMu by TristanMu
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The TristanMu page has been changed by TristanMu: http://wiki.apache.org/cassandra/TristanMu New page: These lamps were much superior to other lamps with the time, and Mr Coleman’s business soon took off.BR Remember though, cabin tents usually provide more room and even more walking space inside. BR BR BR BR My name is Tristan Mueller. I life in Dundee Beach (Australia).BR BR My weblog ... [[http://rayzzz.com/ErickaHom|trekking shop]]
[Cassandra Wiki] Trivial Update of DarinMcca by DarinMcca
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The DarinMcca page has been changed by DarinMcca: http://wiki.apache.org/cassandra/DarinMcca New page: Watchmaker Naoharu Sakelaris spare-time activities includes causes of headaches audio books, football.BR What else? He likes vacationing and checking out new countries like Kitwe.BR BR Stop by my website - [[http://bentio.com/luannrqn|Highly recommended Internet site]]
[jira] [Created] (CASSANDRA-5444) TTL does not compact rows
Sathish created CASSANDRA-5444:
--
Summary: TTL does not compact rows
Key: CASSANDRA-5444
URL: https://issues.apache.org/jira/browse/CASSANDRA-5444
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.9
Environment: Linux
Reporter: Sathish
Fix For: 1.1.9
I find that the rows are not compacted when gc_grace_seconds is set through
alter table command. Following were the steps performed:
1. Created the following table:
CREATE COLUMNFAMILY MirrorSmokeTest (
id uuid PRIMARY KEY,
test_message varchar
);
2. Ran an alter command:
alter table MirrorSmokeTest WITH gc_grace_seconds = 60;
3. Insert a row into the above table:
insert into MirrorSmokeTest (id, test_message) Values
('4a7fad82-8298-4d91-85de-8255b7c7e4f5', '2') USING ttl 60;
4. Waited for 60 seconds and ran a query that results in the following output:
select * from MirrorSmokeTest;
id
--
4a7fad82-8298-4d91-85de-8255b7c7e4f5
5. Ran a flush and compact and reran the query that results in the following:
select * from MirrorSmokeTest;
id
--
4a7fad82-8298-4d91-85de-8255b7c7e4f5
--
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
[Cassandra Wiki] Trivial Update of BobvrscaW by BobvrscaW
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The BobvrscaW page has been changed by BobvrscaW: http://wiki.apache.org/cassandra/BobvrscaW New page: Polo 素材されている を作成する、カムバックの間で 並べ替えファッション。BR BR My blog: [[http://2013rolexfreeshippig.com/|スーパーコピー時計]]
[jira] [Commented] (CASSANDRA-5431) cassandra-shuffle with JMX usernames and passwords
[ https://issues.apache.org/jira/browse/CASSANDRA-5431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13626113#comment-13626113 ] Dave Brosius commented on CASSANDRA-5431: - 5431-v2 doesn't apply cleanly to cassandra-1.2. When fixes up are applied, patch looks good to me, on it's own. I'd note that passing passwords as Strings is probably not a good idea as there's no way to flush the password from the server memory space, as there's no guarantee that gc will toss that string. Would be better if the interface was char[]'s that can be cleared. But that's not this patch's problem. +1 cassandra-shuffle with JMX usernames and passwords --- Key: CASSANDRA-5431 URL: https://issues.apache.org/jira/browse/CASSANDRA-5431 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.3 Reporter: Eric Dong Assignee: Michał Michalski Attachments: 5431-v2.txt, 5431-v3.txt, CASSANDRA-5431-whitespace.patch Unlike nodetool, cassandra-shuffle doesn't allow passing in a JMX username and password. This stops those who want to switch to vnodes from doing so if JMX access requires a username and a password. Patch to 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] [Resolved] (CASSANDRA-5444) TTL does not compact rows
[
https://issues.apache.org/jira/browse/CASSANDRA-5444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams resolved CASSANDRA-5444.
-
Resolution: Invalid
Nothing specific to TTLs here, you're dealing with a range ghost (see the FAQ)
but they eliminated in 1.2.
TTL does not compact rows
--
Key: CASSANDRA-5444
URL: https://issues.apache.org/jira/browse/CASSANDRA-5444
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.9
Environment: Linux
Reporter: Sathish
Fix For: 1.1.9
I find that the rows are not compacted when gc_grace_seconds is set through
alter table command. Following were the steps performed:
1. Created the following table:
CREATE COLUMNFAMILY MirrorSmokeTest (
id uuid PRIMARY KEY,
test_message varchar
);
2. Ran an alter command:
alter table MirrorSmokeTest WITH gc_grace_seconds = 60;
3. Insert a row into the above table:
insert into MirrorSmokeTest (id, test_message) Values
('4a7fad82-8298-4d91-85de-8255b7c7e4f5', '2') USING ttl 60;
4. Waited for 60 seconds and ran a query that results in the following output:
select * from MirrorSmokeTest;
id
--
4a7fad82-8298-4d91-85de-8255b7c7e4f5
5. Ran a flush and compact and reran the query that results in the following:
select * from MirrorSmokeTest;
id
--
4a7fad82-8298-4d91-85de-8255b7c7e4f5
--
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] [Comment Edited] (CASSANDRA-5444) TTL does not compact rows
[
https://issues.apache.org/jira/browse/CASSANDRA-5444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13626140#comment-13626140
]
Brandon Williams edited comment on CASSANDRA-5444 at 4/9/13 2:30 AM:
-
Nothing specific to TTLs here, you're dealing with a range ghost (see the FAQ)
but they are eliminated in 1.2.
was (Author: brandon.williams):
Nothing specific to TTLs here, you're dealing with a range ghost (see the
FAQ) but they eliminated in 1.2.
TTL does not compact rows
--
Key: CASSANDRA-5444
URL: https://issues.apache.org/jira/browse/CASSANDRA-5444
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.9
Environment: Linux
Reporter: Sathish
Fix For: 1.1.9
I find that the rows are not compacted when gc_grace_seconds is set through
alter table command. Following were the steps performed:
1. Created the following table:
CREATE COLUMNFAMILY MirrorSmokeTest (
id uuid PRIMARY KEY,
test_message varchar
);
2. Ran an alter command:
alter table MirrorSmokeTest WITH gc_grace_seconds = 60;
3. Insert a row into the above table:
insert into MirrorSmokeTest (id, test_message) Values
('4a7fad82-8298-4d91-85de-8255b7c7e4f5', '2') USING ttl 60;
4. Waited for 60 seconds and ran a query that results in the following output:
select * from MirrorSmokeTest;
id
--
4a7fad82-8298-4d91-85de-8255b7c7e4f5
5. Ran a flush and compact and reran the query that results in the following:
select * from MirrorSmokeTest;
id
--
4a7fad82-8298-4d91-85de-8255b7c7e4f5
--
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
