git commit: Decide on a gcBefore before sending out TreeRequests

2013-04-08 Thread marcuse
Updated Branches:
  refs/heads/trunk 3e0b21c45 -> efbdee237


Decide on a gcBefore before sending out TreeRequests

patch by marcuse, reviewed by yukim, for CASSANDRA-4932


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

Branch: refs/heads/trunk
Commit: efbdee23705fed6be49a2fb20a79f18c98ff
Parents: 3e0b21c
Author: Marcus Eriksson 
Authored: Tue Apr 9 08:08:32 2013 +0200
Committer: Marcus Eriksson 
Committed: Tue Apr 9 08:08:32 2013 +0200

--
 CHANGES.txt|3 +-
 .../cassandra/db/compaction/CompactionManager.java |5 ++-
 .../cassandra/service/ActiveRepairService.java |   27 ++
 .../data/serialization/2.0/service.TreeRequest.bin |  Bin 121 -> 129 bytes
 .../serialization/2.0/service.TreeResponse.bin |  Bin 930 -> 946 bytes
 .../compaction/LeveledCompactionStrategyTest.java  |3 +-
 .../service/AntiEntropyServiceTestAbstract.java|3 +-
 .../cassandra/service/SerializationsTest.java  |2 +-
 8 files changed, 30 insertions(+), 13 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/efbdee23/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index bb00642..b322425 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -28,7 +28,8 @@
  * remove row-level bloom filters (CASSANDRA-4885)
  * Change Kernel Page Cache skipping into row preheating (disabled by default)
(CASSANDRA-4937)
-
+ * Improve repair by deciding on a gcBefore before sending
+   out TreeRequests (CASSANDRA-4932)
 
 1.2.4
  * Ensure that PerRowSecondaryIndex updates see the most recent values

http://git-wip-us.apache.org/repos/asf/cassandra/blob/efbdee23/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 64cf253..b5aefee 100644
--- a/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
+++ b/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
@@ -618,7 +618,10 @@ public class CompactionManager implements 
CompactionManagerMBean
 // we don't mark validating sstables as compacting in DataTracker, 
so we have to mark them referenced
 // instead so they won't be cleaned up if they do get compacted 
during the validation
 sstables = cfs.markCurrentSSTablesReferenced();
-gcBefore = getDefaultGcBefore(cfs);
+if (validator.request.gcBefore > 0)
+gcBefore = validator.request.gcBefore;
+else
+gcBefore = getDefaultGcBefore(cfs);
 }
 
 CompactionIterable ci = new ValidationCompactionIterable(cfs, 
sstables, validator.request.range, gcBefore);

http://git-wip-us.apache.org/repos/asf/cassandra/blob/efbdee23/src/java/org/apache/cassandra/service/ActiveRepairService.java
--
diff --git a/src/java/org/apache/cassandra/service/ActiveRepairService.java 
b/src/java/org/apache/cassandra/service/ActiveRepairService.java
index f103771..f7a5fa4 100644
--- a/src/java/org/apache/cassandra/service/ActiveRepairService.java
+++ b/src/java/org/apache/cassandra/service/ActiveRepairService.java
@@ -442,7 +442,7 @@ public class ActiveRepairService
 public void doVerb(MessageIn message, int id)
 {
 TreeRequest remotereq = message.payload;
-TreeRequest request = new TreeRequest(remotereq.sessionid, 
message.from, remotereq.range, remotereq.cf);
+TreeRequest request = new TreeRequest(remotereq.sessionid, 
message.from, remotereq.range, remotereq.gcBefore, remotereq.cf);
 
 // trigger read-only compaction
 ColumnFamilyStore store = 
Table.open(request.cf.left).getColumnFamilyStore(request.cf.right);
@@ -462,7 +462,7 @@ public class ActiveRepairService
 {
 // deserialize the remote tree, and register it
 Validator response = message.payload;
-TreeRequest request = new TreeRequest(response.request.sessionid, 
message.from, response.request.range, response.request.cf);
+TreeRequest request = new TreeRequest(response.request.sessionid, 
message.from, response.request.range, response.request.gcBefore, 
response.request.cf);
 ActiveRepairService.instance.rendezvous(request, response.tree);
 }
 }
@@ -489,20 +489,22 @@ public class ActiveRepairService
 pu

[Cassandra Wiki] Trivial Update of "MariamLut" by MariamLut

2013-04-08 Thread Apache Wiki
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for 
change notification.

The "MariamLut" page has been changed by MariamLut:
http://wiki.apache.org/cassandra/MariamLut

New page:
http://wiki.flisol.cl/index.php?title=Usuario:Alan1278 http://wiki.<>
cagepotato.com/index.php?title=User:FredrickL<>
<>
Check out my blog [[http://heraudition.com/ShonaUPGG|online casinos review]]


[Cassandra Wiki] Trivial Update of "LewisShoc" by LewisShoc

2013-04-08 Thread Apache Wiki
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for 
change notification.

The "LewisShoc" page has been changed by LewisShoc:
http://wiki.apache.org/cassandra/LewisShoc

New page:
There is nothing to write about me at all.<>
Yes! Im a member of apache.org.<>
I just wish Im useful in some way here.<>
<>
my blog post :: 
[[http://beingsbook.com/blogs/94641/203545/tactics-to-get-the-most-from-you|vehicle
 insurance ratings]]


git commit: remove duplicate line

2013-04-08 Thread dbrosius
Updated Branches:
  refs/heads/trunk 39cf55a54 -> 3e0b21c45


remove duplicate line


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

Branch: refs/heads/trunk
Commit: 3e0b21c45aead137250c30bba1224d213debe73b
Parents: 39cf55a
Author: Dave Brosius 
Authored: Tue Apr 9 01:23:24 2013 -0400
Committer: Dave Brosius 
Committed: Tue Apr 9 01:23:24 2013 -0400

--
 .../db/index/composites/CompositesIndex.java   |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/3e0b21c4/src/java/org/apache/cassandra/db/index/composites/CompositesIndex.java
--
diff --git 
a/src/java/org/apache/cassandra/db/index/composites/CompositesIndex.java 
b/src/java/org/apache/cassandra/db/index/composites/CompositesIndex.java
index 26ad84d..202efbf 100644
--- a/src/java/org/apache/cassandra/db/index/composites/CompositesIndex.java
+++ b/src/java/org/apache/cassandra/db/index/composites/CompositesIndex.java
@@ -99,7 +99,7 @@ public abstract class CompositesIndex extends 
AbstractSimplePerColumnSecondaryIn
 {
 int localDeletionTime = (int) (System.currentTimeMillis() / 1000);
 ColumnFamily cfi = 
ArrayBackedSortedColumns.factory.create(indexCfs.metadata);
-cfi.addTombstone(entry.indexEntry, (int) (System.currentTimeMillis() / 
1000), entry.timestamp);
+cfi.addTombstone(entry.indexEntry, localDeletionTime, entry.timestamp);
 indexCfs.apply(entry.indexValue, cfi, 
SecondaryIndexManager.nullUpdater);
 if (logger.isDebugEnabled())
 logger.debug("removed index entry for cleaned-up value {}:{}", 
entry.indexValue, cfi);



[Cassandra Wiki] Trivial Update of "DemetraW6" by DemetraW6

2013-04-08 Thread Apache Wiki
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for 
change notification.

The "DemetraW6" page has been changed by DemetraW6:
http://wiki.apache.org/cassandra/DemetraW6

New page:
My name: Senaida Delvalle<>
Age: 27<>
Country: Netherlands<>
Home town: Amstelveen <>
ZIP: 1186 NK<>
Street: Watercirkel 176<>
<>
my website [[http://pligg.Austinhiphopscene.com/user.php?login=opalm69&;|car 
insurance florida the general]]


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

2013-04-08 Thread Yuki Morishita (JIRA)

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

Yuki Morishita commented on CASSANDRA-2698:
---

[~benedict]

hmm, it is not clear to me why you create EstimatedHistogram of size of 
differences. Sometimes I see more than 1000 of differences for large clusters. 
You should just create it with reasonable bucket count. You don't have to keep 
every size for every range.

Using logging for outputting statistic is fine at this point, but I think we 
should come up with other way so that it is easy to see all the related logs 
and statistics about certain repair session. I don't have specific idea yet 
though. (Maybe another system cf similar to Tracing?)

nits:

- fix coding style (especially whitespace) to match other code.
- EstimatedHistogram#testGroupBy is failing.
- comparator in Arrays#sort in EstimatedHistogram#logSummary has the same 
conditions in both if and else if.

> Instrument repair to be able to assess it's efficiency (precision)
> --
>
> Key: CASSANDRA-2698
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2698
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Sylvain Lebresne
>Assignee: Benedict
>Priority: Minor
>  Labels: lhf
> Attachments: nodetool_repair_and_cfhistogram.tar.gz, 
> patch_2698_v1.txt, patch.diff, patch-rebased.diff
>
>
> Some reports indicate that repair sometime transfer huge amounts of data. One 
> hypothesis is that the merkle tree precision may deteriorate too much at some 
> data size. To check this hypothesis, it would be reasonably to gather 
> statistic during the merkle tree building of how many rows each merkle tree 
> range account for (and the size that this represent). It is probably an 
> interesting statistic to have anyway.   

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


[Cassandra Wiki] Trivial Update of "ArafCrutc" by ArafCrutc

2013-04-08 Thread Apache Wiki
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for 
change notification.

The "ArafCrutc" page has been changed by ArafCrutc:
http://wiki.apache.org/cassandra/ArafCrutc

New page:
Nothing to say about me I think.<>
Enjoying to be a member of apache.org.<>
I just wish Im useful in some way .<>
<>
Also visit my weblog: [[http://tokitama.net/wp/?attachment_id=80|american 
shower and bath moorestown nj]]


[Cassandra Wiki] Update of "HowToContribute" by DaveBrosius

2013-04-08 Thread Apache Wiki
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for 
change notification.

The "HowToContribute" page has been changed by DaveBrosius:
http://wiki.apache.org/cassandra/HowToContribute?action=diff&rev1=45&rev2=46

Comment:
remove svn references

   * Include `-Dhttp.proxyHost=myproxy -Dhttp.proxyPort=3128` in the `ANT_OPTS` 
environment variable.  See the ant wiki 
[http://wiki.apache.org/ant/TheElementsOfAntStyle] for more information about 
`ANT_OPTS`.
   * Specify these values on the command line: `ant clean build 
-Dhttp.proxyHost=myproxy -Dhttp.proxyPort=3128`
  
- == Subversion Configuration ==
- Add this to your subversion configuration (~/.subversion/config on unix-style 
installs) so that newly added files have the correct auto-properties once 
committed:
- 
- {{{
- [auto-props]
- *.java = svn:eol-style=native
- *.properties = svn:eol-style=native
- *.py= svn:eol-style=native
- *.sh = svn:eol-style=native;svn:executable
- *.thrift = svn:eol-style=native
- *.txt = svn:eol-style=native
- *.xml = svn:eol-style=native
- *.jar = svn:mime-type=application/octet-stream
- *.bat = svn:eol-style=CRLF
- }}}
- ''Note: for this to work you must enable auto-props by setting'' 
`enable-auto-props = yes` ''in .subversion/config.''
- 
  == Got Git? ==
   * Using git to manage patches during reviews: 
http://spyced.blogspot.com/2009/06/patch-oriented-development-made-sane.html
   * Uploading and applying patches from JIRA automagically: [[GitAndJIRA]]


[Cassandra Wiki] Trivial Update of "MorrisPir" by MorrisPir

2013-04-08 Thread Apache Wiki
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for 
change notification.

The "MorrisPir" page has been changed by MorrisPir:
http://wiki.apache.org/cassandra/MorrisPir

New page:
My name is Morris Venegas. I life in Callcup (Australia).<>
<>
<>
My site ... 
[[http://www.ppjaponesia.org/userinfo.php?uid=809865|ppjaponesia.org]]


[2/4] git commit: support username/password for for jmx in shuffle tool patch by mmichalski reviewed by dbrosius for cassandra-5431

2013-04-08 Thread dbrosius
support username/password for for jmx in shuffle tool
patch by mmichalski reviewed by dbrosius for cassandra-5431


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

Branch: refs/heads/trunk
Commit: fe8939075999359b8a26a1a0dcf1a7c7bc4531bb
Parents: 2e96d07
Author: Dave Brosius 
Authored: Mon Apr 8 23:17:37 2013 -0400
Committer: Dave Brosius 
Committed: Mon Apr 8 23:17:37 2013 -0400

--
 .../apache/cassandra/tools/AbstractJmxClient.java  |   11 ++-
 src/java/org/apache/cassandra/tools/Shuffle.java   |   11 +++
 2 files changed, 13 insertions(+), 9 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/fe893907/src/java/org/apache/cassandra/tools/AbstractJmxClient.java
--
diff --git a/src/java/org/apache/cassandra/tools/AbstractJmxClient.java 
b/src/java/org/apache/cassandra/tools/AbstractJmxClient.java
index 3d5cd3a..8241a5b 100644
--- a/src/java/org/apache/cassandra/tools/AbstractJmxClient.java
+++ b/src/java/org/apache/cassandra/tools/AbstractJmxClient.java
@@ -47,6 +47,8 @@ public abstract class AbstractJmxClient implements Closeable
 
 protected final String host;
 protected final int port;
+protected final String username;
+protected final String password;
 protected JMXConnection jmxConn;
 protected PrintStream out = System.out;
 
@@ -54,6 +56,8 @@ public abstract class AbstractJmxClient implements Closeable
 {
 options.addOption("h", "host", true,  "JMX hostname or IP address 
(Default: localhost)");
 options.addOption("p", "port", true,  "JMX port number (Default: 
7199)");
+options.addOption("u", "username", true,  "JMX username");
+options.addOption("pw", "password", true,  "JMX password");
 options.addOption("H", "help", false, "Print help information");
 }
 
@@ -61,6 +65,8 @@ public abstract class AbstractJmxClient implements Closeable
 {
 this.host = (host != null) ? host : DEFAULT_HOST;
 this.port = (port != null) ? port : DEFAULT_JMX_PORT;
+this.username = username;
+this.password = password;
 jmxConn = new JMXConnection(this.host, this.port, username, password);
 }
 
@@ -133,11 +139,6 @@ class JMXConnection
 private JMXConnector jmxc;
 private MBeanServerConnection mbeanServerConn;
 
-JMXConnection(String host, int port) throws IOException
-{
-this(host, port, null, null);
-}
-
 JMXConnection(String host, int port, String username, String password) 
throws IOException
 {
 this.host = host;

http://git-wip-us.apache.org/repos/asf/cassandra/blob/fe893907/src/java/org/apache/cassandra/tools/Shuffle.java
--
diff --git a/src/java/org/apache/cassandra/tools/Shuffle.java 
b/src/java/org/apache/cassandra/tools/Shuffle.java
index 8cf38b9..793d2ee 100644
--- a/src/java/org/apache/cassandra/tools/Shuffle.java
+++ b/src/java/org/apache/cassandra/tools/Shuffle.java
@@ -233,7 +233,7 @@ public class Shuffle extends AbstractJmxClient
 {
 try
 {
-JMXConnection conn = new JMXConnection(endpoint, port);
+JMXConnection conn = new JMXConnection(endpoint, port, 
username, password);
 
getSSProxy(conn.getMbeanServerConn()).enableScheduledRangeXfers();
 conn.close();
 }
@@ -265,7 +265,7 @@ public class Shuffle extends AbstractJmxClient
 {
 try
 {
-JMXConnection conn = new JMXConnection(endpoint, port);
+JMXConnection conn = new JMXConnection(endpoint, port, 
username, password);
 
getSSProxy(conn.getMbeanServerConn()).disableScheduledRangeXfers();
 conn.close();
 }
@@ -286,7 +286,7 @@ public class Shuffle extends AbstractJmxClient
 {
 try
 {
-JMXConnection conn = new JMXConnection(host, port);
+JMXConnection conn = new JMXConnection(host, port, username, 
password);
 return getSSProxy(conn.getMbeanServerConn()).getLiveNodes();
 }
 catch (IOException e)
@@ -631,6 +631,8 @@ public class Shuffle extends AbstractJmxClient
 
 String hostName = (cmd.getOptionValue("host") != null) ? 
cmd.getOptionValue("host") : DEFAULT_HOST;
 String port = (cmd.getOptionValue("port") != null) ? 
cmd.getOptionValue("port") : Integer.toString(DEFAULT_JMX_PORT);
+String username = cmd.getOptionValue("username");
+String password = cmd.getOptionV

[1/4] git commit: Change version for 1.2.4 release

2013-04-08 Thread dbrosius
Updated Branches:
  refs/heads/trunk 4902bdc7b -> 39cf55a54


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/trunk
Commit: 2e96d07114dc88f85e56d88f7322a6b91da36c0d
Parents: 22d107f
Author: Sylvain Lebresne 
Authored: Mon Apr 8 18:55:06 2013 +0200
Committer: Sylvain Lebresne 
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 @@
 
 
 
-
+
 
 
 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   Mon, 08 Apr 2013 18:52:23 +0200
+
 cassandra (1.2.3) unstable; urgency=low
 
   * New release



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

2013-04-08 Thread dbrosius
Merge branch 'cassandra-1.2' into trunk


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

Branch: refs/heads/trunk
Commit: 39cf55a543efc0ef9d3cc83ea225a8d068d3d537
Parents: 4902bdc c5820ed
Author: Dave Brosius 
Authored: Mon Apr 8 23:31:30 2013 -0400
Committer: Dave Brosius 
Committed: Mon Apr 8 23:31:30 2013 -0400

--
 CHANGES.txt|1 +
 debian/changelog   |6 ++
 .../apache/cassandra/tools/AbstractJmxClient.java  |   11 ++-
 src/java/org/apache/cassandra/tools/Shuffle.java   |   11 +++
 4 files changed, 20 insertions(+), 9 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/39cf55a5/CHANGES.txt
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/39cf55a5/src/java/org/apache/cassandra/tools/Shuffle.java
--



[3/4] git commit: add 5431 to CHANGES.txt

2013-04-08 Thread dbrosius
add 5431 to CHANGES.txt


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

Branch: refs/heads/trunk
Commit: c5820eda4f74583f099eddcebdb5cc274122765b
Parents: fe89390
Author: Dave Brosius 
Authored: Mon Apr 8 23:22:04 2013 -0400
Committer: Dave Brosius 
Committed: Mon Apr 8 23:22:04 2013 -0400

--
 CHANGES.txt |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/c5820eda/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 81d57ef..76e5853 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -32,6 +32,7 @@
  * Fix potential incremental backups race (CASSANDRA-5410)
  * Fix prepared BATCH statements with batch-level timestamps (CASSANDRA-5415)
  * Allow overriding superuser setup delay (CASSANDRA-5430)
+ * cassandra-shuffle with JMX usernames and passwords (CASSANDRA-5431)
 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)



git commit: add 5431 to CHANGES.txt

2013-04-08 Thread dbrosius
Updated Branches:
  refs/heads/cassandra-1.2 fe8939075 -> c5820eda4


add 5431 to CHANGES.txt


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

Branch: refs/heads/cassandra-1.2
Commit: c5820eda4f74583f099eddcebdb5cc274122765b
Parents: fe89390
Author: Dave Brosius 
Authored: Mon Apr 8 23:22:04 2013 -0400
Committer: Dave Brosius 
Committed: Mon Apr 8 23:22:04 2013 -0400

--
 CHANGES.txt |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/c5820eda/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 81d57ef..76e5853 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -32,6 +32,7 @@
  * Fix potential incremental backups race (CASSANDRA-5410)
  * Fix prepared BATCH statements with batch-level timestamps (CASSANDRA-5415)
  * Allow overriding superuser setup delay (CASSANDRA-5430)
+ * cassandra-shuffle with JMX usernames and passwords (CASSANDRA-5431)
 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)



git commit: support username/password for for jmx in shuffle tool patch by mmichalski reviewed by dbrosius for cassandra-5431

2013-04-08 Thread dbrosius
Updated Branches:
  refs/heads/cassandra-1.2 2e96d0711 -> fe8939075


support username/password for for jmx in shuffle tool
patch by mmichalski reviewed by dbrosius for cassandra-5431


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

Branch: refs/heads/cassandra-1.2
Commit: fe8939075999359b8a26a1a0dcf1a7c7bc4531bb
Parents: 2e96d07
Author: Dave Brosius 
Authored: Mon Apr 8 23:17:37 2013 -0400
Committer: Dave Brosius 
Committed: Mon Apr 8 23:17:37 2013 -0400

--
 .../apache/cassandra/tools/AbstractJmxClient.java  |   11 ++-
 src/java/org/apache/cassandra/tools/Shuffle.java   |   11 +++
 2 files changed, 13 insertions(+), 9 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/fe893907/src/java/org/apache/cassandra/tools/AbstractJmxClient.java
--
diff --git a/src/java/org/apache/cassandra/tools/AbstractJmxClient.java 
b/src/java/org/apache/cassandra/tools/AbstractJmxClient.java
index 3d5cd3a..8241a5b 100644
--- a/src/java/org/apache/cassandra/tools/AbstractJmxClient.java
+++ b/src/java/org/apache/cassandra/tools/AbstractJmxClient.java
@@ -47,6 +47,8 @@ public abstract class AbstractJmxClient implements Closeable
 
 protected final String host;
 protected final int port;
+protected final String username;
+protected final String password;
 protected JMXConnection jmxConn;
 protected PrintStream out = System.out;
 
@@ -54,6 +56,8 @@ public abstract class AbstractJmxClient implements Closeable
 {
 options.addOption("h", "host", true,  "JMX hostname or IP address 
(Default: localhost)");
 options.addOption("p", "port", true,  "JMX port number (Default: 
7199)");
+options.addOption("u", "username", true,  "JMX username");
+options.addOption("pw", "password", true,  "JMX password");
 options.addOption("H", "help", false, "Print help information");
 }
 
@@ -61,6 +65,8 @@ public abstract class AbstractJmxClient implements Closeable
 {
 this.host = (host != null) ? host : DEFAULT_HOST;
 this.port = (port != null) ? port : DEFAULT_JMX_PORT;
+this.username = username;
+this.password = password;
 jmxConn = new JMXConnection(this.host, this.port, username, password);
 }
 
@@ -133,11 +139,6 @@ class JMXConnection
 private JMXConnector jmxc;
 private MBeanServerConnection mbeanServerConn;
 
-JMXConnection(String host, int port) throws IOException
-{
-this(host, port, null, null);
-}
-
 JMXConnection(String host, int port, String username, String password) 
throws IOException
 {
 this.host = host;

http://git-wip-us.apache.org/repos/asf/cassandra/blob/fe893907/src/java/org/apache/cassandra/tools/Shuffle.java
--
diff --git a/src/java/org/apache/cassandra/tools/Shuffle.java 
b/src/java/org/apache/cassandra/tools/Shuffle.java
index 8cf38b9..793d2ee 100644
--- a/src/java/org/apache/cassandra/tools/Shuffle.java
+++ b/src/java/org/apache/cassandra/tools/Shuffle.java
@@ -233,7 +233,7 @@ public class Shuffle extends AbstractJmxClient
 {
 try
 {
-JMXConnection conn = new JMXConnection(endpoint, port);
+JMXConnection conn = new JMXConnection(endpoint, port, 
username, password);
 
getSSProxy(conn.getMbeanServerConn()).enableScheduledRangeXfers();
 conn.close();
 }
@@ -265,7 +265,7 @@ public class Shuffle extends AbstractJmxClient
 {
 try
 {
-JMXConnection conn = new JMXConnection(endpoint, port);
+JMXConnection conn = new JMXConnection(endpoint, port, 
username, password);
 
getSSProxy(conn.getMbeanServerConn()).disableScheduledRangeXfers();
 conn.close();
 }
@@ -286,7 +286,7 @@ public class Shuffle extends AbstractJmxClient
 {
 try
 {
-JMXConnection conn = new JMXConnection(host, port);
+JMXConnection conn = new JMXConnection(host, port, username, 
password);
 return getSSProxy(conn.getMbeanServerConn()).getLiveNodes();
 }
 catch (IOException e)
@@ -631,6 +631,8 @@ public class Shuffle extends AbstractJmxClient
 
 String hostName = (cmd.getOptionValue("host") != null) ? 
cmd.getOptionValue("host") : DEFAULT_HOST;
 String port = (cmd.getOptionValue("port") != null) ? 
cmd.getOptionValue("port") : Integer.toString(DEFAULT_JMX_PORT);
+String userna

[jira] [Comment Edited] (CASSANDRA-5062) Support CAS

2013-04-08 Thread Jonathan Ellis (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13625923#comment-13625923
 ] 

Jonathan Ellis edited comment on CASSANDRA-5062 at 4/9/13 3:10 AM:
---

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

  was (Author: jbellis):
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] [Resolved] (CASSANDRA-5444) TTL does not compact rows

2013-04-08 Thread Brandon Williams (JIRA)

 [ 
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

2013-04-08 Thread Brandon Williams (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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


[jira] [Commented] (CASSANDRA-5431) cassandra-shuffle with JMX usernames and passwords

2013-04-08 Thread Dave Brosius (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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


[Cassandra Wiki] Trivial Update of "BobvrscaW" by BobvrscaW

2013-04-08 Thread Apache Wiki
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 素材されている を作成する、カムバックの間で 並べ替えファッション。<>
<>
My blog: [[http://2013rolexfreeshippig.com/|スーパーコピー時計]]


[jira] [Created] (CASSANDRA-5444) TTL does not compact rows

2013-04-08 Thread Sathish (JIRA)
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 "DarinMcca" by DarinMcca

2013-04-08 Thread Apache Wiki
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.<>
What else? He likes vacationing and checking out new countries like Kitwe.<>
<>
Stop by my website - [[http://bentio.com/luannrqn|Highly recommended Internet 
site]]


[Cassandra Wiki] Trivial Update of "TristanMu" by TristanMu

2013-04-08 Thread Apache Wiki
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.<>
Remember though, cabin tents usually provide more room and even more "walking 
space" inside. <>
<>
<>
<>
My name is Tristan Mueller. I life in Dundee Beach (Australia).<>
<>
My weblog ... [[http://rayzzz.com/ErickaHom|trekking shop]]


[Cassandra Wiki] Trivial Update of "bexozyxkutu088" by bexozyxkutu088

2013-04-08 Thread Apache Wiki
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=diff&rev1=5&rev2=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.<>
+ 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.<>
  <>
+ Review my website 
[[http://scrapebrokers.com/october-autoapprove-scrapebox-list|Clicking Here]]
- <>
- My web site; 
[[http://scrapebrokers.com/tag/scrapebox-autoapprove-list|Recommended Internet 
page]]
  


[jira] [Created] (CASSANDRA-5443) Add CAS CQL support

2013-04-08 Thread Jonathan Ellis (JIRA)
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


[jira] [Created] (CASSANDRA-5441) Add support for read at CL.SERIAL

2013-04-08 Thread Jonathan Ellis (JIRA)
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

2013-04-08 Thread Jonathan Ellis (JIRA)
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] [Commented] (CASSANDRA-5062) Support CAS

2013-04-08 Thread Jonathan Ellis (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-5440) ISE during short reads

2013-04-08 Thread Brandon Williams (JIRA)
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

2013-04-08 Thread Brandon Williams (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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


[Cassandra Wiki] Trivial Update of "Outlines_For_fast_Solutions_Pertaining_to_customized_fat_loss_review" by MarcoS31

2013-04-08 Thread Apache Wiki
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 .<>
<>
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. <>
<>
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. <>
<>
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.<>
<>
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/


[Cassandra Wiki] Trivial Update of "MarcoS31" by MarcoS31

2013-04-08 Thread Apache Wiki
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 Wilt<>
My age: 25<>
Country: Germany<>
Home town: Nohen <>
Post code: 55767<>
Address: Meininger Strasse 96<>
<>
Feel free to surf to my page; 
[[http://www.healthreviewscam.com/somanabolic-muscle-maximizer-review/|muscle 
maximizer somanabolic review]]


[jira] [Commented] (CASSANDRA-5431) cassandra-shuffle with JMX usernames and passwords

2013-04-08 Thread Jonathan Ellis (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.

2013-04-08 Thread Jonathan Ellis (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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


[jira] [Commented] (CASSANDRA-5062) Support CAS

2013-04-08 Thread Jonathan Ellis (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

2013-04-08 Thread Dave Brosius (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Comment Edited] (CASSANDRA-3533) TimeoutException when there is a firewall issue.

2013-04-08 Thread Vijay (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-3533) TimeoutException when there is a firewall issue.

2013-04-08 Thread Vijay (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Commented] (CASSANDRA-5062) Support CAS

2013-04-08 Thread Jonathan Ellis (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-5062) Support CAS

2013-04-08 Thread Jonathan Ellis (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-4932) Agree on a gcbefore/expirebefore value for all replica during validation compaction

2013-04-08 Thread Yuki Morishita (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-4932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Resolved] (CASSANDRA-5427) CustomTThreadPoolServer.java (line 210) Error occurred during processing of message.

2013-04-08 Thread Jonathan Ellis (JIRA)

 [ 
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-5051) Allow automatic cleanup after gc_grace

2013-04-08 Thread Jonathan Ellis (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Comment Edited] (CASSANDRA-5427) CustomTThreadPoolServer.java (line 210) Error occurred during processing of message.

2013-04-08 Thread J.B. Langston (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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:

[jira] [Commented] (CASSANDRA-5427) CustomTThreadPoolServer.java (line 210) Error occurred during processing of message.

2013-04-08 Thread J.B. Langston (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Commented] (CASSANDRA-3533) TimeoutException when there is a firewall issue.

2013-04-08 Thread Jonathan Ellis (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Updated] (CASSANDRA-5431) cassandra-shuffle with JMX usernames and passwords

2013-04-08 Thread Jonathan Ellis (JIRA)

 [ 
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-5436) Binary protocol versioning

2013-04-08 Thread Marcus Eriksson (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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


[Cassandra Wiki] Trivial Update of "EYXNina" by EYXNina

2013-04-08 Thread Apache Wiki
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.<>
Lovely to be a member of this community.<>
I really wish Im useful in some way .<>
<>
Here is my website: 
[[http://lib.ybust.edu.cn/?document_srl=736&mid=sub06_01&sort_index=regdate&order_type=desc|Learn
 Additional]]


[jira] [Updated] (CASSANDRA-5436) Binary protocol versioning

2013-04-08 Thread Marcus Eriksson (JIRA)

 [ 
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


[jira] [Updated] (CASSANDRA-5431) cassandra-shuffle with JMX usernames and passwords

2013-04-08 Thread JIRA

 [ 
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-4932) Agree on a gcbefore/expirebefore value for all replica during validation compaction

2013-04-08 Thread Marcus Eriksson (JIRA)

 [ 
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] [Commented] (CASSANDRA-5437) multiget specific key filtering

2013-04-08 Thread Brandon Williams (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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


[Cassandra Wiki] Trivial Update of "WillieSch" by WillieSch

2013-04-08 Thread Apache Wiki
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).<>
<>
<>
my blog; 
[[http://www.gamermates.de//index.php//index.php//index.php/index.php?page=User&userID=3451|http://www.gamermates.de/]]


[jira] [Commented] (CASSANDRA-5433) Nodetool - Human Readable

2013-04-08 Thread Brandon Williams (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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


[jira] [Commented] (CASSANDRA-4932) Agree on a gcbefore/expirebefore value for all replica during validation compaction

2013-04-08 Thread Yuki Morishita (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-4932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

2013-04-08 Thread Yuki Morishita (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-4932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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


buildbot failure in ASF Buildbot on cassandra-trunk

2013-04-08 Thread buildbot
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 

BUILD FAILED: failed

sincerely,
 -The Buildbot





git commit: fix build post-rebase

2013-04-08 Thread jbellis
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 
Authored: Mon Apr 8 13:36:04 2013 -0500
Committer: Jonathan Ellis 
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 Collection markAllCompacting()
+public Iterable markAllCompacting()
 {
-Callable> callable = new 
Callable>()
+Callable> callable = new 
Callable>()
 {
-public Collection call() throws Exception
+public Iterable call() throws Exception
 {
 assert data.getCompacting().isEmpty() : data.getCompacting();
-Collection sstables = 
AbstractCompactionStrategy.filterSuspectSSTables(getSSTables());
-if (sstables.isEmpty())
+Iterable 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(Collection sstables)
+public boolean markCompacting(Iterable sstables)
 {
-assert sstables != null && !sstables.isEmpty();
+assert sstables != null && !Iterables.isEmpty(sstables);
 
 View currentView = view.get();
 Set 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(Collection unmark)
+public void unmarkCompacting(Iterable unmark)
 {
 if (!cfstore.isValid())
 {
@@ -533,7 +533,7 @@ public class DataTracker
 return new View(memtable, memtablesPendingFlush, sstables, 
compactingNew, intervalTree);
 }
 
-public View unmarkCompacting(Collection tounmark)
+public View unmarkCompacting(Iterable tounmark)
 {
 Set compactingNew = 
ImmutableSet.copyOf(Sets.difference(compacting, ImmutableSet.copyOf(tounmark)));
 return new View(memtable, memtablesPendingFlush, sstables, 
compactingNew, intervalTree);

http://git-wip-us.apache.org/repos/asf/cassandra/blob/4902bdc7/src/java/org/apache/cassandra/db/compaction/AbstractCompactionTask.java
--
di

[jira] [Resolved] (CASSANDRA-5371) Perform size-tiered compactions in L0

2013-04-08 Thread Jonathan Ellis (JIRA)

 [ 
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


[jira] [Created] (CASSANDRA-5439) allow STCS options to apply to the L0 compaction performed by LCS

2013-04-08 Thread Jonathan Ellis (JIRA)
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


[2/2] git commit: r/m unused SimpleFuture

2013-04-08 Thread jbellis
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 
Authored: Mon Apr 8 13:20:11 2013 -0500
Committer: Jonathan Ellis 
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

2013-04-08 Thread jbellis
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 
Authored: Mon Apr 8 13:19:40 2013 -0500
Committer: Jonathan Ellis 
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, Collection 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 Iterable 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;
@@ -73,6 +74,18 @@ public class DataTracker
 return view.

[jira] [Commented] (CASSANDRA-5431) cassandra-shuffle with JMX usernames and passwords

2013-04-08 Thread Eric Dong (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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


Git Push Summary

2013-04-08 Thread slebresne
Updated Tags:  refs/tags/1.2.4-tentative [created] 2e96d0711


git commit: Change version for 1.2.4 release

2013-04-08 Thread slebresne
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 
Authored: Mon Apr 8 18:55:06 2013 +0200
Committer: Sylvain Lebresne 
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 @@
 
 
 
-
+
 
 
 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   Mon, 08 Apr 2013 18:52:23 +0200
+
 cassandra (1.2.3) unstable; urgency=low
 
   * New release



[jira] [Commented] (CASSANDRA-5062) Support CAS

2013-04-08 Thread Sylvain Lebresne (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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


[jira] [Commented] (CASSANDRA-4885) Remove or rework per-row bloom filters

2013-04-08 Thread Jason Brown (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-4885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

2013-04-08 Thread Jason Brown (JIRA)

 [ 
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] [Updated] (CASSANDRA-5431) cassandra-shuffle with JMX usernames and passwords

2013-04-08 Thread JIRA

 [ 
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


[1/2] git commit: Allow overriding superuser setup delay

2013-04-08 Thread aleksey
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 
Authored: Mon Apr 8 19:16:06 2013 +0300
Committer: Aleksey Yeschenko 
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 static final int GENSALT_LOG

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

2013-04-08 Thread aleksey
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 
Authored: Mon Apr 8 19:17:47 2013 +0300
Committer: Aleksey Yeschenko 
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
--



git commit: Allow overriding superuser setup delay

2013-04-08 Thread aleksey
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 
Authored: Mon Apr 8 19:16:06 2013 +0300
Committer: Aleksey Yeschenko 
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 static final

[Cassandra Wiki] Trivial Update of "JewelBeta" by JewelBeta

2013-04-08 Thread Apache Wiki
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.<>
I enjoy of finally being a part of apache.org.<>
<>
<>
I just wish I am useful in one way .<>
<>
Take a look at my webpage 
[[http://ucgi.mishima-stable.co.jp/cgi-bin/aska.cgi|please click the next page]]


[jira] [Commented] (CASSANDRA-5430) Make Auth.SUPERUSER_SETUP_DELAY configurable

2013-04-08 Thread Jonathan Ellis (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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


[jira] [Updated] (CASSANDRA-5430) Make Auth.SUPERUSER_SETUP_DELAY configurable

2013-04-08 Thread Aleksey Yeschenko (JIRA)

 [ 
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


[Cassandra Wiki] Trivial Update of "LenoreRut" by LenoreRut

2013-04-08 Thread Apache Wiki
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 michigan<>
How can they possibly be indifferent to your urban center that will 
increases quicker compared to all other locations asia?<>
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.<>
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. <>
property photography<>
Several 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?<>
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.<>
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]] <>
real estate property on-line<>
There 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.<>
<>
<>
property san antonio<>
First, 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.<>
<>
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_blog&view=comments&pid=34655&Itemid=0
 http://www.business-market.eu/index.php?<>
<>
do=/blog/397591/bracket-enjoyable-home-rentals/<>
http://mysexyvidz.com/index.php?do=/blog/19750/housing-ask/<>
<>
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-5220) Repair improvements when using vnodes

2013-04-08 Thread Jonathan Ellis (JIRA)

 [ 
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


[jira] [Updated] (CASSANDRA-4316) Compaction Throttle too bursty with large rows

2013-04-08 Thread Jonathan Ellis (JIRA)

 [ 
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] [Commented] (CASSANDRA-5371) Perform size-tiered compactions in L0

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

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Resolved] (CASSANDRA-5277) rename AntiEntropyService

2013-04-08 Thread Jonathan Ellis (JIRA)

 [ 
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-4885) Remove or rework per-row bloom filters

2013-04-08 Thread Jonathan Ellis (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-4885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Commented] (CASSANDRA-5430) Make Auth.SUPERUSER_SETUP_DELAY configurable

2013-04-08 Thread Jonathan Ellis (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-5430) Make Auth.SUPERUSER_SETUP_DELAY configurable

2013-04-08 Thread Aleksey Yeschenko (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

2013-04-08 Thread Jonathan Ellis (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-4914) Aggregate functions in CQL

2013-04-08 Thread Sylvain Lebresne (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-4914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Resolved] (CASSANDRA-5438) possibly wrong stream id when cassandra reports an error

2013-04-08 Thread Sylvain Lebresne (JIRA)

 [ 
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-5436) Binary protocol versioning

2013-04-08 Thread Sylvain Lebresne (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Created] (CASSANDRA-5438) possibly wrong stream id when cassandra reports an error

2013-04-08 Thread Sorin Manolache (JIRA)
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-5430) Make Auth.SUPERUSER_SETUP_DELAY configurable

2013-04-08 Thread Aleksey Yeschenko (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-5430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Updated] (CASSANDRA-5349) Add binary protocol support for bind variables to non-prepared statements

2013-04-08 Thread Sylvain Lebresne (JIRA)

 [ 
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


buildbot success in ASF Buildbot on cassandra-trunk

2013-04-08 Thread buildbot
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 

Build succeeded!

sincerely,
 -The Buildbot





[Cassandra Wiki] Trivial Update of "Leading_Digital_Cameras_For_2012" by JacklynHa

2013-04-08 Thread Apache Wiki
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.<>
<>
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.<>
<>
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.<>
<>
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.<>
<>
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.<>
<>
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.<>
<>
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.<>
<>
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.


[Cassandra Wiki] Trivial Update of "JacklynHa" by JacklynHa

2013-04-08 Thread Apache Wiki
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.<>
You can always discover his website here: 
http://www.xoomshop.com/B007261A36/Samsung_DV300F_Dual_View_Smart_Camera___Black_EC_DV300FBPBUS.html<>
<>
Here is my site 
[[http://www.xoomshop.com/B007261A36/Samsung_DV300F_Dual_View_Smart_Camera___Black_EC_DV300FBPBUS.html|click
 through the next webpage]]


[jira] [Updated] (CASSANDRA-5250) Improve LeveledScanner work estimation

2013-04-08 Thread Jeremy Hanna (JIRA)

 [ 
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=13577420&page=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


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

2013-04-08 Thread aleksey
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 
Authored: Mon Apr 8 15:58:24 2013 +0300
Committer: Aleksey Yeschenko 
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
  Map, IMutation> mutations = new 
HashMap, 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

2013-04-08 Thread aleksey
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 
Authored: Mon Apr 8 15:46:58 2013 +0300
Committer: Aleksey Yeschenko 
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
 Map, IMutation> mutations = new 
HashMap, 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");



git commit: Fix prepared BATCH statements with batch-level timestamps

2013-04-08 Thread aleksey
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 
Authored: Mon Apr 8 15:46:58 2013 +0300
Committer: Aleksey Yeschenko 
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
 Map, IMutation> mutations = new 
HashMap, 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");



[Cassandra Wiki] Trivial Update of "AnnettaCo" by AnnettaCo

2013-04-08 Thread Apache Wiki
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=diff&rev1=1&rev2=3

- I am 18 years old and my name is Annetta Colby.<>
- I life in Vaterstetten (Germany).<>
+ My name: Brenda Ball<>
+ Age: 28<>
+ Country: United States<>
+ Town: Florida <>
+ ZIP: 43545<>
+ Street: 2045 Hill Street<>
  <>
- 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_blog&view=comments&pid=48772&Itemid=0|Read
 the Full Article]]
  


[Cassandra Wiki] Trivial Update of "AnnmarieH" by AnnmarieH

2013-04-08 Thread Apache Wiki
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.<>
Last but not least the thing that he treasure most is spending time with his 
companions.<>
<>
Also visit my site [[http://spazzam1.com/profile/laurenekea|click the following 
page]]


  1   2   >