[jira] [Commented] (CASSANDRA-2540) Data reads by default
[
https://issues.apache.org/jira/browse/CASSANDRA-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13026880#comment-13026880
]
Terje Marthinussen commented on CASSANDRA-2540:
---
Would it make sense to make dynamic snitch "react" to "digest but not data"
error directly to improve recovery time and why do we need to wait for the
100ms to make dynamic snitch work?
Couldn't we add a load balancer like function that would detect if a node has a
significant number of outstanding requests on node 1 vs. 2 and 3, then send to
node 2 instead?
Overall, I am not asking for a round robin load balancer though... (not good
for caching)
The digest function may also in some cases maybe be made dynamic based on the
size of the data being read. That is, just send the data for small data sizes
and use digests for large responses?
No, I don't know all the details on how this part of the code work, so my
suggestions may be totally wrong :)
I do wonder however if we get enough of these timeouts to actually be a
problem. If there is a couple of delays in latencies for a few seconds 2-3
times a week/month, no problem.
However, if we have so many of these errors that people see them many times a
day, it would seem like this is a performance problem somewhere in cassandra
which should be fixed rather than applying some patchwork which hide it...
> Data reads by default
> -
>
> Key: CASSANDRA-2540
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2540
> Project: Cassandra
> Issue Type: Wish
>Reporter: Stu Hood
>Priority: Minor
>
> The intention of digest vs data reads is to save bandwidth in the read path
> at the cost of latency, but I expect that this has been a premature
> optimization.
> * Data requested by a read will often be within an order of magnitude of the
> digest size, and a failed digest means extra roundtrips, more bandwidth
> * The [digest reads but not your data
> read|https://issues.apache.org/jira/browse/CASSANDRA-2282?focusedCommentId=13004656&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13004656]
> problem means failing QUORUM reads because a single node is unavailable, and
> would require eagerly re-requesting at some fraction of your timeout
> * Saving bandwidth in cross datacenter usecases comes at huge cost to
> latency, but since both constraints change proportionally (enough), the
> tradeoff is not clear
> Some options:
> # Add an option to use digest reads
> # Remove digest reads entirely (and/or punt and make them a runtime
> optimization based on data size in the future)
> # Continue to use digest reads, but send them to {{N - R}} nodes for
> (somewhat) more predicatable behavior with QUORUM
> \\
> The outcome of data-reads-by-default should be significantly improved
> latency, with a moderate increase in bandwidth usage for large reads.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-1278) Make bulk loading into Cassandra less crappy, more pluggable
[ https://issues.apache.org/jira/browse/CASSANDRA-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthew F. Dennis updated CASSANDRA-1278: - Comment: was deleted (was: The above numbers are correct, but at RF=1 (I mistyped it in IM). At both RF=1 and RF=3 there were 5 M1.XL C* nodes and 20 M1.XL proxy nodes, each doing 10M inserts. At RF=1 C* nodes bump up against max CPU while the proxies are running from building indexes/filters and compacting. The nodes sustain ~150Mb/s incoming traffic each. All the proxies finished between 810 and 825 seconds. With 20 proxies + 10M inserts/proxy * RF=1 that is 200M inserts across 4 * 20 cores on the proxies or 4 * 5 cores when measured by cluster cores resulting in a bit over 3K inserts/sec/core on the proxies and a bit over 12K "effective inserts"/sec/core on the cluster. At RF=3 the results are as expected, taking about 2560 seconds to finish (so about 100 seconds longer than expected when increasing from RF=1). This is just shy of 3K inserts/sec/core on the proxies and little under 12K "effective inserts"/sec/core on the cluster. As it looked like 20 proxies maxed out 5 nodes at RF=1 one would expect RF=3 to take roughly 3 times as long. Network traffic was more variable though at RF=3 as it bounced between 80-200 Mb/s. There were no timeouts in either case. ) > Make bulk loading into Cassandra less crappy, more pluggable > > > Key: CASSANDRA-1278 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1278 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Jeremy Hanna >Assignee: Matthew F. Dennis > Fix For: 0.8.1 > > Attachments: 1278-cassandra-0.7-v2.txt, 1278-cassandra-0.7.1.txt, > 1278-cassandra-0.7.txt > > Original Estimate: 40h > Time Spent: 40h 40m > Remaining Estimate: 0h > > Currently bulk loading into Cassandra is a black art. People are either > directed to just do it responsibly with thrift or a higher level client, or > they have to explore the contrib/bmt example - > http://wiki.apache.org/cassandra/BinaryMemtable That contrib module requires > delving into the code to find out how it works and then applying it to the > given problem. Using either method, the user also needs to keep in mind that > overloading the cluster is possible - which will hopefully be addressed in > CASSANDRA-685 > This improvement would be to create a contrib module or set of documents > dealing with bulk loading. Perhaps it could include code in the Core to make > it more pluggable for external clients of different types. > It is just that this is something that many that are new to Cassandra need to > do - bulk load their data into Cassandra. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-1278) Make bulk loading into Cassandra less crappy, more pluggable
[ https://issues.apache.org/jira/browse/CASSANDRA-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13026840#comment-13026840 ] Matthew F. Dennis commented on CASSANDRA-1278: -- The above numbers are correct, but at RF=1 (I mistyped it in IM). At both RF=1 and RF=3 there were 5 M1.XL C* nodes and 20 M1.XL proxy nodes, each doing 10M inserts. At RF=1 C* nodes bump up against max CPU while the proxies are running from building indexes/filters and compacting. The nodes sustain ~150Mb/s incoming traffic each. All the proxies finished between 810 and 825 seconds. With 20 proxies * 10M inserts/proxy * RF=1 that is 200M inserts across 4 * 20 cores on the proxies or 4 * 5 cores when measured by cluster cores resulting in a bit over 3K inserts/sec/core on the proxies and a bit over 12K "effective inserts"/sec/core on the cluster. At RF=3 the results are as expected, taking about 2560 seconds to finish (so about 100 seconds longer than expected when increasing from RF=1). This is just shy of 3K inserts/sec/core on the proxies and little under 12K "effective inserts"/sec/core on the cluster. As it looked like 20 proxies maxed out 5 nodes at RF=1 one would expect RF=3 to take roughly 3 times as long. Network traffic was more variable though at RF=3 as it bounced between 80-200 Mb/s. There were no timeouts in either case. > Make bulk loading into Cassandra less crappy, more pluggable > > > Key: CASSANDRA-1278 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1278 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Jeremy Hanna >Assignee: Matthew F. Dennis > Fix For: 0.8.1 > > Attachments: 1278-cassandra-0.7-v2.txt, 1278-cassandra-0.7.1.txt, > 1278-cassandra-0.7.txt > > Original Estimate: 40h > Time Spent: 40h 40m > Remaining Estimate: 0h > > Currently bulk loading into Cassandra is a black art. People are either > directed to just do it responsibly with thrift or a higher level client, or > they have to explore the contrib/bmt example - > http://wiki.apache.org/cassandra/BinaryMemtable That contrib module requires > delving into the code to find out how it works and then applying it to the > given problem. Using either method, the user also needs to keep in mind that > overloading the cluster is possible - which will hopefully be addressed in > CASSANDRA-685 > This improvement would be to create a contrib module or set of documents > dealing with bulk loading. Perhaps it could include code in the Core to make > it more pluggable for external clients of different types. > It is just that this is something that many that are new to Cassandra need to > do - bulk load their data into Cassandra. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-1278) Make bulk loading into Cassandra less crappy, more pluggable
[ https://issues.apache.org/jira/browse/CASSANDRA-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13026838#comment-13026838 ] Matthew F. Dennis commented on CASSANDRA-1278: -- The above numbers are correct, but at RF=1 (I mistyped it in IM). At both RF=1 and RF=3 there were 5 M1.XL C* nodes and 20 M1.XL proxy nodes, each doing 10M inserts. At RF=1 C* nodes bump up against max CPU while the proxies are running from building indexes/filters and compacting. The nodes sustain ~150Mb/s incoming traffic each. All the proxies finished between 810 and 825 seconds. With 20 proxies + 10M inserts/proxy * RF=1 that is 200M inserts across 4 * 20 cores on the proxies or 4 * 5 cores when measured by cluster cores resulting in a bit over 3K inserts/sec/core on the proxies and a bit over 12K "effective inserts"/sec/core on the cluster. At RF=3 the results are as expected, taking about 2560 seconds to finish (so about 100 seconds longer than expected when increasing from RF=1). This is just shy of 3K inserts/sec/core on the proxies and little under 12K "effective inserts"/sec/core on the cluster. As it looked like 20 proxies maxed out 5 nodes at RF=1 one would expect RF=3 to take roughly 3 times as long. Network traffic was more variable though at RF=3 as it bounced between 80-200 Mb/s. There were no timeouts in either case. > Make bulk loading into Cassandra less crappy, more pluggable > > > Key: CASSANDRA-1278 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1278 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Jeremy Hanna >Assignee: Matthew F. Dennis > Fix For: 0.8.1 > > Attachments: 1278-cassandra-0.7-v2.txt, 1278-cassandra-0.7.1.txt, > 1278-cassandra-0.7.txt > > Original Estimate: 40h > Time Spent: 40h 40m > Remaining Estimate: 0h > > Currently bulk loading into Cassandra is a black art. People are either > directed to just do it responsibly with thrift or a higher level client, or > they have to explore the contrib/bmt example - > http://wiki.apache.org/cassandra/BinaryMemtable That contrib module requires > delving into the code to find out how it works and then applying it to the > given problem. Using either method, the user also needs to keep in mind that > overloading the cluster is possible - which will hopefully be addressed in > CASSANDRA-685 > This improvement would be to create a contrib module or set of documents > dealing with bulk loading. Perhaps it could include code in the Core to make > it more pluggable for external clients of different types. > It is just that this is something that many that are new to Cassandra need to > do - bulk load their data into Cassandra. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-1278) Make bulk loading into Cassandra less crappy, more pluggable
[ https://issues.apache.org/jira/browse/CASSANDRA-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthew F. Dennis updated CASSANDRA-1278: - Attachment: (was: 1278-cassandra-0.7-v2.txt) > Make bulk loading into Cassandra less crappy, more pluggable > > > Key: CASSANDRA-1278 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1278 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Jeremy Hanna >Assignee: Matthew F. Dennis > Fix For: 0.8.1 > > Attachments: 1278-cassandra-0.7-v2.txt, 1278-cassandra-0.7.1.txt, > 1278-cassandra-0.7.txt > > Original Estimate: 40h > Time Spent: 40h 40m > Remaining Estimate: 0h > > Currently bulk loading into Cassandra is a black art. People are either > directed to just do it responsibly with thrift or a higher level client, or > they have to explore the contrib/bmt example - > http://wiki.apache.org/cassandra/BinaryMemtable That contrib module requires > delving into the code to find out how it works and then applying it to the > given problem. Using either method, the user also needs to keep in mind that > overloading the cluster is possible - which will hopefully be addressed in > CASSANDRA-685 > This improvement would be to create a contrib module or set of documents > dealing with bulk loading. Perhaps it could include code in the Core to make > it more pluggable for external clients of different types. > It is just that this is something that many that are new to Cassandra need to > do - bulk load their data into Cassandra. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-1278) Make bulk loading into Cassandra less crappy, more pluggable
[ https://issues.apache.org/jira/browse/CASSANDRA-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthew F. Dennis updated CASSANDRA-1278: - Attachment: 1278-cassandra-0.7-v2.txt rebased v2 attached > Make bulk loading into Cassandra less crappy, more pluggable > > > Key: CASSANDRA-1278 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1278 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Jeremy Hanna >Assignee: Matthew F. Dennis > Fix For: 0.8.1 > > Attachments: 1278-cassandra-0.7-v2.txt, 1278-cassandra-0.7.1.txt, > 1278-cassandra-0.7.txt > > Original Estimate: 40h > Time Spent: 40h 40m > Remaining Estimate: 0h > > Currently bulk loading into Cassandra is a black art. People are either > directed to just do it responsibly with thrift or a higher level client, or > they have to explore the contrib/bmt example - > http://wiki.apache.org/cassandra/BinaryMemtable That contrib module requires > delving into the code to find out how it works and then applying it to the > given problem. Using either method, the user also needs to keep in mind that > overloading the cluster is possible - which will hopefully be addressed in > CASSANDRA-685 > This improvement would be to create a contrib module or set of documents > dealing with bulk loading. Perhaps it could include code in the Core to make > it more pluggable for external clients of different types. > It is just that this is something that many that are new to Cassandra need to > do - bulk load their data into Cassandra. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2581) Rebuffer called excessively during seeks
[ https://issues.apache.org/jira/browse/CASSANDRA-2581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet updated CASSANDRA-2581: -- Attachment: 0001-Rebuffer-called-excessively-during-seeks.patch > Rebuffer called excessively during seeks > > > Key: CASSANDRA-2581 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2581 > Project: Cassandra > Issue Type: Bug >Affects Versions: 0.8.1 >Reporter: Chris Goffinet >Assignee: Chris Goffinet >Priority: Minor > Attachments: 0001-Rebuffer-called-excessively-during-seeks.patch > > > When doing an strace tonight, I noticed during memtable flushes that we were > only writing 1KB per every write() system call...After diving more into it, > it's because of a bug in the seek() code. > if (newPosition >= bufferOffset + validBufferBytes || newPosition < > bufferOffset) > vs. > if (newPosition > (bufferOffset + validBufferBytes) || newPosition < > bufferOffset) > Two things I noticed, we shouldn't need to rebuffer if newPosition is equal > to bufferOffset + validBufferBytes, second the evaluation was doing > (newPosition >= bufferOffset) + validBufferBytes which always seemed to be > true. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2581) Rebuffer called excessively during seeks
Rebuffer called excessively during seeks Key: CASSANDRA-2581 URL: https://issues.apache.org/jira/browse/CASSANDRA-2581 Project: Cassandra Issue Type: Bug Reporter: Chris Goffinet Assignee: Chris Goffinet Priority: Minor When doing an strace tonight, I noticed during memtable flushes that we were only writing 1KB per every write() system call...After diving more into it, it's because of a bug in the seek() code. if (newPosition >= bufferOffset + validBufferBytes || newPosition < bufferOffset) vs. if (newPosition > (bufferOffset + validBufferBytes) || newPosition < bufferOffset) Two things I noticed, we shouldn't need to rebuffer if newPosition is equal to bufferOffset + validBufferBytes, second the evaluation was doing (newPosition >= bufferOffset) + validBufferBytes which always seemed to be true. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2581) Rebuffer called excessively during seeks
[ https://issues.apache.org/jira/browse/CASSANDRA-2581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Goffinet updated CASSANDRA-2581: -- Affects Version/s: 0.8.1 > Rebuffer called excessively during seeks > > > Key: CASSANDRA-2581 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2581 > Project: Cassandra > Issue Type: Bug >Affects Versions: 0.8.1 >Reporter: Chris Goffinet >Assignee: Chris Goffinet >Priority: Minor > > When doing an strace tonight, I noticed during memtable flushes that we were > only writing 1KB per every write() system call...After diving more into it, > it's because of a bug in the seek() code. > if (newPosition >= bufferOffset + validBufferBytes || newPosition < > bufferOffset) > vs. > if (newPosition > (bufferOffset + validBufferBytes) || newPosition < > bufferOffset) > Two things I noticed, we shouldn't need to rebuffer if newPosition is equal > to bufferOffset + validBufferBytes, second the evaluation was doing > (newPosition >= bufferOffset) + validBufferBytes which always seemed to be > true. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-1278) Make bulk loading into Cassandra less crappy, more pluggable
[ https://issues.apache.org/jira/browse/CASSANDRA-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13026819#comment-13026819 ] Jonathan Ellis commented on CASSANDRA-1278: --- Matt responded on IM, bq. RF=3, 20 proxies, everything on XL nodes seems to be the magic number. C* bumps up and off max CPU while the proxies are running. each C* node sustains ~150Mb/s incoming. All the proxies finished at roughly the same time (between 810 and 825 seconds). There were 200M keys inserted by the stress into the proxies averaging a bit over 3000 inserts/sec/core on the proxies with an "effective" insert rate on the cluster of 12K+ /sec/core. > Make bulk loading into Cassandra less crappy, more pluggable > > > Key: CASSANDRA-1278 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1278 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Jeremy Hanna >Assignee: Matthew F. Dennis > Fix For: 0.8.1 > > Attachments: 1278-cassandra-0.7-v2.txt, 1278-cassandra-0.7.1.txt, > 1278-cassandra-0.7.txt > > Original Estimate: 40h > Time Spent: 40h 40m > Remaining Estimate: 0h > > Currently bulk loading into Cassandra is a black art. People are either > directed to just do it responsibly with thrift or a higher level client, or > they have to explore the contrib/bmt example - > http://wiki.apache.org/cassandra/BinaryMemtable That contrib module requires > delving into the code to find out how it works and then applying it to the > given problem. Using either method, the user also needs to keep in mind that > overloading the cluster is possible - which will hopefully be addressed in > CASSANDRA-685 > This improvement would be to create a contrib module or set of documents > dealing with bulk loading. Perhaps it could include code in the Core to make > it more pluggable for external clients of different types. > It is just that this is something that many that are new to Cassandra need to > do - bulk load their data into Cassandra. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2578) stress performance is artificially limited
[ https://issues.apache.org/jira/browse/CASSANDRA-2578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13026810#comment-13026810 ] Hudson commented on CASSANDRA-2578: --- Integrated in Cassandra-0.7 #461 (See [https://builds.apache.org/hudson/job/Cassandra-0.7/461/]) cache generateValues in Inserter/IndexedRangeSlicer. Patch by Pavel Yaskevich, reviewed by brandonwilliams for CASSANDRA-2578 > stress performance is artificially limited > -- > > Key: CASSANDRA-2578 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2578 > Project: Cassandra > Issue Type: Bug > Components: Tools >Affects Versions: 0.7.4 >Reporter: Brandon Williams >Assignee: Pavel Yaskevich > Fix For: 0.7.6 > > Attachments: CASSANDRA-2578-0.7.patch, CASSANDRA-2578.patch > > > With stress I only get about 7k inserts/s against a single server, and the > load and cpu usage from stress is higher than the server. Pystress gets > 15-20k inserts/s against the same machine. Stress isn't cpu-limited however, > so there must be something else holding it back. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2580) stress will not use existing keyspaces
stress will not use existing keyspaces -- Key: CASSANDRA-2580 URL: https://issues.apache.org/jira/browse/CASSANDRA-2580 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.8 beta 1 Reporter: Brandon Williams Assignee: Pavel Yaskevich cassandra-3:/srv/cassandra# tools/stress/bin/stress -n 1 -d cassandra-2 -i 1 -o insert Created keyspaces. Sleeping 1s for propagation. total,interval_op_rate,interval_key_rate,avg_latency,elapsed_time 1,1,1,0.049,0 cassandra-3:/srv/cassandra# tools/stress/bin/stress -n 1 -d cassandra-2 -i 1 -o insert Unable to create stress keyspace: Keyspace already exists. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2578) stress performance is artificially limited
[ https://issues.apache.org/jira/browse/CASSANDRA-2578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-2578: Affects Version/s: (was: 0.8 beta 1) 0.7.4 Fix Version/s: 0.7.6 > stress performance is artificially limited > -- > > Key: CASSANDRA-2578 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2578 > Project: Cassandra > Issue Type: Bug > Components: Tools >Affects Versions: 0.7.4 >Reporter: Brandon Williams >Assignee: Pavel Yaskevich > Fix For: 0.7.6 > > Attachments: CASSANDRA-2578-0.7.patch, CASSANDRA-2578.patch > > > With stress I only get about 7k inserts/s against a single server, and the > load and cpu usage from stress is higher than the server. Pystress gets > 15-20k inserts/s against the same machine. Stress isn't cpu-limited however, > so there must be something else holding it back. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1097668 - in /cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/operations: IndexedRangeSlicer.java Inserter.java
Author: brandonwilliams
Date: Fri Apr 29 01:38:40 2011
New Revision: 1097668
URL: http://svn.apache.org/viewvc?rev=1097668&view=rev
Log:
cache generateValues in Inserter/IndexedRangeSlicer.
Patch by Pavel Yaskevich, reviewed by brandonwilliams for CASSANDRA-2578
Modified:
cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/operations/IndexedRangeSlicer.java
cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/operations/Inserter.java
Modified:
cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/operations/IndexedRangeSlicer.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/operations/IndexedRangeSlicer.java?rev=1097668&r1=1097667&r2=1097668&view=diff
==
---
cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/operations/IndexedRangeSlicer.java
(original)
+++
cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/operations/IndexedRangeSlicer.java
Fri Apr 29 01:38:40 2011
@@ -28,6 +28,8 @@ import java.util.List;
public class IndexedRangeSlicer extends Operation
{
+private static List values = null;
+
public IndexedRangeSlicer(int index)
{
super(index);
@@ -35,12 +37,14 @@ public class IndexedRangeSlicer extends
public void run(Cassandra.Client client) throws IOException
{
+if (values == null)
+values = generateValues();
+
String format = "%0" + session.getTotalKeysLength() + "d";
SlicePredicate predicate = new SlicePredicate().setSlice_range(new
SliceRange(ByteBufferUtil.EMPTY_BYTE_BUFFER,
ByteBufferUtil.EMPTY_BYTE_BUFFER,
false, session.getColumnsPerKey()));
-List values = super.generateValues();
ColumnParent parent = new ColumnParent("Standard1");
int expectedPerValue = session.getNumKeys() / values.size();
Modified:
cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/operations/Inserter.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/operations/Inserter.java?rev=1097668&r1=1097667&r2=1097668&view=diff
==
---
cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/operations/Inserter.java
(original)
+++
cassandra/branches/cassandra-0.7/contrib/stress/src/org/apache/cassandra/contrib/stress/operations/Inserter.java
Fri Apr 29 01:38:40 2011
@@ -31,6 +31,7 @@ import java.util.Map;
public class Inserter extends Operation
{
+private static List values = null;
public Inserter(int index)
{
@@ -39,7 +40,9 @@ public class Inserter extends Operation
public void run(Cassandra.Client client) throws IOException
{
-List values = generateValues();
+if (values == null)
+values = generateValues();
+
List columns = new ArrayList();
List superColumns = new ArrayList();
[jira] [Commented] (CASSANDRA-2536) Schema disagreements when using connections to multiple hosts
[ https://issues.apache.org/jira/browse/CASSANDRA-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13026801#comment-13026801 ] Jonathan Ellis commented on CASSANDRA-2536: --- bq. it seems to me that clients making schema modifications are more likely to be centralized I would have also argued that they are likely to use the same connection (to the same server), and look where that got us. :) bq. I personally think the timestamp comparison is good enough for now I am okay with this. What do you think, Gary? (Nit: the exception message says "older" but the comparison is "older or equal.") > Schema disagreements when using connections to multiple hosts > - > > Key: CASSANDRA-2536 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2536 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.8 beta 1 > Environment: Two node 0.8-beta1 cluster with one seed and JNA. >Reporter: Tyler Hobbs >Assignee: Tyler Hobbs > Attachments: 2536-compare-timestamp.txt, schema_disagree.py > > > If you have two thrift connections open to different nodes and you create a > KS using the first, then a CF in that KS using the second, you wind up with a > schema disagreement even if you wait/sleep after creating the KS. > The attached script reproduces the issue using pycassa (1.0.6 should work > fine, although it has the 0.7 thrift-gen code). It's also reproducible by > hand with two cassandra-cli sessions. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2578) stress performance is artificially limited
[ https://issues.apache.org/jira/browse/CASSANDRA-2578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-2578: --- Attachment: CASSANDRA-2578-0.7.patch > stress performance is artificially limited > -- > > Key: CASSANDRA-2578 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2578 > Project: Cassandra > Issue Type: Bug > Components: Tools >Affects Versions: 0.8 beta 1 >Reporter: Brandon Williams >Assignee: Pavel Yaskevich > Attachments: CASSANDRA-2578-0.7.patch, CASSANDRA-2578.patch > > > With stress I only get about 7k inserts/s against a single server, and the > load and cpu usage from stress is higher than the server. Pystress gets > 15-20k inserts/s against the same machine. Stress isn't cpu-limited however, > so there must be something else holding it back. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2578) stress performance is artificially limited
[ https://issues.apache.org/jira/browse/CASSANDRA-2578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-2578: --- Attachment: CASSANDRA-2578.patch caching generateValues in Inserter/IndexedRangeSlicer. Patch against trunk but can be applied to cassandra-0.8 without any problem. > stress performance is artificially limited > -- > > Key: CASSANDRA-2578 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2578 > Project: Cassandra > Issue Type: Bug > Components: Tools >Affects Versions: 0.8 beta 1 >Reporter: Brandon Williams >Assignee: Pavel Yaskevich > Attachments: CASSANDRA-2578.patch > > > With stress I only get about 7k inserts/s against a single server, and the > load and cpu usage from stress is higher than the server. Pystress gets > 15-20k inserts/s against the same machine. Stress isn't cpu-limited however, > so there must be something else holding it back. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2579) apache-cassandra-cql-*.jar as a separate artifact
[ https://issues.apache.org/jira/browse/CASSANDRA-2579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Evans updated CASSANDRA-2579: -- Attachment: v1-0001-CASSANDRA-2579-apache-cassandra-cql-.jar-as-a-separate.txt > apache-cassandra-cql-*.jar as a separate artifact > - > > Key: CASSANDRA-2579 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2579 > Project: Cassandra > Issue Type: Bug > Components: Packaging, Tools >Affects Versions: 0.8 beta 1 >Reporter: Eric Evans >Assignee: Eric Evans >Priority: Minor > Labels: cql > Fix For: 0.8.0 > > Attachments: > v1-0001-CASSANDRA-2579-apache-cassandra-cql-.jar-as-a-separate.txt > > > The CQL jar should not be stored in the -bin.tar.gz artifact, but created > separately with its own checksum files. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2579) apache-cassandra-cql-*.jar as a separate artifact
apache-cassandra-cql-*.jar as a separate artifact - Key: CASSANDRA-2579 URL: https://issues.apache.org/jira/browse/CASSANDRA-2579 Project: Cassandra Issue Type: Bug Components: Packaging, Tools Affects Versions: 0.8 beta 1 Reporter: Eric Evans Assignee: Eric Evans Priority: Minor Fix For: 0.8.0 Attachments: v1-0001-CASSANDRA-2579-apache-cassandra-cql-.jar-as-a-separate.txt The CQL jar should not be stored in the -bin.tar.gz artifact, but created separately with its own checksum files. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-2459) move SSTableScanner to use SSTableReader.dfile instead of BRAF
[ https://issues.apache.org/jira/browse/CASSANDRA-2459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich resolved CASSANDRA-2459. Resolution: Won't Fix > move SSTableScanner to use SSTableReader.dfile instead of BRAF > -- > > Key: CASSANDRA-2459 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2459 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Pavel Yaskevich >Assignee: Pavel Yaskevich >Priority: Minor > Fix For: 1.0 > > > That can give us the following benefits: > a). don't need to skip a cache because we will be operating on memory mappings > b). better performance (not copying data between kernel and user buffers as > effect gained from using memory mapped segments, avoiding time operating on > the kernel mode (+ time for switching context and read-ahead pressure) which > BRAF involves) > c). less impact on the live-reads > d). less garbage will be created > e). less file descriptors opened -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2536) Schema disagreements when using connections to multiple hosts
[ https://issues.apache.org/jira/browse/CASSANDRA-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tyler Hobbs updated CASSANDRA-2536: --- Attachment: 2536-compare-timestamp.txt Attached patch compares version timestamps before applying migration locally. > Schema disagreements when using connections to multiple hosts > - > > Key: CASSANDRA-2536 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2536 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.8 beta 1 > Environment: Two node 0.8-beta1 cluster with one seed and JNA. >Reporter: Tyler Hobbs >Assignee: Tyler Hobbs > Attachments: 2536-compare-timestamp.txt, schema_disagree.py > > > If you have two thrift connections open to different nodes and you create a > KS using the first, then a CF in that KS using the second, you wind up with a > schema disagreement even if you wait/sleep after creating the KS. > The attached script reproduces the issue using pycassa (1.0.6 should work > fine, although it has the 0.7 thrift-gen code). It's also reproducible by > hand with two cassandra-cli sessions. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2578) stress performance is artificially limited
stress performance is artificially limited -- Key: CASSANDRA-2578 URL: https://issues.apache.org/jira/browse/CASSANDRA-2578 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.8 beta 1 Reporter: Brandon Williams Assignee: Pavel Yaskevich With stress I only get about 7k inserts/s against a single server, and the load and cpu usage from stress is higher than the server. Pystress gets 15-20k inserts/s against the same machine. Stress isn't cpu-limited however, so there must be something else holding it back. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2536) Schema disagreements when using connections to multiple hosts
[
https://issues.apache.org/jira/browse/CASSANDRA-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13026710#comment-13026710
]
Tyler Hobbs commented on CASSANDRA-2536:
{quote}
Wouldn't that update be DOA then? I thought we checked to make sure the new
migration compared after the current migration (as well as making sure the new
migration's previous version matches with the current version).
{quote}
We do check that the previous version matches, but the migration is applied
locally without comparing the current and new uuids.
{quote}
If the clocks are that far off sync, I think the cluster has bigger problems
(like writes not being applied).
{quote}
This can theoretically happen with clocks being off by only tens of
milliseconds.
{quote}
And unlike with data modification, I can't think of a use for doing "clever"
things w/ a client side timesamp. So pushing it to the client doesn't really
solve anything, just means you need to sync clocks across more machines.
{quote}
Not for clever purposes -- it seems to me that clients making schema
modifications are more likely to be centralized, so schema changes coming from
a single client will (almost) always have increasing timestamps.
> Schema disagreements when using connections to multiple hosts
> -
>
> Key: CASSANDRA-2536
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2536
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 0.8 beta 1
> Environment: Two node 0.8-beta1 cluster with one seed and JNA.
>Reporter: Tyler Hobbs
>Assignee: Tyler Hobbs
> Attachments: schema_disagree.py
>
>
> If you have two thrift connections open to different nodes and you create a
> KS using the first, then a CF in that KS using the second, you wind up with a
> schema disagreement even if you wait/sleep after creating the KS.
> The attached script reproduces the issue using pycassa (1.0.6 should work
> fine, although it has the 0.7 thrift-gen code). It's also reproducible by
> hand with two cassandra-cli sessions.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2536) Schema disagreements when using connections to multiple hosts
[ https://issues.apache.org/jira/browse/CASSANDRA-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13026698#comment-13026698 ] Jonathan Ellis commented on CASSANDRA-2536: --- bq. A node shouldn't accept a schema change if the timestamp for the new schema would be earlier than its current schema. You need this with or without the client-side timestamp, though; there's no sense in letting people blow their leg off. And once you have that you don't need to add a client-side timestamp with all the PITA-ness that involves. (And unlike with data modification, I can't think of a use for doing "clever" things w/ a client side timesamp. So pushing it to the client doesn't really solve anything, just means you need to sync clocks across more machines.) > Schema disagreements when using connections to multiple hosts > - > > Key: CASSANDRA-2536 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2536 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.8 beta 1 > Environment: Two node 0.8-beta1 cluster with one seed and JNA. >Reporter: Tyler Hobbs >Assignee: Tyler Hobbs > Attachments: schema_disagree.py > > > If you have two thrift connections open to different nodes and you create a > KS using the first, then a CF in that KS using the second, you wind up with a > schema disagreement even if you wait/sleep after creating the KS. > The attached script reproduces the issue using pycassa (1.0.6 should work > fine, although it has the 0.7 thrift-gen code). It's also reproducible by > hand with two cassandra-cli sessions. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2536) Schema disagreements when using connections to multiple hosts
[ https://issues.apache.org/jira/browse/CASSANDRA-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13026684#comment-13026684 ] Gary Dusbabek commented on CASSANDRA-2536: -- bq. Sometimes the v1 UUID generated by the second node has an earlier timestamp than the current schema UUID has. Wouldn't that update be DOA then? I thought we checked to make sure the new migration compared after the current migration (as well as making sure the new migration's previous version matches with the current version). bq. A node shouldn't accept a schema change if the timestamp for the new schema would be earlier than its current schema. If the clocks are *that* far off sync, I think the cluster has bigger problems (like writes not being applied). Plus, it would be easy for a node whose clock is way head to 'poison' schema updates from the rest of the cluster who are, in effect, behind the times. bq. Schema modification calls should accept an optional client-side timestamp that will be used for the v1 UUID. Seems like a better approach. > Schema disagreements when using connections to multiple hosts > - > > Key: CASSANDRA-2536 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2536 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.8 beta 1 > Environment: Two node 0.8-beta1 cluster with one seed and JNA. >Reporter: Tyler Hobbs >Assignee: Tyler Hobbs > Attachments: schema_disagree.py > > > If you have two thrift connections open to different nodes and you create a > KS using the first, then a CF in that KS using the second, you wind up with a > schema disagreement even if you wait/sleep after creating the KS. > The attached script reproduces the issue using pycassa (1.0.6 should work > fine, although it has the 0.7 thrift-gen code). It's also reproducible by > hand with two cassandra-cli sessions. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2536) Schema disagreements when using connections to multiple hosts
[ https://issues.apache.org/jira/browse/CASSANDRA-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13026674#comment-13026674 ] Tyler Hobbs commented on CASSANDRA-2536: The issue is the clocks being out of sync between nodes. Sometimes the v1 UUID generated by the second node has an earlier timestamp than the current schema UUID has. There are a couple of things that could be fixed here: 1. A node shouldn't accept a schema change if the timestamp for the new schema would be earlier than its current schema. 2. Schema modification calls should accept an optional client-side timestamp that will be used for the v1 UUID. > Schema disagreements when using connections to multiple hosts > - > > Key: CASSANDRA-2536 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2536 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.8 beta 1 > Environment: Two node 0.8-beta1 cluster with one seed and JNA. >Reporter: Tyler Hobbs >Assignee: Tyler Hobbs > Attachments: schema_disagree.py > > > If you have two thrift connections open to different nodes and you create a > KS using the first, then a CF in that KS using the second, you wind up with a > schema disagreement even if you wait/sleep after creating the KS. > The attached script reproduces the issue using pycassa (1.0.6 should work > fine, although it has the 0.7 thrift-gen code). It's also reproducible by > hand with two cassandra-cli sessions. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2558) Add "concurrent_compactions" configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-2558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stu Hood updated CASSANDRA-2558: Comment: was deleted (was: > does concurrent_compactors=0 disable compaction? That is currently the magic value for "let Cassandra decide". IMO, disabling compaction entirely shouldn't be easy.) > Add "concurrent_compactions" configuration > -- > > Key: CASSANDRA-2558 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2558 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 0.8 beta 1 >Reporter: Sylvain Lebresne >Assignee: Sylvain Lebresne >Priority: Trivial > Fix For: 0.8.1 > > Attachments: 0001-Make-compaction-thread-number-configurable.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > We should expose a way to configure the max number of thread to use when > multi_threaded compaction is turned on. So far, it uses nb_of_processors > thread, which if you have many cores may be unreasonably high (as far as > random IO is concerned and thus independently of compaction throttling)... at > least unless you have SSD. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2558) Add "concurrent_compactions" configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-2558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13026653#comment-13026653 ] Stu Hood commented on CASSANDRA-2558: - > does concurrent_compactors=0 disable compaction? That is currently the magic value for "let Cassandra decide". IMO, disabling compaction entirely shouldn't be easy. > Add "concurrent_compactions" configuration > -- > > Key: CASSANDRA-2558 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2558 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 0.8 beta 1 >Reporter: Sylvain Lebresne >Assignee: Sylvain Lebresne >Priority: Trivial > Fix For: 0.8.1 > > Attachments: 0001-Make-compaction-thread-number-configurable.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > We should expose a way to configure the max number of thread to use when > multi_threaded compaction is turned on. So far, it uses nb_of_processors > thread, which if you have many cores may be unreasonably high (as far as > random IO is concerned and thus independently of compaction throttling)... at > least unless you have SSD. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2558) Add "concurrent_compactions" configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-2558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13026650#comment-13026650 ] Jonathan Ellis commented on CASSANDRA-2558: --- does concurrent_compactors=0 disable compaction? that would be a lot more intuitive than the current min/max voodoo. > Add "concurrent_compactions" configuration > -- > > Key: CASSANDRA-2558 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2558 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 0.8 beta 1 >Reporter: Sylvain Lebresne >Assignee: Sylvain Lebresne >Priority: Trivial > Fix For: 0.8.1 > > Attachments: 0001-Make-compaction-thread-number-configurable.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > We should expose a way to configure the max number of thread to use when > multi_threaded compaction is turned on. So far, it uses nb_of_processors > thread, which if you have many cores may be unreasonably high (as far as > random IO is concerned and thus independently of compaction throttling)... at > least unless you have SSD. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2571) Check for null super column for SC CF in ThriftValidation (and always validate the sc key)
[
https://issues.apache.org/jira/browse/CASSANDRA-2571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-2571:
--
Attachment: 2571.txt
I find boolean (or other :) flags that change method behavior subtly confusing.
Attached is a version that inlines the new check into insert(), which is the
only place that wants it.
> Check for null super column for SC CF in ThriftValidation (and always
> validate the sc key)
> --
>
> Key: CASSANDRA-2571
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2571
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 0.7.0, 0.8 beta 1
>Reporter: Mike Bulman
>Assignee: Sylvain Lebresne
> Fix For: 0.7.6, 0.8.0
>
> Attachments: 0001-Improve-ThriftValidation.patch, 2571.txt
>
>
> Run the following via cli:
> {noformat}
> [default@test] use test;
> Authenticated to keyspace: test
> [default@test] create column family super with column_type=Super and
> default_validation_class=CounterColumnType;
> d41df8e0-7055-11e0--242d50cf1fbf
> Waiting for schema agreement...
> ... schemas agree across the cluster
> [default@test] incr super['0']['0'];
> Value incremented.
> [default@test] incr super['0']['0']['0'];
> null
> {noformat}
> Obviously the first incr call is invalid, even though it reports otherwise,
> as well as generates this exception:
> {noformat}
> ERROR 17:38:05,871 Fatal exception in thread Thread[COMMIT-LOG-WRITER,5,main]
> java.lang.RuntimeException: java.lang.ClassCastException:
> org.apache.cassandra.db.CounterColumn cannot be cast to
> org.apache.cassandra.db.SuperColumn
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:34)
> at java.lang.Thread.run(Thread.java:636)
> Caused by: java.lang.ClassCastException:
> org.apache.cassandra.db.CounterColumn cannot be cast to
> org.apache.cassandra.db.SuperColumn
> at
> org.apache.cassandra.db.SuperColumnSerializer.serialize(SuperColumn.java:353)
> at
> org.apache.cassandra.db.SuperColumnSerializer.serialize(SuperColumn.java:337)
> at
> org.apache.cassandra.db.ColumnFamilySerializer.serializeForSSTable(ColumnFamilySerializer.java:88)
> at
> org.apache.cassandra.db.ColumnFamilySerializer.serialize(ColumnFamilySerializer.java:74)
> at
> org.apache.cassandra.db.RowMutation$RowMutationSerializer.serialize(RowMutation.java:353)
> at
> org.apache.cassandra.db.RowMutation.getSerializedBuffer(RowMutation.java:236)
> at
> org.apache.cassandra.db.commitlog.CommitLogSegment.write(CommitLogSegment.java:111)
> at
> org.apache.cassandra.db.commitlog.CommitLog$LogRecordAdder.run(CommitLog.java:480)
> at
> org.apache.cassandra.db.commitlog.PeriodicCommitLogExecutorService$1.runMayThrow(PeriodicCommitLogExecutorService.java:49)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
> ... 1 more
> {noformat}
> But the second, proper incr call results in a bunch of exceptions and not a
> real increment.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2558) Add "concurrent_compactions" configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-2558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13026649#comment-13026649 ] Stu Hood commented on CASSANDRA-2558: - There might be a bit of confusion with the current blurb about _what_ is highly recommended (high/low/disabled/enabled), but other than that, +1. > Add "concurrent_compactions" configuration > -- > > Key: CASSANDRA-2558 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2558 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 0.8 beta 1 >Reporter: Sylvain Lebresne >Assignee: Sylvain Lebresne >Priority: Trivial > Fix For: 0.8.1 > > Attachments: 0001-Make-compaction-thread-number-configurable.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > We should expose a way to configure the max number of thread to use when > multi_threaded compaction is turned on. So far, it uses nb_of_processors > thread, which if you have many cores may be unreasonably high (as far as > random IO is concerned and thus independently of compaction throttling)... at > least unless you have SSD. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2558) Add "concurrent_compactions" configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-2558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13026649#comment-13026649 ] Stu Hood edited comment on CASSANDRA-2558 at 4/28/11 7:27 PM: -- There might be a bit of confusion with the current blurb about _what_ is highly recommended (high/low/disabled/enabled), but other than that, +1. EDIT: Also, it looks like the correct spelling is "compactor". was (Author: stuhood): There might be a bit of confusion with the current blurb about _what_ is highly recommended (high/low/disabled/enabled), but other than that, +1. > Add "concurrent_compactions" configuration > -- > > Key: CASSANDRA-2558 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2558 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 0.8 beta 1 >Reporter: Sylvain Lebresne >Assignee: Sylvain Lebresne >Priority: Trivial > Fix For: 0.8.1 > > Attachments: 0001-Make-compaction-thread-number-configurable.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > We should expose a way to configure the max number of thread to use when > multi_threaded compaction is turned on. So far, it uses nb_of_processors > thread, which if you have many cores may be unreasonably high (as far as > random IO is concerned and thus independently of compaction throttling)... at > least unless you have SSD. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-2543) Node not responding, bringing down cluster, marked as up
[ https://issues.apache.org/jira/browse/CASSANDRA-2543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-2543. --- Resolution: Duplicate Fix Version/s: (was: 0.7.6) Sounds good. Thanks for helping troubleshoot; I'm glad 0.7.5 is working well. > Node not responding, bringing down cluster, marked as up > > > Key: CASSANDRA-2543 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2543 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.7.4 >Reporter: Thibaut > Attachments: jstack > > > I have one node which constantly hangs and brings done the entire cluster > (not giving any answers). > If I restart the node, the node will hang after a certain number of time. I > have no indication > It's marked as up when executing the nodetool ring command. > Executing the ring command on the node itself (without any traffic on the > cluster) takes at least 2 minutes to execute. The node takes about 50%-100% > of cpu over all cpus. > Netstats doesn't list anything interesting: > /software/cassandra/bin/nodetool -h localhost netstats > Mode: Normal > Not sending any streams. > Not receiving any streams. > Pool NameActive Pending Completed > Commandsn/a 0 51064 > Responses n/a 0 530479 > I attached the jstack of the node. There are no indications that the node has > faulty hardware. > /usr/bin/java -ea -XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 > -Xms5254M -Xmx5254M -Xmn400M -XX:+HeapDumpOnOutOfMemoryError -Xss128k > -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled > -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=1 > -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly > -Djava.net.preferIPv4Stack=true -Dcom.sun.management.jmxremote.port=8080 > -Dcom.sun.management.jmxremote.ssl=false > -Dcom.sun.management.jmxremote.authenticate=false > -Dlog4j.configuration=log4j-server.properties > -Dlog4j.defaultInitOverride=true -Dcassandra-foreground=yes -cp > /software/cassandra/bin/../conf:/software/cassandra/bin/../build/classes:/software/cassandra/bin/../lib/antlr-3.1.3.jar:/software/cassandra/bin/../lib/apache-cassandra-0.7.4.jar:/software/cassandra/bin/../lib/avro-1.4.0-fixes.jar:/software/cassandra/bin/../lib/avro-1.4.0-sources-fixes.jar:/software/cassandra/bin/../lib/commons-cli-1.1.jar:/software/cassandra/bin/../lib/commons-codec-1.2.jar:/software/cassandra/bin/../lib/commons-collections-3.2.1.jar:/software/cassandra/bin/../lib/commons-lang-2.4.jar:/software/cassandra/bin/../lib/concurrentlinkedhashmap-lru-1.1.jar:/software/cassandra/bin/../lib/guava-r05.jar:/software/cassandra/bin/../lib/high-scale-lib.jar:/software/cassandra/bin/../lib/jackson-core-asl-1.4.0.jar:/software/cassandra/bin/../lib/jackson-mapper-asl-1.4.0.jar:/software/cassandra/bin/../lib/jetty-6.1.21.jar:/software/cassandra/bin/../lib/jetty-util-6.1.21.jar:/software/cassandra/bin/../lib/jline-0.9.94.jar:/software/cassandra/bin/../lib/json-simple-1.1.jar:/software/cassandra/bin/../lib/jug-2.0.0.jar:/software/cassandra/bin/../lib/libthrift-0.5.jar:/software/cassandra/bin/../lib/log4j-1.2.16.jar:/software/cassandra/bin/../lib/servlet-api-2.5-20081211.jar:/software/cassandra/bin/../lib/slf4j-api-1.6.1.jar:/software/cassandra/bin/../lib/slf4j-log4j12-1.6.1.jar:/software/cassandra/bin/../lib/snakeyaml-1.6.jar > org.apache.cassandra.thrift.CassandraDaemon -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2543) Node not responding, bringing down cluster, marked as up
[ https://issues.apache.org/jira/browse/CASSANDRA-2543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13026398#comment-13026398 ] Thibaut commented on CASSANDRA-2543: You can close thisissue. I think it's a duplicate of CASSANDRA-2463 causing the Garbage collector to run every few seconds. I updated to 0.7.5 and everything runs much smoother (I have also seen no timeoutexceptions in hector anymore). > Node not responding, bringing down cluster, marked as up > > > Key: CASSANDRA-2543 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2543 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.7.4 >Reporter: Thibaut > Fix For: 0.7.6 > > Attachments: jstack > > > I have one node which constantly hangs and brings done the entire cluster > (not giving any answers). > If I restart the node, the node will hang after a certain number of time. I > have no indication > It's marked as up when executing the nodetool ring command. > Executing the ring command on the node itself (without any traffic on the > cluster) takes at least 2 minutes to execute. The node takes about 50%-100% > of cpu over all cpus. > Netstats doesn't list anything interesting: > /software/cassandra/bin/nodetool -h localhost netstats > Mode: Normal > Not sending any streams. > Not receiving any streams. > Pool NameActive Pending Completed > Commandsn/a 0 51064 > Responses n/a 0 530479 > I attached the jstack of the node. There are no indications that the node has > faulty hardware. > /usr/bin/java -ea -XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 > -Xms5254M -Xmx5254M -Xmn400M -XX:+HeapDumpOnOutOfMemoryError -Xss128k > -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled > -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=1 > -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly > -Djava.net.preferIPv4Stack=true -Dcom.sun.management.jmxremote.port=8080 > -Dcom.sun.management.jmxremote.ssl=false > -Dcom.sun.management.jmxremote.authenticate=false > -Dlog4j.configuration=log4j-server.properties > -Dlog4j.defaultInitOverride=true -Dcassandra-foreground=yes -cp > /software/cassandra/bin/../conf:/software/cassandra/bin/../build/classes:/software/cassandra/bin/../lib/antlr-3.1.3.jar:/software/cassandra/bin/../lib/apache-cassandra-0.7.4.jar:/software/cassandra/bin/../lib/avro-1.4.0-fixes.jar:/software/cassandra/bin/../lib/avro-1.4.0-sources-fixes.jar:/software/cassandra/bin/../lib/commons-cli-1.1.jar:/software/cassandra/bin/../lib/commons-codec-1.2.jar:/software/cassandra/bin/../lib/commons-collections-3.2.1.jar:/software/cassandra/bin/../lib/commons-lang-2.4.jar:/software/cassandra/bin/../lib/concurrentlinkedhashmap-lru-1.1.jar:/software/cassandra/bin/../lib/guava-r05.jar:/software/cassandra/bin/../lib/high-scale-lib.jar:/software/cassandra/bin/../lib/jackson-core-asl-1.4.0.jar:/software/cassandra/bin/../lib/jackson-mapper-asl-1.4.0.jar:/software/cassandra/bin/../lib/jetty-6.1.21.jar:/software/cassandra/bin/../lib/jetty-util-6.1.21.jar:/software/cassandra/bin/../lib/jline-0.9.94.jar:/software/cassandra/bin/../lib/json-simple-1.1.jar:/software/cassandra/bin/../lib/jug-2.0.0.jar:/software/cassandra/bin/../lib/libthrift-0.5.jar:/software/cassandra/bin/../lib/log4j-1.2.16.jar:/software/cassandra/bin/../lib/servlet-api-2.5-20081211.jar:/software/cassandra/bin/../lib/slf4j-api-1.6.1.jar:/software/cassandra/bin/../lib/slf4j-log4j12-1.6.1.jar:/software/cassandra/bin/../lib/snakeyaml-1.6.jar > org.apache.cassandra.thrift.CassandraDaemon -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2558) Add "concurrent_compactions" configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-2558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13026392#comment-13026392 ] Ryan King commented on CASSANDRA-2558: -- I believe Terje had compaction turned off during a bulk import. Those compactions happened when compaction was reactivated. > Add "concurrent_compactions" configuration > -- > > Key: CASSANDRA-2558 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2558 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 0.8 beta 1 >Reporter: Sylvain Lebresne >Assignee: Sylvain Lebresne >Priority: Trivial > Fix For: 0.8.1 > > Attachments: 0001-Make-compaction-thread-number-configurable.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > We should expose a way to configure the max number of thread to use when > multi_threaded compaction is turned on. So far, it uses nb_of_processors > thread, which if you have many cores may be unreasonably high (as far as > random IO is concerned and thus independently of compaction throttling)... at > least unless you have SSD. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[Cassandra Wiki] Update of "Operations" by AlexisLeQuoc
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "Operations" page has been changed by AlexisLeQuoc. The comment on this change is: Added instructions to change the replication factor on a live cluster. http://wiki.apache.org/cassandra/Operations?action=diff&rev1=85&rev2=86 -- The same options apply to changing replication strategy. Reducing replication factor is easily done and only requires running cleanup afterwards to remove extra replicas. + + To update the replication factor on a live cluster, forget about cassandra.yaml. Rather you want to use '''cassandra-cli''': + update keyspace Keyspace1 set replication_factor = 3; === Network topology === Besides datacenters, you can also tell Cassandra which nodes are in the same rack within a datacenter. Cassandra will use this to route both reads and data movement for Range changes to the nearest replicas. This is configured by a user-pluggable !EndpointSnitch class in the configuration file.
[jira] [Assigned] (CASSANDRA-2536) Schema disagreements when using connections to multiple hosts
[ https://issues.apache.org/jira/browse/CASSANDRA-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tyler Hobbs reassigned CASSANDRA-2536: -- Assignee: Tyler Hobbs (was: Gary Dusbabek) > Schema disagreements when using connections to multiple hosts > - > > Key: CASSANDRA-2536 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2536 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.8 beta 1 > Environment: Two node 0.8-beta1 cluster with one seed and JNA. >Reporter: Tyler Hobbs >Assignee: Tyler Hobbs > Attachments: schema_disagree.py > > > If you have two thrift connections open to different nodes and you create a > KS using the first, then a CF in that KS using the second, you wind up with a > schema disagreement even if you wait/sleep after creating the KS. > The attached script reproduces the issue using pycassa (1.0.6 should work > fine, although it has the 0.7 thrift-gen code). It's also reproducible by > hand with two cassandra-cli sessions. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2558) Add "concurrent_compactions" configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-2558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-2558: Attachment: 0001-Make-compaction-thread-number-configurable.patch > Add "concurrent_compactions" configuration > -- > > Key: CASSANDRA-2558 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2558 > Project: Cassandra > Issue Type: Improvement > Components: Core >Affects Versions: 0.8 beta 1 >Reporter: Sylvain Lebresne >Assignee: Sylvain Lebresne >Priority: Trivial > Fix For: 0.8.1 > > Attachments: 0001-Make-compaction-thread-number-configurable.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > We should expose a way to configure the max number of thread to use when > multi_threaded compaction is turned on. So far, it uses nb_of_processors > thread, which if you have many cores may be unreasonably high (as far as > random IO is concerned and thus independently of compaction throttling)... at > least unless you have SSD. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2282) ReadCallback AssertionError: resolver.getMessageCount() <= endpoints.size()
[
https://issues.apache.org/jira/browse/CASSANDRA-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-2282:
--
Fix Version/s: 0.7.4
> ReadCallback AssertionError: resolver.getMessageCount() <= endpoints.size()
> ---
>
> Key: CASSANDRA-2282
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2282
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 0.7.3
>Reporter: Tyler Hobbs
>Assignee: Jonathan Ellis
> Fix For: 0.7.4
>
> Attachments: 2282-v2.txt, 2282.txt
>
>
> In a three node cluster with RF=2, when trying to page through all rows with
> get_range_slices() at CL.ONE, I get timeouts on the client side. Looking at
> the Cassandra logs, all of the nodes show the following AssertionError
> repeatedly:
> {noformat}
> ERROR [RequestResponseStage:2] 2011-03-07 19:10:27,527
> DebuggableThreadPoolExecutor.java (line 103) Error in ThreadPoolExecutor
> java.lang.AssertionError
> at
> org.apache.cassandra.service.ReadCallback.response(ReadCallback.java:127)
> at
> org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:49)
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:72)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:636)
> ERROR [RequestResponseStage:2] 2011-03-07 19:10:27,529
> AbstractCassandraDaemon.java (line 114) Fatal exception in thread
> Thread[RequestResponseStage:2,5,main]
> java.lang.AssertionError
> at
> org.apache.cassandra.service.ReadCallback.response(ReadCallback.java:127)
> at
> org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:49)
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:72)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:636)
> {noformat}
> The nodes are all running 0.7.3. The cluster was at size 3 before any data
> was inserted, and everything else appears perfectly healthy.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1097530 - in /cassandra/branches/cassandra-0.8: CHANGES.txt src/java/org/apache/cassandra/db/CompactionManager.java
Author: jbellis
Date: Thu Apr 28 16:16:40 2011
New Revision: 1097530
URL: http://svn.apache.org/viewvc?rev=1097530&view=rev
Log:
make forceUserDefinedCompaction always try to attempt what is requested
patch by jbellis; reviewed by slebresne for CASSANDRA-2575
Modified:
cassandra/branches/cassandra-0.8/CHANGES.txt
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/CompactionManager.java
Modified: cassandra/branches/cassandra-0.8/CHANGES.txt
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/CHANGES.txt?rev=1097530&r1=1097529&r2=1097530&view=diff
==
--- cassandra/branches/cassandra-0.8/CHANGES.txt (original)
+++ cassandra/branches/cassandra-0.8/CHANGES.txt Thu Apr 28 16:16:40 2011
@@ -11,6 +11,9 @@
* fix incorrect use of NBHM.size in ReadCallback that could cause
reads to time out even when responses were received (CASSAMDRA-2552)
* trigger read repair correctly for LOCAL_QUORUM reads (CASSANDRA-2556)
+ * forceUserDefinedCompaction will attempt to compact what it is given
+ even if the pessimistic estimate is that there is not enough disk space;
+ automatic compactions will only compact 2 or more sstables (CASSANDRA-2575)
0.8.0-beta1
Modified:
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/CompactionManager.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/CompactionManager.java?rev=1097530&r1=1097529&r2=1097530&view=diff
==
---
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/CompactionManager.java
(original)
+++
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/CompactionManager.java
Thu Apr 28 16:16:40 2011
@@ -414,10 +414,11 @@ public class CompactionManager implement
// attempt to schedule the set
else if ((sstables =
cfs.getDataTracker().markCompacting(sstables, 1, Integer.MAX_VALUE)) != null)
{
+String location = cfs.table.getDataFileLocation(1);
// success: perform the compaction
try
{
-doCompaction(cfs, sstables, gcBefore);
+doCompactionWithoutSizeEstimation(cfs, sstables,
gcBefore, location);
}
finally
{
@@ -489,11 +490,32 @@ public class CompactionManager implement
}
}
+int doCompaction(ColumnFamilyStore cfs, Collection
sstables, int gcBefore) throws IOException
+{
+Table table = cfs.table;
+
+// If the compaction file path is null that means we have no space
left for this compaction.
+// try again w/o the largest one.
+Set smallerSSTables = new
HashSet(sstables);
+while (smallerSSTables.size() > 1)
+{
+String compactionFileLocation =
table.getDataFileLocation(cfs.getExpectedCompactedFileSize(smallerSSTables));
+if (compactionFileLocation != null)
+return doCompactionWithoutSizeEstimation(cfs, smallerSSTables,
gcBefore, compactionFileLocation);
+
+logger.warn("insufficient space to compact all requested files " +
StringUtils.join(smallerSSTables, ", "));
+smallerSSTables.remove(cfs.getMaxSizeFile(smallerSSTables));
+}
+
+logger.error("insufficient space to compact even the two smallest
files, aborting");
+return 0;
+}
+
/**
* For internal use and testing only. The rest of the system should go
through the submit* methods,
* which are properly serialized.
*/
-int doCompaction(ColumnFamilyStore cfs, Collection
sstables, int gcBefore) throws IOException
+int doCompactionWithoutSizeEstimation(ColumnFamilyStore cfs,
Collection sstables, int gcBefore, String
compactionFileLocation) throws IOException
{
// The collection of sstables passed may be empty (but not null); even
if
// it is not empty, it may compact down to nothing if all rows are
deleted.
@@ -507,23 +529,6 @@ public class CompactionManager implement
for (SSTableReader sstable : sstables)
assert sstable.descriptor.cfname.equals(cfs.columnFamily);
-String compactionFileLocation =
table.getDataFileLocation(cfs.getExpectedCompactedFileSize(sstables));
-// If the compaction file path is null that means we have no space
left for this compaction.
-// try again w/o the largest one.
-List smallerSSTables = new
ArrayList(sstables);
-while (compactionFileLocation == null && smallerSSTables.size() > 1)
-{
-logger.warn("insufficient space to compact all requested files " +
StringUtils.join(smallerSSTables, ", "));
-small
[jira] [Commented] (CASSANDRA-2575) make forceUserDefinedCompaction actually do what it says
[ https://issues.apache.org/jira/browse/CASSANDRA-2575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13026356#comment-13026356 ] Sylvain Lebresne commented on CASSANDRA-2575: - +1 on v2 > make forceUserDefinedCompaction actually do what it says > > > Key: CASSANDRA-2575 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2575 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.7.1 >Reporter: Jonathan Ellis >Assignee: Jonathan Ellis >Priority: Minor > Fix For: 0.8.0 > > Attachments: 2575-v2.txt, 2575.txt > > > See http://www.mail-archive.com/user@cassandra.apache.org/msg12621.html for > motivation -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
buildbot failure in ASF Buildbot on cassandra-trunk
The Buildbot has detected a new failure on builder cassandra-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/cassandra-trunk/builds/1290 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: isis_ubuntu Build Reason: scheduler Build Source Stamp: [branch cassandra/trunk] 1097511 Blamelist: jbellis BUILD FAILED: failed compile sincerely, -The Buildbot
[jira] [Commented] (CASSANDRA-2555) Explicit timestamp support for CQL
[ https://issues.apache.org/jira/browse/CASSANDRA-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13026352#comment-13026352 ] Jonathan Ellis commented on CASSANDRA-2555: --- committed to trunk in r1097511 > Explicit timestamp support for CQL > -- > > Key: CASSANDRA-2555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2555 > Project: Cassandra > Issue Type: Improvement > Components: API >Reporter: Jonathan Ellis >Assignee: Pavel Yaskevich > Fix For: 0.8.1 > > Attachments: CASSANDRA-2555-v2.patch, CASSANDRA-2555.patch > > > To make CQL BATCHes useful for the normal purpose of idempotent retries, we > need to add support for client-supplied timestamps. At a minimum this needs > to be available for a batch (BEGIN BATCH USING TIMESTAMP 1303743619771318) > but might also be nice at the statement level (UPDATE ... USING TIMESTAMP > ...). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2575) make forceUserDefinedCompaction actually do what it says
[ https://issues.apache.org/jira/browse/CASSANDRA-2575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2575: -- Attachment: 2575-v2.txt bq. Also wondering if it couldn't make sense to not compact if we end up with only 1 sstable in doCompaction, now that you still can do a userDefinedCompaction on only 1 sstable Good idea. v2 attached with a rewrite of the retry loop to do this. > make forceUserDefinedCompaction actually do what it says > > > Key: CASSANDRA-2575 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2575 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.7.1 >Reporter: Jonathan Ellis >Assignee: Jonathan Ellis >Priority: Minor > Fix For: 0.8.0 > > Attachments: 2575-v2.txt, 2575.txt > > > See http://www.mail-archive.com/user@cassandra.apache.org/msg12621.html for > motivation -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1097511 - in /cassandra/trunk: ./ doc/cql/ src/java/org/apache/cassandra/cql/ test/system/
Author: jbellis
Date: Thu Apr 28 15:39:52 2011
New Revision: 1097511
URL: http://svn.apache.org/viewvc?rev=1097511&view=rev
Log:
add timestamp support to cqlINSERT,UPDATE,and BATCH
patch by Pavel Yaskevich; reviewed by jbellis for CASSANDRA-2555
Modified:
cassandra/trunk/CHANGES.txt
cassandra/trunk/doc/cql/CQL.textile
cassandra/trunk/src/java/org/apache/cassandra/cql/AbstractModification.java
cassandra/trunk/src/java/org/apache/cassandra/cql/BatchStatement.java
cassandra/trunk/src/java/org/apache/cassandra/cql/Cql.g
cassandra/trunk/src/java/org/apache/cassandra/cql/DeleteStatement.java
cassandra/trunk/src/java/org/apache/cassandra/cql/QueryProcessor.java
cassandra/trunk/src/java/org/apache/cassandra/cql/UpdateStatement.java
cassandra/trunk/test/system/test_cql.py
Modified: cassandra/trunk/CHANGES.txt
URL:
http://svn.apache.org/viewvc/cassandra/trunk/CHANGES.txt?rev=1097511&r1=1097510&r2=1097511&view=diff
==
--- cassandra/trunk/CHANGES.txt (original)
+++ cassandra/trunk/CHANGES.txt Thu Apr 28 15:39:52 2011
@@ -1,6 +1,7 @@
1.0-dev
* add support for insert, delete in cql BATCH (CASSANDRA-2537)
* add support for IN to cql SELECT, UPDATE (CASSANDRA-2553)
+ * add timestamp support to cql INSERT, UPDATE, and BATCH (CASSANDRA-2555)
0.8.0-?
Modified: cassandra/trunk/doc/cql/CQL.textile
URL:
http://svn.apache.org/viewvc/cassandra/trunk/doc/cql/CQL.textile?rev=1097511&r1=1097510&r2=1097511&view=diff
==
--- cassandra/trunk/doc/cql/CQL.textile (original)
+++ cassandra/trunk/doc/cql/CQL.textile Thu Apr 28 15:39:52 2011
@@ -74,7 +74,7 @@ h2. INSERT
_Synopsis:_
bc.
-INSERT INTO (KEY, , , ...) VALUES (, ,
, ...) [USING CONSISTENCY (KEY, , , ...) VALUES (, ,
, ...) [USING CONSISTENCY [AND TIMESTAMP ]];
An @INSERT@ is used to write one or more columns to a record in a Cassandra
column family. No results are returned.
@@ -85,7 +85,7 @@ h2. UPDATE
_Synopsis:_
bc.
-UPDATE [USING ]
+UPDATE [USING [AND TIMESTAMP ]]
SET name1 = value1, name2 = value2 WHERE KEY = keyname;
An @UPDATE@ is used to write one or more columns to a record in a Cassandra
column family. No results are returned.
@@ -104,6 +104,13 @@ UPDATE ... [USING ] ...
Following the column family identifier is an optional "consistency level
specification":#consistency.
+h3. Timestamp
+
+bc.
+UPDATE ... [USING TIMESTAMP ] ...
+
+@UPDATE@ supports setting client-supplied optional timestamp for modification.
+
h3. Specifying Columns and Row
bc.
@@ -156,10 +163,12 @@ h2. BATCH
_Synopsis:_
bc.
-BATCH BEGIN BATCH [USING CONSISTENCY ]
+BATCH BEGIN BATCH [USING CONSISTENCY [AND TIMESTAMP ]]
INSERT or UPDATE or DELETE statements separated by semicolon or "end of
line"
APPLY BATCH
+@BATCH@ supports setting client-supplied optional global timestamp which will
be used for each of the operations included in batch.
+
A single consistency level is used for the entire batch, it appears after the
@BEGIN BATCH@ statement, and uses the standard "consistency level
specification":#consistency. Batch default to @CONSISTENCY.ONE@ when left
unspecified.
_NOTE: While there are no isolation guarantees, @UPDATE@ queries are atomic
within a give record._
Modified:
cassandra/trunk/src/java/org/apache/cassandra/cql/AbstractModification.java
URL:
http://svn.apache.org/viewvc/cassandra/trunk/src/java/org/apache/cassandra/cql/AbstractModification.java?rev=1097511&r1=1097510&r2=1097511&view=diff
==
--- cassandra/trunk/src/java/org/apache/cassandra/cql/AbstractModification.java
(original)
+++ cassandra/trunk/src/java/org/apache/cassandra/cql/AbstractModification.java
Thu Apr 28 15:39:52 2011
@@ -32,11 +32,18 @@ public abstract class AbstractModificati
protected final String columnFamily;
protected final ConsistencyLevel cLevel;
+protected final Long timestamp;
public AbstractModification(String columnFamily, ConsistencyLevel cLevel)
{
+this(columnFamily, cLevel, null);
+}
+
+public AbstractModification(String columnFamily, ConsistencyLevel cLevel,
Long timestamp)
+{
this.columnFamily = columnFamily;
this.cLevel = cLevel;
+this.timestamp = timestamp;
}
public String getColumnFamily()
@@ -59,6 +66,16 @@ public abstract class AbstractModificati
return cLevel != null;
}
+public long getTimestamp()
+{
+return timestamp == null ? System.currentTimeMillis() : timestamp;
+}
+
+public boolean isSetTimestamp()
+{
+return timestamp != null;
+}
+
/**
* Convert statement into a list of mutations to apply on the server
*
@@ -71,4 +88,18 @@ public abstract class AbstractModificati
*/
public abs
[jira] [Updated] (CASSANDRA-2555) Explicit timestamp support for CQL
[ https://issues.apache.org/jira/browse/CASSANDRA-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-2555: --- Attachment: CASSANDRA-2555-v2.patch QP throws exception only if global and local timestamp were set in BATCH at the same time. test for BATCH with TIMESTAMP is moved to the previous test for the BATCH statement but tests for INSERT, UPDATE are left in dedicated tests. > Explicit timestamp support for CQL > -- > > Key: CASSANDRA-2555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2555 > Project: Cassandra > Issue Type: Improvement > Components: API >Reporter: Jonathan Ellis >Assignee: Pavel Yaskevich > Fix For: 0.8.1 > > Attachments: CASSANDRA-2555-v2.patch, CASSANDRA-2555.patch > > > To make CQL BATCHes useful for the normal purpose of idempotent retries, we > need to add support for client-supplied timestamps. At a minimum this needs > to be available for a batch (BEGIN BATCH USING TIMESTAMP 1303743619771318) > but might also be nice at the statement level (UPDATE ... USING TIMESTAMP > ...). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1097485 - in /cassandra/site: publish/download/index.html src/content/download/index.html
Author: eevans
Date: Thu Apr 28 14:42:51 2011
New Revision: 1097485
URL: http://svn.apache.org/viewvc?rev=1097485&view=rev
Log:
link to cql language drivers
Modified:
cassandra/site/publish/download/index.html
cassandra/site/src/content/download/index.html
Modified: cassandra/site/publish/download/index.html
URL:
http://svn.apache.org/viewvc/cassandra/site/publish/download/index.html?rev=1097485&r1=1097484&r2=1097485&view=diff
==
--- cassandra/site/publish/download/index.html (original)
+++ cassandra/site/publish/download/index.html Thu Apr 28 14:42:51 2011
@@ -123,6 +123,29 @@
+ CQL Drivers
+
+ New for 0.8 is CQL (Cassandra Query Language), an SQL-alike alternative to
+ the traditional http://wiki.apache.org/cassandra/ClientOptions";>
+ RPC interface. Language drivers are available for:
+
+
+
+ http://www.apache.org/dist/cassandra/drivers/java";>
+ Java (JDBC)
+
+
+ http://www.apache.org/dist/cassandra/drivers/py";>
+ Python (DBAPI2)
+
+
+ http://www.apache.org/dist/cassandra/drivers/txpy";>
+ Twisted
+
+
+
+
+
When downloading from a mirror, please be sure to verify the checksums
and OpenPGP compatible signature (see the MD5, SHA1, and PGP links
Modified: cassandra/site/src/content/download/index.html
URL:
http://svn.apache.org/viewvc/cassandra/site/src/content/download/index.html?rev=1097485&r1=1097484&r2=1097485&view=diff
==
--- cassandra/site/src/content/download/index.html (original)
+++ cassandra/site/src/content/download/index.html Thu Apr 28 14:42:51 2011
@@ -82,6 +82,29 @@
{% endif %}
+ CQL Drivers
+
+ New for 0.8 is CQL (Cassandra Query Language), an SQL-alike alternative to
+ the traditional http://wiki.apache.org/cassandra/ClientOptions";>
+ RPC interface. Language drivers are available for:
+
+
+
+ http://www.apache.org/dist/cassandra/drivers/java";>
+ Java (JDBC)
+
+
+ http://www.apache.org/dist/cassandra/drivers/py";>
+ Python (DBAPI2)
+
+
+ http://www.apache.org/dist/cassandra/drivers/txpy";>
+ Twisted
+
+
+
+
+
When downloading from a mirror, please be sure to verify the checksums
and OpenPGP compatible signature (see the MD5, SHA1, and PGP links
[jira] [Commented] (CASSANDRA-2555) Explicit timestamp support for CQL
[ https://issues.apache.org/jira/browse/CASSANDRA-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13026323#comment-13026323 ] Pavel Yaskevich commented on CASSANDRA-2555: Gotcha! > Explicit timestamp support for CQL > -- > > Key: CASSANDRA-2555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2555 > Project: Cassandra > Issue Type: Improvement > Components: API >Reporter: Jonathan Ellis >Assignee: Pavel Yaskevich > Fix For: 0.8.1 > > Attachments: CASSANDRA-2555.patch > > > To make CQL BATCHes useful for the normal purpose of idempotent retries, we > need to add support for client-supplied timestamps. At a minimum this needs > to be available for a batch (BEGIN BATCH USING TIMESTAMP 1303743619771318) > but might also be nice at the statement level (UPDATE ... USING TIMESTAMP > ...). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2555) Explicit timestamp support for CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13026322#comment-13026322
]
Jonathan Ellis edited comment on CASSANDRA-2555 at 4/28/11 2:33 PM:
{code}
if (up.isSetTimestamp())
throw new InvalidRequestException(
"Timestamp must be set on the BATCH, not
individual statements");
{code}
Unlike ConsistencyLevel, it can make sense to have different timestamps on the
individual updates. So we should only reject this if there is a ts on the batch
as well. (I.e., ts on batch = ok, ts on individual updates within a batch =
ok, ts on both = confusing and not ok.)
bq. 3 tests added
if it doesn't cause conflicts, can you move these into existing
batch/update/insert tests? There is a very high per-method overhead in
test_cql since it tears down, wipes, and restarts the server for each.
was (Author: jbellis):
{code}
if (up.isSetTimestamp())
throw new InvalidRequestException(
"Timestamp must be set on the BATCH, not
individual statements");
{code}
Unlike ConsistencyLevel, it can make sense to have different timestamps on the
individual updates. So we should only reject this if there is a ts on the batch
as well. (I.e., ts on batch = ok, ts on individual updates = ok, ts on both =
confusing and not ok.)
bq. 3 tests added
if it doesn't cause conflicts, can you move these into existing
batch/update/insert tests? There is a very high per-method overhead in
test_cql since it tears down, wipes, and restarts the server for each.
> Explicit timestamp support for CQL
> --
>
> Key: CASSANDRA-2555
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2555
> Project: Cassandra
> Issue Type: Improvement
> Components: API
>Reporter: Jonathan Ellis
>Assignee: Pavel Yaskevich
> Fix For: 0.8.1
>
> Attachments: CASSANDRA-2555.patch
>
>
> To make CQL BATCHes useful for the normal purpose of idempotent retries, we
> need to add support for client-supplied timestamps. At a minimum this needs
> to be available for a batch (BEGIN BATCH USING TIMESTAMP 1303743619771318)
> but might also be nice at the statement level (UPDATE ... USING TIMESTAMP
> ...).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2555) Explicit timestamp support for CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13026322#comment-13026322
]
Jonathan Ellis commented on CASSANDRA-2555:
---
{code}
if (up.isSetTimestamp())
throw new InvalidRequestException(
"Timestamp must be set on the BATCH, not
individual statements");
{code}
Unlike ConsistencyLevel, it can make sense to have different timestamps on the
individual updates. So we should only reject this if there is a ts on the batch
as well. (I.e., ts on batch = ok, ts on individual updates = ok, ts on both =
confusing and not ok.)
bq. 3 tests added
if it doesn't cause conflicts, can you move these into existing
batch/update/insert tests? There is a very high per-method overhead in
test_cql since it tears down, wipes, and restarts the server for each.
> Explicit timestamp support for CQL
> --
>
> Key: CASSANDRA-2555
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2555
> Project: Cassandra
> Issue Type: Improvement
> Components: API
>Reporter: Jonathan Ellis
>Assignee: Pavel Yaskevich
> Fix For: 0.8.1
>
> Attachments: CASSANDRA-2555.patch
>
>
> To make CQL BATCHes useful for the normal purpose of idempotent retries, we
> need to add support for client-supplied timestamps. At a minimum this needs
> to be available for a batch (BEGIN BATCH USING TIMESTAMP 1303743619771318)
> but might also be nice at the statement level (UPDATE ... USING TIMESTAMP
> ...).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
buildbot success in ASF Buildbot on cassandra-trunk
The Buildbot has detected a restored build on builder cassandra-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/cassandra-trunk/builds/1289 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: isis_ubuntu Build Reason: scheduler Build Source Stamp: [branch cassandra/trunk] 1097473 Blamelist: jbellis Build succeeded! sincerely, -The Buildbot
svn commit: r1097473 - in /cassandra/trunk: ./ conf/ contrib/ interface/thrift/gen-java/org/apache/cassandra/thrift/ lib/ lib/licenses/ src/java/org/apache/cassandra/service/ src/resources/org/apache/
Author: jbellis
Date: Thu Apr 28 14:20:59 2011
New Revision: 1097473
URL: http://svn.apache.org/viewvc?rev=1097473&view=rev
Log:
merge from 0.8
Added:
cassandra/trunk/lib/jamm-0.2.2.jar
- copied unchanged from r1097386,
cassandra/branches/cassandra-0.8/lib/jamm-0.2.2.jar
cassandra/trunk/lib/licenses/jamm-0.2.2.txt
- copied unchanged from r1097386,
cassandra/branches/cassandra-0.8/lib/licenses/jamm-0.2.2.txt
Removed:
cassandra/trunk/lib/jamm-0.2.1.jar
cassandra/trunk/lib/licenses/jamm-0.2.1.txt
Modified:
cassandra/trunk/ (props changed)
cassandra/trunk/CHANGES.txt
cassandra/trunk/build.xml
cassandra/trunk/conf/cassandra-env.sh
cassandra/trunk/contrib/ (props changed)
cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java
(props changed)
cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java
(props changed)
cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java
(props changed)
cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/NotFoundException.java
(props changed)
cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/SuperColumn.java
(props changed)
cassandra/trunk/src/java/org/apache/cassandra/service/AbstractRowResolver.java
cassandra/trunk/src/java/org/apache/cassandra/service/AsyncRepairCallback.java
cassandra/trunk/src/java/org/apache/cassandra/service/ClientState.java
cassandra/trunk/src/java/org/apache/cassandra/service/DatacenterReadCallback.java
cassandra/trunk/src/java/org/apache/cassandra/service/IResponseResolver.java
cassandra/trunk/src/java/org/apache/cassandra/service/RangeSliceResponseResolver.java
cassandra/trunk/src/java/org/apache/cassandra/service/ReadCallback.java
cassandra/trunk/src/java/org/apache/cassandra/service/RepairCallback.java
cassandra/trunk/src/resources/org/apache/cassandra/cli/CliHelp.yaml
Propchange: cassandra/trunk/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Thu Apr 28 14:20:59 2011
@@ -1,7 +1,7 @@
/cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1081914,1083000
-/cassandra/branches/cassandra-0.7:1026516-1096531,1096805
+/cassandra/branches/cassandra-0.7:1026516-1096531,1096805,1097448,1097455
/cassandra/branches/cassandra-0.7.0:1053690-1055654
-/cassandra/branches/cassandra-0.8:1090935-1097141,1097387
+/cassandra/branches/cassandra-0.8:1090935-1097471
/cassandra/tags/cassandra-0.7.0-rc3:1051699-1053689
/incubator/cassandra/branches/cassandra-0.3:774578-796573
/incubator/cassandra/branches/cassandra-0.4:810145-834239,834349-834350
Modified: cassandra/trunk/CHANGES.txt
URL:
http://svn.apache.org/viewvc/cassandra/trunk/CHANGES.txt?rev=1097473&r1=1097472&r2=1097473&view=diff
==
--- cassandra/trunk/CHANGES.txt (original)
+++ cassandra/trunk/CHANGES.txt Thu Apr 28 14:20:59 2011
@@ -11,6 +11,11 @@
* movegossip heartbeat back to its own thread (CASSANDRA-2554)
* validate cql TRUNCATE columnfamily before truncating (CASSANDRA-2570)
* fix batch_mutate for mixed standard-counter mutations (CASSANDRA-2457)
+ * disallow making schema changes to system keyspace (CASSANDRA-2563)
+ * fix sending mutation messages multiple times (CASSANDRA-2557)
+ * fix incorrect use of NBHM.size in ReadCallback that could cause
+ reads to time out even when responses were received (CASSAMDRA-2552)
+ * trigger read repair correctly for LOCAL_QUORUM reads (CASSANDRA-2556)
0.8.0-beta1
Modified: cassandra/trunk/build.xml
URL:
http://svn.apache.org/viewvc/cassandra/trunk/build.xml?rev=1097473&r1=1097472&r2=1097473&view=diff
==
--- cassandra/trunk/build.xml (original)
+++ cassandra/trunk/build.xml Thu Apr 28 14:20:59 2011
@@ -618,7 +618,7 @@
-
+
Modified: cassandra/trunk/conf/cassandra-env.sh
URL:
http://svn.apache.org/viewvc/cassandra/trunk/conf/cassandra-env.sh?rev=1097473&r1=1097472&r2=1097473&view=diff
==
--- cassandra/trunk/conf/cassandra-env.sh (original)
+++ cassandra/trunk/conf/cassandra-env.sh Thu Apr 28 14:20:59 2011
@@ -95,7 +95,7 @@ JVM_OPTS="$JVM_OPTS -ea"
check_openjdk=$(java -version 2>&1 | awk '{if (NR == 2) {print $1}}')
if [ "$check_openjdk" != "OpenJDK" ]
then
-JVM_OPTS="$JVM_OPTS -javaagent:$CASSANDRA_HOME/lib/jamm-0.2.1.jar"
+JVM_OPTS="$JVM_OPTS -javaagent:$CASSANDRA_HOME/lib/jamm-0.2.2.jar"
fi
# enable thread priorities, primarily so we can give periodic tasks
Propchange: cassandra/trunk/contrib/
[jira] [Commented] (CASSANDRA-2556) DatacenterReadResolver not triggering repair
[ https://issues.apache.org/jira/browse/CASSANDRA-2556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13026310#comment-13026310 ] Hudson commented on CASSANDRA-2556: --- Integrated in Cassandra-0.7 #460 (See [https://builds.apache.org/hudson/job/Cassandra-0.7/460/]) trigger read repair correctly forLOCAL_QUORUM reads patch by jbellis; reviewed by slebresne for CASSANDRA-2556 > DatacenterReadResolver not triggering repair > > > Key: CASSANDRA-2556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2556 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.7.0 >Reporter: Stu Hood >Assignee: Jonathan Ellis >Priority: Minor > Fix For: 0.7.6, 0.8.0 > > Attachments: 2556.txt > > > DatacenterReadResolver only calls maybeResolveForRepair for local reads. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2552) ReadResponseResolver Race
[
https://issues.apache.org/jira/browse/CASSANDRA-2552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13026306#comment-13026306
]
Hudson commented on CASSANDRA-2552:
---
Integrated in Cassandra-0.7 #459 (See
[https://builds.apache.org/hudson/job/Cassandra-0.7/459/])
fix incorrect use ofNBHM.size in ReadCallback
patch by jbellis; reviewed by stuhood for CASSANDRA-2552
> ReadResponseResolver Race
> -
>
> Key: CASSANDRA-2552
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2552
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 0.7.1
>Reporter: Stu Hood
>Assignee: Jonathan Ellis
> Fix For: 0.7.6, 0.8.0
>
> Attachments: 0001-Move-Resolvers-to-atomic-append-count.txt,
> 2552-v2-07.txt, 2552-v2.txt, ResolveRaceTest.java
>
>
> When receiving a response, ReadResponseResolver uses a 3 step process to
> decide whether to trigger the condition that enough responses have arrived:
> # Add new response
> # Check response set size
> # Check that data is present
> I think that these steps must have been reordered by the compiler in some
> cases, because I was able to reproduce a case for a QUORUM read where the
> condition is not properly triggered:
> {noformat}
> INFO [RequestResponseStage:15] 2011-04-25 00:26:53,514
> ReadResponseResolver.java (line 87) post append for 1087367065: hasData=false
> in 2 messages
> INFO [RequestResponseStage:8] 2011-04-25 00:26:53,514
> ReadResponseResolver.java (line 87) post append for 1087367065: hasData=true
> in 1 messages
> INFO [pool-1-thread-54] 2011-04-25 00:27:03,516 StorageProxy.java (line 623)
> Read timeout: java.util.concurrent.TimeoutException:
> ReadResponseResolver@1087367065(/10.34.131.109=false,/10.34.132.122=true,)
> {noformat}
> The last line shows that both results were present, and that one of them was
> holding data.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-2556) DatacenterReadResolver not triggering repair
[ https://issues.apache.org/jira/browse/CASSANDRA-2556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-2556. --- Resolution: Fixed Fix Version/s: 0.8.0 committed > DatacenterReadResolver not triggering repair > > > Key: CASSANDRA-2556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2556 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.7.0 >Reporter: Stu Hood >Assignee: Jonathan Ellis >Priority: Minor > Fix For: 0.7.6, 0.8.0 > > Attachments: 2556.txt > > > DatacenterReadResolver only calls maybeResolveForRepair for local reads. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1097456 - in /cassandra/branches/cassandra-0.8: ./ contrib/ interface/thrift/gen-java/org/apache/cassandra/thrift/ src/java/org/apache/cassandra/service/
Author: jbellis Date: Thu Apr 28 13:37:07 2011 New Revision: 1097456 URL: http://svn.apache.org/viewvc?rev=1097456&view=rev Log: merge from 0.7 Modified: cassandra/branches/cassandra-0.8/ (props changed) cassandra/branches/cassandra-0.8/CHANGES.txt cassandra/branches/cassandra-0.8/contrib/ (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/NotFoundException.java (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/SuperColumn.java (props changed) cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/DatacenterReadCallback.java cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/ReadCallback.java Propchange: cassandra/branches/cassandra-0.8/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Apr 28 13:37:07 2011 @@ -1,5 +1,5 @@ /cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1081914,1083000 -/cassandra/branches/cassandra-0.7:1026516-1096531,1096805,1097448 +/cassandra/branches/cassandra-0.7:1026516-1096531,1096805,1097448,1097455 /cassandra/branches/cassandra-0.7.0:1053690-1055654 /cassandra/tags/cassandra-0.7.0-rc3:1051699-1053689 /cassandra/trunk:1090978-1090979 Modified: cassandra/branches/cassandra-0.8/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/CHANGES.txt?rev=1097456&r1=1097455&r2=1097456&view=diff == --- cassandra/branches/cassandra-0.8/CHANGES.txt (original) +++ cassandra/branches/cassandra-0.8/CHANGES.txt Thu Apr 28 13:37:07 2011 @@ -10,6 +10,7 @@ * fix sending mutation messages multiple times (CASSANDRA-2557) * fix incorrect use of NBHM.size in ReadCallback that could cause reads to time out even when responses were received (CASSAMDRA-2552) + * trigger read repair correctly for LOCAL_QUORUM reads (CASSANDRA-2556) 0.8.0-beta1 Propchange: cassandra/branches/cassandra-0.8/contrib/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Apr 28 13:37:07 2011 @@ -1,5 +1,5 @@ /cassandra/branches/cassandra-0.6/contrib:922689-1052356,1052358-1053452,1053454,1053456-1068009 -/cassandra/branches/cassandra-0.7/contrib:1026516-1096531,1096805,1097448 +/cassandra/branches/cassandra-0.7/contrib:1026516-1096531,1096805,1097448,1097455 /cassandra/branches/cassandra-0.7.0/contrib:1053690-1055654 /cassandra/tags/cassandra-0.7.0-rc3/contrib:1051699-1053689 /cassandra/trunk/contrib:1090978-1090979 Propchange: cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Apr 28 13:37:07 2011 @@ -1,5 +1,5 @@ /cassandra/branches/cassandra-0.6/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:922689-1052356,1052358-1053452,1053454,1053456-1081914,1083000 -/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1096531,1096805,1097448 +/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1096531,1096805,1097448,1097455 /cassandra/branches/cassandra-0.7.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1053690-1055654 /cassandra/tags/cassandra-0.7.0-rc3/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1051699-1053689 /cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1090978-1090979 Propchange: cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Apr 28 13:37:07 2011 @@ -1,5 +1,5 @@ /cassandra/branches/cassandra-0.6/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:922689-1052356,1052358-1053452,1053454,1053456-1081914,1083000 -/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1026516-1096531,1096805,1097448 +/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1026516-1096531,1096805,1097448,1097455 /cassandra/branches/cassandra-0.7.0/interface/thrift/gen-java/org/apache/cas
svn commit: r1097455 - in /cassandra/branches/cassandra-0.7: CHANGES.txt src/java/org/apache/cassandra/service/DatacenterReadCallback.java src/java/org/apache/cassandra/service/ReadCallback.java
Author: jbellis
Date: Thu Apr 28 13:36:07 2011
New Revision: 1097455
URL: http://svn.apache.org/viewvc?rev=1097455&view=rev
Log:
trigger read repair correctly forLOCAL_QUORUM reads
patch by jbellis; reviewed by slebresne for CASSANDRA-2556
Modified:
cassandra/branches/cassandra-0.7/CHANGES.txt
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/DatacenterReadCallback.java
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/ReadCallback.java
Modified: cassandra/branches/cassandra-0.7/CHANGES.txt
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/CHANGES.txt?rev=1097455&r1=1097454&r2=1097455&view=diff
==
--- cassandra/branches/cassandra-0.7/CHANGES.txt (original)
+++ cassandra/branches/cassandra-0.7/CHANGES.txt Thu Apr 28 13:36:07 2011
@@ -3,6 +3,7 @@
* move gossip heartbeat back to its own thread (CASSANDRA-2554)
* fix incorrect use of NBHM.size in ReadCallback that could cause
reads to time out even when responses were received (CASSAMDRA-2552)
+ * trigger read repair correctly for LOCAL_QUORUM reads (CASSANDRA-2556)
0.7.5
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/DatacenterReadCallback.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/DatacenterReadCallback.java?rev=1097455&r1=1097454&r2=1097455&view=diff
==
---
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/DatacenterReadCallback.java
(original)
+++
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/DatacenterReadCallback.java
Thu Apr 28 13:36:07 2011
@@ -48,31 +48,17 @@ public class DatacenterReadCallback e
}
@Override
-public void response(Message message)
+protected boolean waitingFor(Message message)
{
-resolver.preprocess(message);
-
-int n = localdc.equals(snitch.getDatacenter(message.getFrom()))
- ? received.incrementAndGet()
- : received.get();
-
-if (n == blockfor && resolver.isDataPresent())
-{
-condition.signal();
-maybeResolveForRepair();
-}
+return localdc.equals(snitch.getDatacenter(message.getFrom()));
}
-
+
@Override
-public void response(ReadResponse result)
+protected boolean waitingFor(ReadResponse response)
{
-((RowDigestResolver) resolver).injectPreProcessed(result);
-
-if (received.incrementAndGet() == blockfor && resolver.isDataPresent())
-{
-condition.signal();
-maybeResolveForRepair();
-}
+// cheat and leverage our knowledge that a local read is the only way
the ReadResponse
+// version of this method gets called
+return true;
}
@Override
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/ReadCallback.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/ReadCallback.java?rev=1097455&r1=1097454&r2=1097455&view=diff
==
---
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/ReadCallback.java
(original)
+++
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/ReadCallback.java
Thu Apr 28 13:36:07 2011
@@ -128,17 +128,40 @@ public class ReadCallback implements
public void response(Message message)
{
resolver.preprocess(message);
-if (received.incrementAndGet() >= blockfor && resolver.isDataPresent())
+int n = waitingFor(message)
+ ? received.incrementAndGet()
+ : received.get();
+if (n >= blockfor && resolver.isDataPresent())
{
condition.signal();
maybeResolveForRepair();
}
}
+/**
+ * @return true if the message counts towards the blockfor threshold
+ * TODO turn the Message into a response so we don't need two versions of
this method
+ */
+protected boolean waitingFor(Message message)
+{
+return true;
+}
+
+/**
+ * @return true if the response counts towards the blockfor threshold
+ */
+protected boolean waitingFor(ReadResponse response)
+{
+return true;
+}
+
public void response(ReadResponse result)
{
((RowDigestResolver) resolver).injectPreProcessed(result);
-if (received.incrementAndGet() >= blockfor && resolver.isDataPresent())
+int n = waitingFor(result)
+ ? received.incrementAndGet()
+ : received.get();
+if (n >= blockfor && resolver.isDataPresent())
{
condition.signal();
maybeResolveForRepair();
svn commit: r1097449 - in /cassandra/branches/cassandra-0.8: ./ contrib/ interface/thrift/gen-java/org/apache/cassandra/thrift/ src/java/org/apache/cassandra/service/
Author: jbellis Date: Thu Apr 28 13:26:28 2011 New Revision: 1097449 URL: http://svn.apache.org/viewvc?rev=1097449&view=rev Log: merge from 0.7 Modified: cassandra/branches/cassandra-0.8/ (props changed) cassandra/branches/cassandra-0.8/CHANGES.txt cassandra/branches/cassandra-0.8/contrib/ (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/NotFoundException.java (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/SuperColumn.java (props changed) cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/AbstractRowResolver.java cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/AsyncRepairCallback.java cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/DatacenterReadCallback.java cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/IResponseResolver.java cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/RangeSliceResponseResolver.java cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/ReadCallback.java cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/RepairCallback.java Propchange: cassandra/branches/cassandra-0.8/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Apr 28 13:26:28 2011 @@ -1,5 +1,5 @@ /cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1081914,1083000 -/cassandra/branches/cassandra-0.7:1026516-1096531,1096805 +/cassandra/branches/cassandra-0.7:1026516-1096531,1096805,1097448 /cassandra/branches/cassandra-0.7.0:1053690-1055654 /cassandra/tags/cassandra-0.7.0-rc3:1051699-1053689 /cassandra/trunk:1090978-1090979 Modified: cassandra/branches/cassandra-0.8/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/CHANGES.txt?rev=1097449&r1=1097448&r2=1097449&view=diff == --- cassandra/branches/cassandra-0.8/CHANGES.txt (original) +++ cassandra/branches/cassandra-0.8/CHANGES.txt Thu Apr 28 13:26:28 2011 @@ -8,6 +8,8 @@ * disallow making schema changes to system keyspace (CASSANDRA-2563) * fix batch_mutate for mixed standard-counter mutations (CASSANDRA-2457) * fix sending mutation messages multiple times (CASSANDRA-2557) + * fix incorrect use of NBHM.size in ReadCallback that could cause + reads to time out even when responses were received (CASSAMDRA-2552) 0.8.0-beta1 Propchange: cassandra/branches/cassandra-0.8/contrib/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Apr 28 13:26:28 2011 @@ -1,5 +1,5 @@ /cassandra/branches/cassandra-0.6/contrib:922689-1052356,1052358-1053452,1053454,1053456-1068009 -/cassandra/branches/cassandra-0.7/contrib:1026516-1096531,1096805 +/cassandra/branches/cassandra-0.7/contrib:1026516-1096531,1096805,1097448 /cassandra/branches/cassandra-0.7.0/contrib:1053690-1055654 /cassandra/tags/cassandra-0.7.0-rc3/contrib:1051699-1053689 /cassandra/trunk/contrib:1090978-1090979 Propchange: cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Apr 28 13:26:28 2011 @@ -1,5 +1,5 @@ /cassandra/branches/cassandra-0.6/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:922689-1052356,1052358-1053452,1053454,1053456-1081914,1083000 -/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1096531,1096805 +/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1096531,1096805,1097448 /cassandra/branches/cassandra-0.7.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1053690-1055654 /cassandra/tags/cassandra-0.7.0-rc3/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1051699-1053689 /cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1090978-1090979 Propchange: cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Apr 28 13:26:28 2011 @@ -1,
svn commit: r1097448 - in /cassandra/branches/cassandra-0.7: ./ src/java/org/apache/cassandra/service/
Author: jbellis
Date: Thu Apr 28 13:24:22 2011
New Revision: 1097448
URL: http://svn.apache.org/viewvc?rev=1097448&view=rev
Log:
fix incorrect use ofNBHM.size in ReadCallback
patch by jbellis; reviewed by stuhood for CASSANDRA-2552
Modified:
cassandra/branches/cassandra-0.7/CHANGES.txt
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/AbstractRowResolver.java
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/AsyncRepairCallback.java
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/DatacenterReadCallback.java
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/IResponseResolver.java
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/RangeSliceResponseResolver.java
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/ReadCallback.java
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/RepairCallback.java
Modified: cassandra/branches/cassandra-0.7/CHANGES.txt
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/CHANGES.txt?rev=1097448&r1=1097447&r2=1097448&view=diff
==
--- cassandra/branches/cassandra-0.7/CHANGES.txt (original)
+++ cassandra/branches/cassandra-0.7/CHANGES.txt Thu Apr 28 13:24:22 2011
@@ -1,6 +1,8 @@
0.7.6
* force GC to reclaim disk space on flush, if necessary (CASSANDRA-2404)
* move gossip heartbeat back to its own thread (CASSANDRA-2554)
+ * fix incorrect use of NBHM.size in ReadCallback that could cause
+ reads to time out even when responses were received (CASSAMDRA-2552)
0.7.5
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/AbstractRowResolver.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/AbstractRowResolver.java?rev=1097448&r1=1097447&r2=1097448&view=diff
==
---
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/AbstractRowResolver.java
(original)
+++
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/AbstractRowResolver.java
Thu Apr 28 13:24:22 2011
@@ -83,9 +83,4 @@ public abstract class AbstractRowResolve
{
return replies.keySet();
}
-
-public int getMessageCount()
-{
-return replies.size();
-}
}
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/AsyncRepairCallback.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/AsyncRepairCallback.java?rev=1097448&r1=1097447&r2=1097448&view=diff
==
---
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/AsyncRepairCallback.java
(original)
+++
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/AsyncRepairCallback.java
Thu Apr 28 13:24:22 2011
@@ -22,6 +22,7 @@ package org.apache.cassandra.service;
import java.io.IOException;
+import java.util.concurrent.atomic.AtomicInteger;
import org.apache.cassandra.concurrent.Stage;
import org.apache.cassandra.concurrent.StageManager;
@@ -32,18 +33,19 @@ import org.apache.cassandra.utils.Wrappe
public class AsyncRepairCallback implements IAsyncCallback
{
private final RowRepairResolver repairResolver;
-private final int count;
+private final int blockfor;
+protected final AtomicInteger received = new AtomicInteger(0);
-public AsyncRepairCallback(RowRepairResolver repairResolver, int count)
+public AsyncRepairCallback(RowRepairResolver repairResolver, int blockfor)
{
this.repairResolver = repairResolver;
-this.count = count;
+this.blockfor = blockfor;
}
public void response(Message message)
{
repairResolver.preprocess(message);
-if (repairResolver.getMessageCount() == count)
+if (received.incrementAndGet() == blockfor)
{
StageManager.getStage(Stage.READ_REPAIR).execute(new
WrappedRunnable()
{
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/DatacenterReadCallback.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/DatacenterReadCallback.java?rev=1097448&r1=1097447&r2=1097448&view=diff
==
---
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/DatacenterReadCallback.java
(original)
+++
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/DatacenterReadCallback.java
Thu Apr 28 13:24:22 2011
@@ -23,7 +23,6 @@ package org.apache.cassandra.service;
import java.net.InetAddress;
import java.util.List;
-import java.util.co
svn commit: r1097443 - /cassandra/tags/cassandra-0.7.5/
Author: slebresne Date: Thu Apr 28 13:06:09 2011 New Revision: 1097443 URL: http://svn.apache.org/viewvc?rev=1097443&view=rev Log: Tag 0.7.5 release Added: cassandra/tags/cassandra-0.7.5/ (props changed) - copied from r1095960, cassandra/branches/cassandra-0.7/ Propchange: cassandra/tags/cassandra-0.7.5/ -- --- svn:ignore (added) +++ svn:ignore Thu Apr 28 13:06:09 2011 @@ -0,0 +1,8 @@ +.classpath +.project +.settings +temp-testng-customsuite.xml +build +build.properties +.idea +out Propchange: cassandra/tags/cassandra-0.7.5/ -- --- svn:mergeinfo (added) +++ svn:mergeinfo Thu Apr 28 13:06:09 2011 @@ -0,0 +1,9 @@ +/cassandra/branches/cassandra-0.6:922689-1081914,1083000 +/cassandra/branches/cassandra-0.7:1026516,1035666,1050269 +/cassandra/branches/cassandra-0.7.0:1053690-1055654 +/cassandra/tags/cassandra-0.7.0-rc3:1051699-1053689 +/cassandra/trunk:1026516-1026734,1028929 +/incubator/cassandra/branches/cassandra-0.3:774578-796573 +/incubator/cassandra/branches/cassandra-0.4:810145-834239,834349-834350 +/incubator/cassandra/branches/cassandra-0.5:72-915439 +/incubator/cassandra/branches/cassandra-0.6:911237-922688
[Cassandra Wiki] Trivial Update of "HadoopSupport" by SilvereLestang
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "HadoopSupport" page has been changed by SilvereLestang. The comment on this change is: Fix and add URLs. http://wiki.apache.org/cassandra/HadoopSupport?action=diff&rev1=30&rev2=31 -- <> == Overview == - Cassandra 0.6+ enables certain Hadoop functionality against Cassandra's data store. Specifically, support has been added for [[http://hadoop.apache.org/mapreduce/|MapReduce]], [[http://pig.apache.org|Pig]] and [[http://hive.apache.org/|Hive]]. + Cassandra 0.6+ enables certain [[http://hadoop.apache.org/|Hadoop]] functionality against Cassandra's data store. Specifically, support has been added for [[http://hadoop.apache.org/mapreduce/|MapReduce]], [[http://pig.apache.org|Pig]] and [[http://hive.apache.org/|Hive]]. [[#Top|Top]] @@ -22, +22 @@ == MapReduce == Input from Cassandra - Cassandra 0.6+ adds support for retrieving data from Cassandra. This is based on implementations of [[http://hadoop.apache.org/common/docs/current/api/org/apache/hadoop/mapreduce/InputSplit.html|InputSplit]], [[http://hadoop.apache.org/common/docs/current/api/org/apache/hadoop/mapreduce/InputFormat.html|InputFormat]], and [[http://hadoop.apache.org/common/docs/current/api/org/apache/hadoop/mapreduce/RecordReader.html|RecordReader]] so that Hadoop !MapReduce jobs can retrieve data from Cassandra. For an example of how this works, see the contrib/word_count example in 0.6 or later. Cassandra rows or row fragments (that is, pairs of key + `SortedMap` of columns) are input to Map tasks for processing by your job, as specified by a `SlicePredicate` that describes which columns to fetch from each row. + Cassandra 0.6+ adds support for retrieving data from Cassandra. This is based on implementations of [[http://hadoop.apache.org/mapreduce/docs/current/api/org/apache/hadoop/mapreduce/InputSplit.html|InputSplit]], [[http://hadoop.apache.org/mapreduce/docs/current/api/org/apache/hadoop/mapreduce/InputFormat.html|InputFormat]], and [[http://hadoop.apache.org/mapreduce/docs/current/api/org/apache/hadoop/mapreduce/RecordReader.html|RecordReader]] so that Hadoop !MapReduce jobs can retrieve data from Cassandra. For an example of how this works, see the contrib/word_count example in 0.6 or later. Cassandra rows or row fragments (that is, pairs of key + `SortedMap` of columns) are input to Map tasks for processing by your job, as specified by a `SlicePredicate` that describes which columns to fetch from each row. Here's how this looks in the word_count example, which selects just one configurable columnName from each row:
[jira] [Commented] (CASSANDRA-2536) Schema disagreements when using connections to multiple hosts
[ https://issues.apache.org/jira/browse/CASSANDRA-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13026292#comment-13026292 ] Gary Dusbabek commented on CASSANDRA-2536: -- bq. any thoughts... I was going to add some jmx to get the last N schema versions (seems like it would be handy anyway and will be necessary if we ever get the rollback pony). Send schema to node A, verify that schema is propagated to B, send schema to B and watch the problem happen. The code to start looking at are the Definitions*VerbHandlers. Schema version is tracked in two places: gossip and in DatabaseDescriptor.defsVersion. Make sure those are reasonably in sync (was the sourced of one bug in the past). > Schema disagreements when using connections to multiple hosts > - > > Key: CASSANDRA-2536 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2536 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.8 beta 1 > Environment: Two node 0.8-beta1 cluster with one seed and JNA. >Reporter: Tyler Hobbs >Assignee: Gary Dusbabek > Attachments: schema_disagree.py > > > If you have two thrift connections open to different nodes and you create a > KS using the first, then a CF in that KS using the second, you wind up with a > schema disagreement even if you wait/sleep after creating the KS. > The attached script reproduces the issue using pycassa (1.0.6 should work > fine, although it has the 0.7 thrift-gen code). It's also reproducible by > hand with two cassandra-cli sessions. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1097434 - /cassandra/branches/cassandra-0.8/CHANGES.txt
Author: jbellis Date: Thu Apr 28 12:30:54 2011 New Revision: 1097434 URL: http://svn.apache.org/viewvc?rev=1097434&view=rev Log: add #2557 to CHANGES Modified: cassandra/branches/cassandra-0.8/CHANGES.txt Modified: cassandra/branches/cassandra-0.8/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/CHANGES.txt?rev=1097434&r1=1097433&r2=1097434&view=diff == --- cassandra/branches/cassandra-0.8/CHANGES.txt (original) +++ cassandra/branches/cassandra-0.8/CHANGES.txt Thu Apr 28 12:30:54 2011 @@ -7,6 +7,7 @@ * validate cql TRUNCATE columnfamily before truncating (CASSANDRA-2570) * disallow making schema changes to system keyspace (CASSANDRA-2563) * fix batch_mutate for mixed standard-counter mutations (CASSANDRA-2457) + * fix sending mutation messages multiple times (CASSANDRA-2557) 0.8.0-beta1
[jira] [Commented] (CASSANDRA-2556) DatacenterReadResolver not triggering repair
[ https://issues.apache.org/jira/browse/CASSANDRA-2556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13026265#comment-13026265 ] Sylvain Lebresne commented on CASSANDRA-2556: - +1 The patch applies on top of 0.8 (that is on top of CASSANDRA-2552 v2 for 0.8). Should be backported to 0.7 first I think. > DatacenterReadResolver not triggering repair > > > Key: CASSANDRA-2556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2556 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.7.0 >Reporter: Stu Hood >Assignee: Jonathan Ellis >Priority: Minor > Fix For: 0.7.6 > > Attachments: 2556.txt > > > DatacenterReadResolver only calls maybeResolveForRepair for local reads. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2575) make forceUserDefinedCompaction actually do what it says
[ https://issues.apache.org/jira/browse/CASSANDRA-2575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13026243#comment-13026243 ] Sylvain Lebresne commented on CASSANDRA-2575: - I suppose we could backport to 0.7 too. Also wondering if it couldn't make sense to not compact if we end up with only 1 sstable in doCompaction, now that you still can do a userDefinedCompaction on only 1 sstable. Not being able to compact the 2 smallest sstables seems pathological enough and it would be nice to avoid the 'same sstable compacted forever' problem seen in the mail thread above. Anyway, +1 on the patch. > make forceUserDefinedCompaction actually do what it says > > > Key: CASSANDRA-2575 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2575 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.7.1 >Reporter: Jonathan Ellis >Assignee: Jonathan Ellis >Priority: Minor > Fix For: 0.8.0 > > Attachments: 2575.txt > > > See http://www.mail-archive.com/user@cassandra.apache.org/msg12621.html for > motivation -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
buildbot failure in ASF Buildbot on cassandra-trunk
The Buildbot has detected a new failure on builder cassandra-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/cassandra-trunk/builds/1288 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: isis_ubuntu Build Reason: scheduler Build Source Stamp: [branch cassandra/trunk] 1097388 Blamelist: slebresne BUILD FAILED: failed compile sincerely, -The Buildbot
svn commit: r1097388 - in /cassandra/trunk: ./ contrib/ interface/thrift/gen-java/org/apache/cassandra/thrift/
Author: slebresne Date: Thu Apr 28 09:52:57 2011 New Revision: 1097388 URL: http://svn.apache.org/viewvc?rev=1097388&view=rev Log: merge from 0.8 Modified: cassandra/trunk/ (props changed) cassandra/trunk/CHANGES.txt cassandra/trunk/contrib/ (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/NotFoundException.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/SuperColumn.java (props changed) Propchange: cassandra/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Apr 28 09:52:57 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1081914,1083000 /cassandra/branches/cassandra-0.7:1026516-1096531,1096805 /cassandra/branches/cassandra-0.7.0:1053690-1055654 -/cassandra/branches/cassandra-0.8:1090935-1097141 +/cassandra/branches/cassandra-0.8:1090935-1097141,1097387 /cassandra/tags/cassandra-0.7.0-rc3:1051699-1053689 /incubator/cassandra/branches/cassandra-0.3:774578-796573 /incubator/cassandra/branches/cassandra-0.4:810145-834239,834349-834350 Modified: cassandra/trunk/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/trunk/CHANGES.txt?rev=1097388&r1=1097387&r2=1097388&view=diff == --- cassandra/trunk/CHANGES.txt (original) +++ cassandra/trunk/CHANGES.txt Thu Apr 28 09:52:57 2011 @@ -10,6 +10,7 @@ * fix nodetool setcompactionthroughput (CASSANDRA-2550) * movegossip heartbeat back to its own thread (CASSANDRA-2554) * validate cql TRUNCATE columnfamily before truncating (CASSANDRA-2570) + * fix batch_mutate for mixed standard-counter mutations (CASSANDRA-2457) 0.8.0-beta1 Propchange: cassandra/trunk/contrib/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Apr 28 09:52:57 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6/contrib:922689-1052356,1052358-1053452,1053454,1053456-1068009 /cassandra/branches/cassandra-0.7/contrib:1026516-1096531,1096805 /cassandra/branches/cassandra-0.7.0/contrib:1053690-1055654 -/cassandra/branches/cassandra-0.8/contrib:1090935-1097141 +/cassandra/branches/cassandra-0.8/contrib:1090935-1097141,1097387 /cassandra/tags/cassandra-0.7.0-rc3/contrib:1051699-1053689 /incubator/cassandra/branches/cassandra-0.3/contrib:774578-796573 /incubator/cassandra/branches/cassandra-0.4/contrib:810145-810987,810994-834239,834349-834350 Propchange: cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Apr 28 09:52:57 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:922689-1052356,1052358-1053452,1053454,1053456-1081914,1083000 /cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1096531,1096805 /cassandra/branches/cassandra-0.7.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1053690-1055654 -/cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1090935-1097141 +/cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1090935-1097141,1097387 /cassandra/tags/cassandra-0.7.0-rc3/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1051699-1053689 /incubator/cassandra/branches/cassandra-0.3/interface/gen-java/org/apache/cassandra/service/Cassandra.java:774578-796573 /incubator/cassandra/branches/cassandra-0.4/interface/gen-java/org/apache/cassandra/service/Cassandra.java:810145-834239,834349-834350 Propchange: cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Apr 28 09:52:57 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:922689-1052356,1052358-1053452,1053454,1053456-1081914,1083000 /cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1026516-1096531,1096805 /cassandra/branches/cassandra-0.7.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1053690-1055654 -/cassandra/branches/cassandra-0.8/interf
svn commit: r1097387 - /cassandra/branches/cassandra-0.8/CHANGES.txt
Author: slebresne Date: Thu Apr 28 09:50:22 2011 New Revision: 1097387 URL: http://svn.apache.org/viewvc?rev=1097387&view=rev Log: Update changelog Modified: cassandra/branches/cassandra-0.8/CHANGES.txt Modified: cassandra/branches/cassandra-0.8/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/CHANGES.txt?rev=1097387&r1=1097386&r2=1097387&view=diff == --- cassandra/branches/cassandra-0.8/CHANGES.txt (original) +++ cassandra/branches/cassandra-0.8/CHANGES.txt Thu Apr 28 09:50:22 2011 @@ -6,6 +6,7 @@ * movegossip heartbeat back to its own thread (CASSANDRA-2554) * validate cql TRUNCATE columnfamily before truncating (CASSANDRA-2570) * disallow making schema changes to system keyspace (CASSANDRA-2563) + * fix batch_mutate for mixed standard-counter mutations (CASSANDRA-2457) 0.8.0-beta1
[jira] [Updated] (CASSANDRA-2552) ReadResponseResolver Race
[
https://issues.apache.org/jira/browse/CASSANDRA-2552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stu Hood updated CASSANDRA-2552:
Reviewer: stuhood
Assignee: Jonathan Ellis (was: Stu Hood)
> ReadResponseResolver Race
> -
>
> Key: CASSANDRA-2552
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2552
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 0.7.1
>Reporter: Stu Hood
>Assignee: Jonathan Ellis
> Fix For: 0.7.6
>
> Attachments: 0001-Move-Resolvers-to-atomic-append-count.txt,
> 2552-v2-07.txt, 2552-v2.txt, ResolveRaceTest.java
>
>
> When receiving a response, ReadResponseResolver uses a 3 step process to
> decide whether to trigger the condition that enough responses have arrived:
> # Add new response
> # Check response set size
> # Check that data is present
> I think that these steps must have been reordered by the compiler in some
> cases, because I was able to reproduce a case for a QUORUM read where the
> condition is not properly triggered:
> {noformat}
> INFO [RequestResponseStage:15] 2011-04-25 00:26:53,514
> ReadResponseResolver.java (line 87) post append for 1087367065: hasData=false
> in 2 messages
> INFO [RequestResponseStage:8] 2011-04-25 00:26:53,514
> ReadResponseResolver.java (line 87) post append for 1087367065: hasData=true
> in 1 messages
> INFO [pool-1-thread-54] 2011-04-25 00:27:03,516 StorageProxy.java (line 623)
> Read timeout: java.util.concurrent.TimeoutException:
> ReadResponseResolver@1087367065(/10.34.131.109=false,/10.34.132.122=true,)
> {noformat}
> The last line shows that both results were present, and that one of them was
> holding data.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2552) ReadResponseResolver Race
[
https://issues.apache.org/jira/browse/CASSANDRA-2552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13026210#comment-13026210
]
Stu Hood commented on CASSANDRA-2552:
-
+1
I still think a Map is overkill here, but I can't reproduce a race with the v2
algorithm.
> ReadResponseResolver Race
> -
>
> Key: CASSANDRA-2552
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2552
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 0.7.1
>Reporter: Stu Hood
>Assignee: Stu Hood
> Fix For: 0.7.6
>
> Attachments: 0001-Move-Resolvers-to-atomic-append-count.txt,
> 2552-v2-07.txt, 2552-v2.txt, ResolveRaceTest.java
>
>
> When receiving a response, ReadResponseResolver uses a 3 step process to
> decide whether to trigger the condition that enough responses have arrived:
> # Add new response
> # Check response set size
> # Check that data is present
> I think that these steps must have been reordered by the compiler in some
> cases, because I was able to reproduce a case for a QUORUM read where the
> condition is not properly triggered:
> {noformat}
> INFO [RequestResponseStage:15] 2011-04-25 00:26:53,514
> ReadResponseResolver.java (line 87) post append for 1087367065: hasData=false
> in 2 messages
> INFO [RequestResponseStage:8] 2011-04-25 00:26:53,514
> ReadResponseResolver.java (line 87) post append for 1087367065: hasData=true
> in 1 messages
> INFO [pool-1-thread-54] 2011-04-25 00:27:03,516 StorageProxy.java (line 623)
> Read timeout: java.util.concurrent.TimeoutException:
> ReadResponseResolver@1087367065(/10.34.131.109=false,/10.34.132.122=true,)
> {noformat}
> The last line shows that both results were present, and that one of them was
> holding data.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-1818) Record Client API Timeouts
[ https://issues.apache.org/jira/browse/CASSANDRA-1818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stu Hood resolved CASSANDRA-1818. - Resolution: Duplicate Assignee: Stu Hood I guess I opened a second ticket about this: CASSANDRA-2532. Oops. > Record Client API Timeouts > -- > > Key: CASSANDRA-1818 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1818 > Project: Cassandra > Issue Type: Improvement > Components: API >Reporter: Stu Hood >Assignee: Stu Hood >Priority: Minor > > ...in the (DEBUG) logs, and as a metric. If the timed-out-request was logged > in its entirety, perhaps with the remote nodes that we might have had to > block for. > (on a related topic, we don't record the full time taken for API requests: > only for the storage level) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
