[jira] [Commented] (CASSANDRA-1600) Merge get_indexed_slices with get_range_slices
[
https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13011139#comment-13011139
]
Sylvain Lebresne commented on CASSANDRA-1600:
-
Remarks/questions:
* In the thrift API, IndexClause should be deprecated too.
* I believe CASSANDRA-1034 should avoid the start_key and end_key in
RangeSliceCommand (since it preserves the keys in ranges) and thus in the
indexed iterator.
* I think there is a bug with the handling of end_key in getIndexedIterator
with wrapped ranges. If the requested range is wrapped, and a node range r is
before start_key but still in the [start_key, end_key] range (that is, r is
before end_key too), then we will query the index with a slice from start_key
to EMPTY_BB. But for that node that will never return anything, even though it
can very well have rows in the requested range. I actually think that
CASSANDRA-1034 would fix that too, since we'll use the range here instead of
[start_key, end_key] and getRestrictedRange will have taken care of this
problem for us.
* We should put EMPTY_FILTER_CLAUSE in FBUtilities and use it for
getRangeSliceUnfiltered too. And if we remove the {start|end}_key from
RangeSliceCommand, we could use the empty filter clause there too instead of
null and simplify the serializer.
* In getIndexedIterator, why not use the iterator on the returned column
family instead of allocating a new arrayQueue ?
* In RangeSliceVerbHandler, rowFilter is tested again null, but can't be.
Nice refactoring otherwise.
Merge get_indexed_slices with get_range_slices
--
Key: CASSANDRA-1600
URL: https://issues.apache.org/jira/browse/CASSANDRA-1600
Project: Cassandra
Issue Type: New Feature
Components: API
Reporter: Stu Hood
Assignee: Jonathan Ellis
Fix For: 0.8
Attachments:
0001-Add-optional-FilterClause-to-KeyRange-and-support-doin.txt,
0002-allow-get_range_slices-to-apply-filter-to-a-sequential.txt
From a comment on 1157:
{quote}
IndexClause only has a start key for get_indexed_slices, but it would seem
that the reasoning behind using 'KeyRange' for get_range_slices applies there
as well, since if you know the range you care about in the primary index, you
don't want to continue scanning until you exhaust 'count' (or the cluster).
Since it would appear that get_indexed_slices would benefit from a KeyRange,
why not smash get_(range|indexed)_slices together, and make IndexClause an
optional field on KeyRange?
{quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2384) Merge Mutation and CounterMutation thrift structure
Merge Mutation and CounterMutation thrift structure --- Key: CASSANDRA-2384 URL: https://issues.apache.org/jira/browse/CASSANDRA-2384 Project: Cassandra Issue Type: Improvement Components: API Affects Versions: 0.8 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Fix For: 0.8 Standard and counter mutation are in 2 different structures, which prevents from doing a standard and counter mutation in the same batch_mutate (you have to use batch_add for counters). It's probably a good idea to merge CounterMutation and Mutation (and simply remove batch_add) to lift that limitation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2377) NPE During Repair In StreamReplyVerbHandler
[
https://issues.apache.org/jira/browse/CASSANDRA-2377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13011146#comment-13011146
]
Vivek Mishra commented on CASSANDRA-2377:
-
I was going through the changes made. I wonder what should be the value of
reply.getSessionID for:
StreamReply reply = StreamReply.serializer.deserialize(new
DataInputStream(bufIn), message.getVersion());
Should we check for this, instead of
if (session == null)
{
logger.warn(Received stream action + reply.action + for an
unknown session from + message.getFrom());
return;
}
As per log it happens for :
case SESSION_FINISHED:
So changes should be something like this:
if (SESSION_FINISHED.equals(reply.action.))
{
logger.warn(Received stream action + reply.action + for an
unknown session from + message.getFrom());
return;
}
Idea is to save any additional static call on
StreamOutSession.get(message.getFrom(), reply.sessionId), which results in
object instantiation for new PairInetAddress, Long(host, sessionId).
NPE During Repair In StreamReplyVerbHandler
---
Key: CASSANDRA-2377
URL: https://issues.apache.org/jira/browse/CASSANDRA-2377
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.7.4
Environment: CentOS
Reporter: Benjamin Coverston
Assignee: Brandon Williams
Fix For: 0.7.5
Attachments: 2377.txt
ERROR [MiscStage:4] 2011-03-24 02:45:05,172 DebuggableThreadPoolExecutor.java
(line 103) Error in ThreadPoolExecutorjava.lang.NullPointerException
at
org.apache.cassandra.streaming.StreamReplyVerbHandler.doVerb(StreamReplyVerbHandler.java:62)
at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:72)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
Source)at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
Source)
at java.lang.Thread.run(Unknown Source)
ERROR [MiscStage:4] 2011-03-24 02:45:05,172 AbstractCassandraDaemon.java
(line 112) Fatal exception in thread
Thread[MiscStage:4,5,main]java.lang.NullPointerException
at
org.apache.cassandra.streaming.StreamReplyVerbHandler.doVerb(StreamReplyVerbHandler.java:62)
at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:72)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
Source)at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
Source)
at java.lang.Thread.run(Unknown Source)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2321) Counter column values shows in hex values. Need to show it in string value.
[
https://issues.apache.org/jira/browse/CASSANDRA-2321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-2321:
Attachment: (was: 0001-Don-t-allow-normal-query-on-counter-CF.patch)
Counter column values shows in hex values. Need to show it in string value.
---
Key: CASSANDRA-2321
URL: https://issues.apache.org/jira/browse/CASSANDRA-2321
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.8
Environment: Linux
Reporter: Mubarak Seyed
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 0.8
Attachments: 0001-Don-t-allow-normal-query-on-counter-CF.patch
CounterColumnType.getString() returns hexString.
{code}
public String getString(ByteBuffer bytes)
{
return ByteBufferUtil.bytesToHex(bytes);
}
{code}
and python stress.py reader returns
[ColumnOrSuperColumn(column=None, super_column=SuperColumn(name='19',
columns=[Column(timestamp=1299984960277, name='56',
value='\x7f\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x08\x00\x00\x00\x00\x00\x00\x00,',
ttl=None), Column(timestamp=1299985019923, name='57',
value='\x7f\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00;\x00\x00\x00\x00\x00\x00\x08\xfd',
ttl=None))]
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2321) Counter column values shows in hex values. Need to show it in string value.
[
https://issues.apache.org/jira/browse/CASSANDRA-2321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-2321:
Attachment: 0001-Don-t-allow-normal-query-on-counter-CF.patch
Rebased patch attached
Counter column values shows in hex values. Need to show it in string value.
---
Key: CASSANDRA-2321
URL: https://issues.apache.org/jira/browse/CASSANDRA-2321
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.8
Environment: Linux
Reporter: Mubarak Seyed
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 0.8
Attachments: 0001-Don-t-allow-normal-query-on-counter-CF.patch
CounterColumnType.getString() returns hexString.
{code}
public String getString(ByteBuffer bytes)
{
return ByteBufferUtil.bytesToHex(bytes);
}
{code}
and python stress.py reader returns
[ColumnOrSuperColumn(column=None, super_column=SuperColumn(name='19',
columns=[Column(timestamp=1299984960277, name='56',
value='\x7f\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x08\x00\x00\x00\x00\x00\x00\x00,',
ttl=None), Column(timestamp=1299985019923, name='57',
value='\x7f\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00;\x00\x00\x00\x00\x00\x00\x08\xfd',
ttl=None))]
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2384) Merge Mutation and CounterMutation thrift structure
[ https://issues.apache.org/jira/browse/CASSANDRA-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-2384: Attachment: 0002-Merge-CounterMutation-and-Mutation.patch 0001-Make-thrift-changes.patch Attaching patch against trunk. The code apply after CASSANDRA-2321 because the refactoring of ThriftValidation in there allows to do proper validation for this patch. An added benefits is that right now, when we receive a CounterMutation, we transform it into a Mutation to use generic code. This patch now avoids this useless re-encapsulation. Merge Mutation and CounterMutation thrift structure --- Key: CASSANDRA-2384 URL: https://issues.apache.org/jira/browse/CASSANDRA-2384 Project: Cassandra Issue Type: Improvement Components: API Affects Versions: 0.8 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Fix For: 0.8 Attachments: 0001-Make-thrift-changes.patch, 0002-Merge-CounterMutation-and-Mutation.patch Original Estimate: 2h Remaining Estimate: 2h Standard and counter mutation are in 2 different structures, which prevents from doing a standard and counter mutation in the same batch_mutate (you have to use batch_add for counters). It's probably a good idea to merge CounterMutation and Mutation (and simply remove batch_add) to lift that limitation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2382) statistics component not fsynced
[ https://issues.apache.org/jira/browse/CASSANDRA-2382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13011200#comment-13011200 ] Jonathan Ellis commented on CASSANDRA-2382: --- bq. Not sure what to do about CompactSerializerTest Gary says the point of CST was to test message serialization rather than on disk and EHS got lumped in because it was using ICS instead of ISC2 like the other disk serializers (ColumnFamily and childeren). So removing it from the CST list is the right fix here. committed w/ that change. statistics component not fsynced Key: CASSANDRA-2382 URL: https://issues.apache.org/jira/browse/CASSANDRA-2382 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.0 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 0.7.5 Attachments: 2382.txt The statistics file is prone to getting lost during a hard reset since it is not fsynced like the other sstable components. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1085372 - in /cassandra/branches/cassandra-0.7: CHANGES.txt src/java/org/apache/cassandra/io/sstable/SSTableWriter.java src/java/org/apache/cassandra/utils/EstimatedHistogram.java test/un
Author: jbellis
Date: Fri Mar 25 13:59:45 2011
New Revision: 1085372
URL: http://svn.apache.org/viewvc?rev=1085372view=rev
Log:
fsync statistics component on write
patch by jbellis; reviewed by brandonwilliams for CASSANDRA-2382
Modified:
cassandra/branches/cassandra-0.7/CHANGES.txt
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/io/sstable/SSTableWriter.java
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/utils/EstimatedHistogram.java
cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/io/CompactSerializerTest.java
Modified: cassandra/branches/cassandra-0.7/CHANGES.txt
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/CHANGES.txt?rev=1085372r1=1085371r2=1085372view=diff
==
--- cassandra/branches/cassandra-0.7/CHANGES.txt (original)
+++ cassandra/branches/cassandra-0.7/CHANGES.txt Fri Mar 25 13:59:45 2011
@@ -18,6 +18,7 @@
* fix encoding bugs in HintedHandoffManager, SystemTable when default
charset is not UTF8 (CASSANDRA-2367)
* allow negative numbers in the cli (CASSANDRA-2358)
+ * fsync statistics component on write (CASSANDRA-2382)
0.7.4
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/io/sstable/SSTableWriter.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/io/sstable/SSTableWriter.java?rev=1085372r1=1085371r2=1085372view=diff
==
---
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/io/sstable/SSTableWriter.java
(original)
+++
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/io/sstable/SSTableWriter.java
Fri Mar 25 13:59:45 2011
@@ -198,7 +198,10 @@ public class SSTableWriter extends SSTab
private static void writeStatistics(Descriptor desc, EstimatedHistogram
rowSizes, EstimatedHistogram columnnCounts) throws IOException
{
-DataOutputStream out = new DataOutputStream(new
FileOutputStream(desc.filenameFor(SSTable.COMPONENT_STATS)));
+BufferedRandomAccessFile out = new BufferedRandomAccessFile(new
File(desc.filenameFor(SSTable.COMPONENT_STATS)),
+ rw,
+
BufferedRandomAccessFile.DEFAULT_BUFFER_SIZE,
+ true);
EstimatedHistogram.serializer.serialize(rowSizes, out);
EstimatedHistogram.serializer.serialize(columnnCounts, out);
out.close();
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/utils/EstimatedHistogram.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/utils/EstimatedHistogram.java?rev=1085372r1=1085371r2=1085372view=diff
==
---
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/utils/EstimatedHistogram.java
(original)
+++
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/utils/EstimatedHistogram.java
Fri Mar 25 13:59:45 2011
@@ -18,13 +18,13 @@
*/
package org.apache.cassandra.utils;
-import java.io.DataInputStream;
-import java.io.DataOutputStream;
+import java.io.DataInput;
+import java.io.DataOutput;
import java.io.IOException;
import java.util.Arrays;
import java.util.concurrent.atomic.AtomicLongArray;
-import org.apache.cassandra.io.ICompactSerializer;
+import org.apache.cassandra.io.ICompactSerializer2;
public class EstimatedHistogram
{
@@ -188,9 +188,9 @@ public class EstimatedHistogram
return buckets.get(buckets.length() - 1) 0;
}
-public static class EstimatedHistogramSerializer implements
ICompactSerializerEstimatedHistogram
+public static class EstimatedHistogramSerializer implements
ICompactSerializer2EstimatedHistogram
{
-public void serialize(EstimatedHistogram eh, DataOutputStream dos)
throws IOException
+public void serialize(EstimatedHistogram eh, DataOutput dos) throws
IOException
{
long[] offsets = eh.getBucketOffsets();
long[] buckets = eh.getBuckets(false);
@@ -202,7 +202,7 @@ public class EstimatedHistogram
}
}
-public EstimatedHistogram deserialize(DataInputStream dis) throws
IOException
+public EstimatedHistogram deserialize(DataInput dis) throws IOException
{
int size = dis.readInt();
long[] offsets = new long[size - 1];
Modified:
cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/io/CompactSerializerTest.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/io/CompactSerializerTest.java?rev=1085372r1=1085371r2=1085372view=diff
svn commit: r1085378 - in /cassandra/trunk: ./ contrib/ interface/thrift/gen-java/org/apache/cassandra/thrift/ src/java/org/apache/cassandra/io/sstable/
Author: jbellis Date: Fri Mar 25 14:03:31 2011 New Revision: 1085378 URL: http://svn.apache.org/viewvc?rev=1085378view=rev Log: merge from 0.7 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) cassandra/trunk/src/java/org/apache/cassandra/io/sstable/SSTableWriter.java Propchange: cassandra/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Fri Mar 25 14:03:31 2011 @@ -1,5 +1,5 @@ /cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1081914,1083000 -/cassandra/branches/cassandra-0.7:1026516-1084291 +/cassandra/branches/cassandra-0.7:1026516-1084291,1085372 /cassandra/branches/cassandra-0.7.0:1053690-1055654 /cassandra/tags/cassandra-0.7.0-rc3:1051699-1053689 /incubator/cassandra/branches/cassandra-0.3:774578-796573 Modified: cassandra/trunk/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/trunk/CHANGES.txt?rev=1085378r1=1085377r2=1085378view=diff == --- cassandra/trunk/CHANGES.txt (original) +++ cassandra/trunk/CHANGES.txt Fri Mar 25 14:03:31 2011 @@ -28,6 +28,7 @@ the same threshold for TTL expiration (CASSANDRA-2349) * fix race when iterating CFs during add/drop (CASSANDRA-2350) * add ConsistencyLevel command to CLI (CASSANDRA-2354) + * fsync statistics component on write (CASSANDRA-2382) 0.7.4 Propchange: cassandra/trunk/contrib/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Fri Mar 25 14:03:31 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-1084291 +/cassandra/branches/cassandra-0.7/contrib:1026516-1084291,1085372 /cassandra/branches/cassandra-0.7.0/contrib:1053690-1055654 /cassandra/tags/cassandra-0.7.0-rc3/contrib:1051699-1053689 /incubator/cassandra/branches/cassandra-0.3/contrib:774578-796573 Propchange: cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Fri Mar 25 14:03:31 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-1084291 +/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1084291,1085372 /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 /incubator/cassandra/branches/cassandra-0.3/interface/gen-java/org/apache/cassandra/service/Cassandra.java:774578-796573 Propchange: cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Fri Mar 25 14:03:31 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-1084291 +/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1026516-1084291,1085372 /cassandra/branches/cassandra-0.7.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1053690-1055654 /cassandra/tags/cassandra-0.7.0-rc3/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1051699-1053689 /incubator/cassandra/branches/cassandra-0.3/interface/gen-java/org/apache/cassandra/service/column_t.java:774578-792198 Propchange: cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java -- --- svn:mergeinfo
[jira] [Created] (CASSANDRA-2385) Cassandra does not start due to: attempted to delete non-existing file HintsColumnFamily-tmp-f-180-Data.db
Cassandra does not start due to: attempted to delete non-existing file HintsColumnFamily-tmp-f-180-Data.db -- Key: CASSANDRA-2385 URL: https://issues.apache.org/jira/browse/CASSANDRA-2385 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.4 Reporter: Thibaut Fix For: 0.7.5 Had one node restarting again and again (after the kernel killing the process due to all memory being used). INFO [main] 2011-03-25 15:23:43,467 AbstractCassandraDaemon.java (line 77) Logging initialized INFO [main] 2011-03-25 15:23:43,482 AbstractCassandraDaemon.java (line 95) Heap size: 3328180224/3328180224 INFO [main] 2011-03-25 15:23:43,484 CLibrary.java (line 61) JNA not found. Native methods will be disabled. INFO [main] 2011-03-25 15:23:43,494 DatabaseDescriptor.java (line 120) Loading settings from file:/software/cassandra/conf/cassandra.yaml INFO [main] 2011-03-25 15:23:43,910 DatabaseDescriptor.java (line 186) DiskAccessMode is standard, indexAccessMode is mmap ERROR [main] 2011-03-25 15:23:43,953 AbstractCassandraDaemon.java (line 331) Exception encountered during startup. java.lang.AssertionError: attempted to delete non-existing file HintsColumnFamily-tmp-f-180-Data.db at org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:46) at org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:41) at org.apache.cassandra.io.sstable.SSTable.delete(SSTable.java:133) at org.apache.cassandra.db.ColumnFamilyStore.scrubDataDirectories(ColumnFamilyStore.java:489) at org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:124) at org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:314) at org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:79) I deleted the corresponding statics file and cassandra restarted. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2386) sstable2json does not work on snapshot without moving the files
sstable2json does not work on snapshot without moving the files
---
Key: CASSANDRA-2386
URL: https://issues.apache.org/jira/browse/CASSANDRA-2386
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 0.6.12
Environment: Redhat Linux
Reporter: Aslak Dirdal
Priority: Minor
sstable2json
../data/MyKeyspace/snapshots/1301066898131-mysnapshot/dockeys-10-Data.db
{
Exception in thread main java.lang.NullPointerException: Unknown
ColumnFamily dockeys in keyspace 1301066898131-mysnapshot
at
org.apache.cassandra.config.DatabaseDescriptor.getComparator(DatabaseDescriptor.java:1169)
at org.apache.cassandra.db.ColumnFamily.create(ColumnFamily.java:68)
at
org.apache.cassandra.io.SSTableReader.makeColumnFamily(SSTableReader.java:582)
at
org.apache.cassandra.db.ColumnFamilySerializer.deserializeFromSSTable(ColumnFamilySerializer.java:158)
at
org.apache.cassandra.io.IteratingRow.getColumnFamily(IteratingRow.java:79)
at
org.apache.cassandra.tools.SSTableExport.serializeRow(SSTableExport.java:110)
at
org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:270)
at
org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:302)
at
org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:326)
at org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:370)
sstable2json seem to think that the foldername 1301066898131-mysnapshot is
the Kayspace name.
Moving the *.db files to a folder with the same name as the Keyspace is a
workaround.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2386) sstable2json does not work on snapshot without moving the files
[
https://issues.apache.org/jira/browse/CASSANDRA-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aslak Dirdal updated CASSANDRA-2386:
Description:
sstable2json
../data/MyKeyspace/snapshots/1301066898131-mysnapshot/dockeys-10-Data.db
{
Exception in thread main java.lang.NullPointerException: Unknown
ColumnFamily dockeys in keyspace 1301066898131-mysnapshot
at
org.apache.cassandra.config.DatabaseDescriptor.getComparator(DatabaseDescriptor.java:1169)
at org.apache.cassandra.db.ColumnFamily.create(ColumnFamily.java:68)
at
org.apache.cassandra.io.SSTableReader.makeColumnFamily(SSTableReader.java:582)
at
org.apache.cassandra.db.ColumnFamilySerializer.deserializeFromSSTable(ColumnFamilySerializer.java:158)
at
org.apache.cassandra.io.IteratingRow.getColumnFamily(IteratingRow.java:79)
at
org.apache.cassandra.tools.SSTableExport.serializeRow(SSTableExport.java:110)
at
org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:270)
at
org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:302)
at
org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:326)
at org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:370)
sstable2json seem to think that the foldername 1301066898131-mysnapshot is
the Keyspace name.
Moving the *.db files to a folder with the same name as the Keyspace is a
workaround.
was:
sstable2json
../data/MyKeyspace/snapshots/1301066898131-mysnapshot/dockeys-10-Data.db
{
Exception in thread main java.lang.NullPointerException: Unknown
ColumnFamily dockeys in keyspace 1301066898131-mysnapshot
at
org.apache.cassandra.config.DatabaseDescriptor.getComparator(DatabaseDescriptor.java:1169)
at org.apache.cassandra.db.ColumnFamily.create(ColumnFamily.java:68)
at
org.apache.cassandra.io.SSTableReader.makeColumnFamily(SSTableReader.java:582)
at
org.apache.cassandra.db.ColumnFamilySerializer.deserializeFromSSTable(ColumnFamilySerializer.java:158)
at
org.apache.cassandra.io.IteratingRow.getColumnFamily(IteratingRow.java:79)
at
org.apache.cassandra.tools.SSTableExport.serializeRow(SSTableExport.java:110)
at
org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:270)
at
org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:302)
at
org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:326)
at org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:370)
sstable2json seem to think that the foldername 1301066898131-mysnapshot is
the Kayspace name.
Moving the *.db files to a folder with the same name as the Keyspace is a
workaround.
sstable2json does not work on snapshot without moving the files
---
Key: CASSANDRA-2386
URL: https://issues.apache.org/jira/browse/CASSANDRA-2386
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 0.6.12
Environment: Redhat Linux
Reporter: Aslak Dirdal
Priority: Minor
sstable2json
../data/MyKeyspace/snapshots/1301066898131-mysnapshot/dockeys-10-Data.db
{
Exception in thread main java.lang.NullPointerException: Unknown
ColumnFamily dockeys in keyspace 1301066898131-mysnapshot
at
org.apache.cassandra.config.DatabaseDescriptor.getComparator(DatabaseDescriptor.java:1169)
at org.apache.cassandra.db.ColumnFamily.create(ColumnFamily.java:68)
at
org.apache.cassandra.io.SSTableReader.makeColumnFamily(SSTableReader.java:582)
at
org.apache.cassandra.db.ColumnFamilySerializer.deserializeFromSSTable(ColumnFamilySerializer.java:158)
at
org.apache.cassandra.io.IteratingRow.getColumnFamily(IteratingRow.java:79)
at
org.apache.cassandra.tools.SSTableExport.serializeRow(SSTableExport.java:110)
at
org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:270)
at
org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:302)
at
org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:326)
at
org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:370)
sstable2json seem to think that the foldername 1301066898131-mysnapshot is
the Keyspace name.
Moving the *.db files to a folder with the same name as the Keyspace is a
workaround.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2385) Cassandra does not start due to: attempted to delete non-existing file HintsColumnFamily-tmp-f-180-Data.db
[ https://issues.apache.org/jira/browse/CASSANDRA-2385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13011265#comment-13011265 ] Jonathan Ellis commented on CASSANDRA-2385: --- Looks like CASSANDRA-2185. Are you sure the node in question is running 0.7.4? Cassandra does not start due to: attempted to delete non-existing file HintsColumnFamily-tmp-f-180-Data.db -- Key: CASSANDRA-2385 URL: https://issues.apache.org/jira/browse/CASSANDRA-2385 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.4 Reporter: Thibaut Fix For: 0.7.5 Had one node restarting again and again (after the kernel killing the process due to all memory being used). INFO [main] 2011-03-25 15:23:43,467 AbstractCassandraDaemon.java (line 77) Logging initialized INFO [main] 2011-03-25 15:23:43,482 AbstractCassandraDaemon.java (line 95) Heap size: 3328180224/3328180224 INFO [main] 2011-03-25 15:23:43,484 CLibrary.java (line 61) JNA not found. Native methods will be disabled. INFO [main] 2011-03-25 15:23:43,494 DatabaseDescriptor.java (line 120) Loading settings from file:/software/cassandra/conf/cassandra.yaml INFO [main] 2011-03-25 15:23:43,910 DatabaseDescriptor.java (line 186) DiskAccessMode is standard, indexAccessMode is mmap ERROR [main] 2011-03-25 15:23:43,953 AbstractCassandraDaemon.java (line 331) Exception encountered during startup. java.lang.AssertionError: attempted to delete non-existing file HintsColumnFamily-tmp-f-180-Data.db at org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:46) at org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:41) at org.apache.cassandra.io.sstable.SSTable.delete(SSTable.java:133) at org.apache.cassandra.db.ColumnFamilyStore.scrubDataDirectories(ColumnFamilyStore.java:489) at org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:124) at org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:314) at org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:79) I deleted the corresponding statics file and cassandra restarted. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2386) sstable2json does not work on snapshot without moving the files
[
https://issues.apache.org/jira/browse/CASSANDRA-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-2386:
--
Affects Version/s: (was: 0.6.12)
Fix Version/s: 0.7.5
sstable2json does not work on snapshot without moving the files
---
Key: CASSANDRA-2386
URL: https://issues.apache.org/jira/browse/CASSANDRA-2386
Project: Cassandra
Issue Type: Bug
Components: Tools
Environment: Redhat Linux
Reporter: Aslak Dirdal
Priority: Minor
Fix For: 0.7.5
sstable2json
../data/MyKeyspace/snapshots/1301066898131-mysnapshot/dockeys-10-Data.db
{
Exception in thread main java.lang.NullPointerException: Unknown
ColumnFamily dockeys in keyspace 1301066898131-mysnapshot
at
org.apache.cassandra.config.DatabaseDescriptor.getComparator(DatabaseDescriptor.java:1169)
at org.apache.cassandra.db.ColumnFamily.create(ColumnFamily.java:68)
at
org.apache.cassandra.io.SSTableReader.makeColumnFamily(SSTableReader.java:582)
at
org.apache.cassandra.db.ColumnFamilySerializer.deserializeFromSSTable(ColumnFamilySerializer.java:158)
at
org.apache.cassandra.io.IteratingRow.getColumnFamily(IteratingRow.java:79)
at
org.apache.cassandra.tools.SSTableExport.serializeRow(SSTableExport.java:110)
at
org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:270)
at
org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:302)
at
org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:326)
at
org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:370)
sstable2json seem to think that the foldername 1301066898131-mysnapshot is
the Keyspace name.
Moving the *.db files to a folder with the same name as the Keyspace is a
workaround.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2385) Cassandra does not start due to: attempted to delete non-existing file HintsColumnFamily-tmp-f-180-Data.db
[ https://issues.apache.org/jira/browse/CASSANDRA-2385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13011271#comment-13011271 ] Thibaut commented on CASSANDRA-2385: Now, as you ask, maybe. I'm not 100% sure it's 0.7.4, as we upgraded this morning. Cassandra does not start due to: attempted to delete non-existing file HintsColumnFamily-tmp-f-180-Data.db -- Key: CASSANDRA-2385 URL: https://issues.apache.org/jira/browse/CASSANDRA-2385 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.4 Reporter: Thibaut Fix For: 0.7.5 Had one node restarting again and again (after the kernel killing the process due to all memory being used). INFO [main] 2011-03-25 15:23:43,467 AbstractCassandraDaemon.java (line 77) Logging initialized INFO [main] 2011-03-25 15:23:43,482 AbstractCassandraDaemon.java (line 95) Heap size: 3328180224/3328180224 INFO [main] 2011-03-25 15:23:43,484 CLibrary.java (line 61) JNA not found. Native methods will be disabled. INFO [main] 2011-03-25 15:23:43,494 DatabaseDescriptor.java (line 120) Loading settings from file:/software/cassandra/conf/cassandra.yaml INFO [main] 2011-03-25 15:23:43,910 DatabaseDescriptor.java (line 186) DiskAccessMode is standard, indexAccessMode is mmap ERROR [main] 2011-03-25 15:23:43,953 AbstractCassandraDaemon.java (line 331) Exception encountered during startup. java.lang.AssertionError: attempted to delete non-existing file HintsColumnFamily-tmp-f-180-Data.db at org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:46) at org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:41) at org.apache.cassandra.io.sstable.SSTable.delete(SSTable.java:133) at org.apache.cassandra.db.ColumnFamilyStore.scrubDataDirectories(ColumnFamilyStore.java:489) at org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:124) at org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:314) at org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:79) I deleted the corresponding statics file and cassandra restarted. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2386) sstable2json does not work on snapshot without moving the files
[
https://issues.apache.org/jira/browse/CASSANDRA-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-2386:
--
Issue Type: Improvement (was: Bug)
sstable2json does not work on snapshot without moving the files
---
Key: CASSANDRA-2386
URL: https://issues.apache.org/jira/browse/CASSANDRA-2386
Project: Cassandra
Issue Type: Improvement
Components: Tools
Environment: Redhat Linux
Reporter: Aslak Dirdal
Priority: Minor
Fix For: 0.7.5
sstable2json
../data/MyKeyspace/snapshots/1301066898131-mysnapshot/dockeys-10-Data.db
{
Exception in thread main java.lang.NullPointerException: Unknown
ColumnFamily dockeys in keyspace 1301066898131-mysnapshot
at
org.apache.cassandra.config.DatabaseDescriptor.getComparator(DatabaseDescriptor.java:1169)
at org.apache.cassandra.db.ColumnFamily.create(ColumnFamily.java:68)
at
org.apache.cassandra.io.SSTableReader.makeColumnFamily(SSTableReader.java:582)
at
org.apache.cassandra.db.ColumnFamilySerializer.deserializeFromSSTable(ColumnFamilySerializer.java:158)
at
org.apache.cassandra.io.IteratingRow.getColumnFamily(IteratingRow.java:79)
at
org.apache.cassandra.tools.SSTableExport.serializeRow(SSTableExport.java:110)
at
org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:270)
at
org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:302)
at
org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:326)
at
org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:370)
sstable2json seem to think that the foldername 1301066898131-mysnapshot is
the Keyspace name.
Moving the *.db files to a folder with the same name as the Keyspace is a
workaround.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-2385) Cassandra does not start due to: attempted to delete non-existing file HintsColumnFamily-tmp-f-180-Data.db
[ https://issues.apache.org/jira/browse/CASSANDRA-2385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-2385. --- Resolution: Duplicate Fix Version/s: (was: 0.7.5) I'll close as duplicate for now then. Please re-open if you see it again. Cassandra does not start due to: attempted to delete non-existing file HintsColumnFamily-tmp-f-180-Data.db -- Key: CASSANDRA-2385 URL: https://issues.apache.org/jira/browse/CASSANDRA-2385 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.4 Reporter: Thibaut Had one node restarting again and again (after the kernel killing the process due to all memory being used). INFO [main] 2011-03-25 15:23:43,467 AbstractCassandraDaemon.java (line 77) Logging initialized INFO [main] 2011-03-25 15:23:43,482 AbstractCassandraDaemon.java (line 95) Heap size: 3328180224/3328180224 INFO [main] 2011-03-25 15:23:43,484 CLibrary.java (line 61) JNA not found. Native methods will be disabled. INFO [main] 2011-03-25 15:23:43,494 DatabaseDescriptor.java (line 120) Loading settings from file:/software/cassandra/conf/cassandra.yaml INFO [main] 2011-03-25 15:23:43,910 DatabaseDescriptor.java (line 186) DiskAccessMode is standard, indexAccessMode is mmap ERROR [main] 2011-03-25 15:23:43,953 AbstractCassandraDaemon.java (line 331) Exception encountered during startup. java.lang.AssertionError: attempted to delete non-existing file HintsColumnFamily-tmp-f-180-Data.db at org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:46) at org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:41) at org.apache.cassandra.io.sstable.SSTable.delete(SSTable.java:133) at org.apache.cassandra.db.ColumnFamilyStore.scrubDataDirectories(ColumnFamilyStore.java:489) at org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:124) at org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:314) at org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:79) I deleted the corresponding statics file and cassandra restarted. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2384) Merge Mutation and CounterMutation thrift structure
[ https://issues.apache.org/jira/browse/CASSANDRA-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13011292#comment-13011292 ] Patricio Echague commented on CASSANDRA-2384: - Awesome. Thank you Sylvain, that simplifies also the Hector design as well. Merge Mutation and CounterMutation thrift structure --- Key: CASSANDRA-2384 URL: https://issues.apache.org/jira/browse/CASSANDRA-2384 Project: Cassandra Issue Type: Improvement Components: API Affects Versions: 0.8 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Fix For: 0.8 Attachments: 0001-Make-thrift-changes.patch, 0002-Merge-CounterMutation-and-Mutation.patch Original Estimate: 2h Remaining Estimate: 2h Standard and counter mutation are in 2 different structures, which prevents from doing a standard and counter mutation in the same batch_mutate (you have to use batch_add for counters). It's probably a good idea to merge CounterMutation and Mutation (and simply remove batch_add) to lift that limitation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2321) Counter column values shows in hex values. Need to show it in string value.
[
https://issues.apache.org/jira/browse/CASSANDRA-2321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13011301#comment-13011301
]
Jonathan Ellis commented on CASSANDRA-2321:
---
I'm not sure this refactor is much of an improvement. Seems like the code
moves around a lot but volume and complexity are not really reduced.
Can't we just add a validateCounterCF to counter calls and
validateNonCounterCF otherwise?
(I'd prefer to say counter/noncounter vs noncommutative/commutative but if
you really prefer the other that's okay too.)
Counter column values shows in hex values. Need to show it in string value.
---
Key: CASSANDRA-2321
URL: https://issues.apache.org/jira/browse/CASSANDRA-2321
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.8
Environment: Linux
Reporter: Mubarak Seyed
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 0.8
Attachments: 0001-Don-t-allow-normal-query-on-counter-CF.patch
CounterColumnType.getString() returns hexString.
{code}
public String getString(ByteBuffer bytes)
{
return ByteBufferUtil.bytesToHex(bytes);
}
{code}
and python stress.py reader returns
[ColumnOrSuperColumn(column=None, super_column=SuperColumn(name='19',
columns=[Column(timestamp=1299984960277, name='56',
value='\x7f\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x08\x00\x00\x00\x00\x00\x00\x00,',
ttl=None), Column(timestamp=1299985019923, name='57',
value='\x7f\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00;\x00\x00\x00\x00\x00\x00\x08\xfd',
ttl=None))]
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-1034) Remove assumption that Key to Token is one-to-one
[ https://issues.apache.org/jira/browse/CASSANDRA-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13011306#comment-13011306 ] Jonathan Ellis commented on CASSANDRA-1034: --- What is LengthPartitioner for? Remove assumption that Key to Token is one-to-one - Key: CASSANDRA-1034 URL: https://issues.apache.org/jira/browse/CASSANDRA-1034 Project: Cassandra Issue Type: Bug Reporter: Stu Hood Assignee: Sylvain Lebresne Priority: Minor Fix For: 0.8 Attachments: 0001-Make-range-accept-both-Token-and-DecoratedKey.patch, 0002-LengthPartitioner.patch, 1034_v1.txt get_range_slices assumes that Tokens do not collide and converts a KeyRange to an AbstractBounds. For RandomPartitioner, this assumption isn't safe, and would lead to a very weird heisenberg. Converting AbstractBounds to use a DecoratedKey would solve this, because the byte[] key portion of the DecoratedKey can act as a tiebreaker. Alternatively, we could make DecoratedKey extend Token, and then use DecoratedKeys in places where collisions are unacceptable. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2377) NPE During Repair In StreamReplyVerbHandler
[ https://issues.apache.org/jira/browse/CASSANDRA-2377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13011308#comment-13011308 ] Brandon Williams commented on CASSANDRA-2377: - An unknown stream action could be received for any of them. It's not hard to imagine a FILE_RETRY happening here, and all of them require a non-null session. NPE During Repair In StreamReplyVerbHandler --- Key: CASSANDRA-2377 URL: https://issues.apache.org/jira/browse/CASSANDRA-2377 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.4 Environment: CentOS Reporter: Benjamin Coverston Assignee: Brandon Williams Fix For: 0.7.5 Attachments: 2377.txt ERROR [MiscStage:4] 2011-03-24 02:45:05,172 DebuggableThreadPoolExecutor.java (line 103) Error in ThreadPoolExecutorjava.lang.NullPointerException at org.apache.cassandra.streaming.StreamReplyVerbHandler.doVerb(StreamReplyVerbHandler.java:62) at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:72) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) ERROR [MiscStage:4] 2011-03-24 02:45:05,172 AbstractCassandraDaemon.java (line 112) Fatal exception in thread Thread[MiscStage:4,5,main]java.lang.NullPointerException at org.apache.cassandra.streaming.StreamReplyVerbHandler.doVerb(StreamReplyVerbHandler.java:62) at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:72) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2387) Create a pig loadstorecaster for the loadfunc/storefunc
Create a pig loadstorecaster for the loadfunc/storefunc --- Key: CASSANDRA-2387 URL: https://issues.apache.org/jira/browse/CASSANDRA-2387 Project: Cassandra Issue Type: Improvement Reporter: Jeremy Hanna Assignee: Jeremy Hanna It appears that after we have applied validators to columns in the metadata that those column values appear as binary data when returned to pig. Validators pack values to bytebuffers to the appropriate width, so that seems to be the issue. So to address this, we should be able to create a loadstorecaster to convert cassandra data types to/from things that are readable by pig. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2387) Create a pig loadstorecaster for the loadfunc/storefunc
[ https://issues.apache.org/jira/browse/CASSANDRA-2387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-2387: Attachment: loadstorecaster-patch.txt Adding a patch with a basic loadstorecaster, wiring into the loadstorefunc, and some adjustments to ByteBufferUtil to help with the loadcaster methods. Create a pig loadstorecaster for the loadfunc/storefunc --- Key: CASSANDRA-2387 URL: https://issues.apache.org/jira/browse/CASSANDRA-2387 Project: Cassandra Issue Type: Improvement Reporter: Jeremy Hanna Assignee: Jeremy Hanna Labels: contrib, hadoop, pig Attachments: loadstorecaster-patch.txt It appears that after we have applied validators to columns in the metadata that those column values appear as binary data when returned to pig. Validators pack values to bytebuffers to the appropriate width, so that seems to be the issue. So to address this, we should be able to create a loadstorecaster to convert cassandra data types to/from things that are readable by pig. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-1034) Remove assumption that Key to Token is one-to-one
[ https://issues.apache.org/jira/browse/CASSANDRA-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13011353#comment-13011353 ] Jonathan Ellis commented on CASSANDRA-1034: --- Initial feedback: - I'm a fan of the RingPosition approach - Less of a fan of pretending that Tokens and DK are equal if the token component of DK is equal. Shouldn't we force caller to ask Token.equals(DK.token) if that's what they mean? As you pointed out in RP docstring, there is not an is-a relationship there. - Should we add RP.isToken to encapsulate RP.asDecoratedKey.key == null checks? - DK docstring is obsolete now Remove assumption that Key to Token is one-to-one - Key: CASSANDRA-1034 URL: https://issues.apache.org/jira/browse/CASSANDRA-1034 Project: Cassandra Issue Type: Bug Reporter: Stu Hood Assignee: Sylvain Lebresne Priority: Minor Fix For: 0.8 Attachments: 0001-Make-range-accept-both-Token-and-DecoratedKey.patch, 0002-LengthPartitioner.patch, 1034_v1.txt get_range_slices assumes that Tokens do not collide and converts a KeyRange to an AbstractBounds. For RandomPartitioner, this assumption isn't safe, and would lead to a very weird heisenberg. Converting AbstractBounds to use a DecoratedKey would solve this, because the byte[] key portion of the DecoratedKey can act as a tiebreaker. Alternatively, we could make DecoratedKey extend Token, and then use DecoratedKeys in places where collisions are unacceptable. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2387) Create a pig loadstorecaster for the loadfunc/storefunc
[ https://issues.apache.org/jira/browse/CASSANDRA-2387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13011354#comment-13011354 ] Brandon Williams commented on CASSANDRA-2387: - This is not really because of validators, but the format the data is stored in. If you're using the cli to insert data, it automatically inspects the CF and discovers the validator, then packs the data accordingly. Create a pig loadstorecaster for the loadfunc/storefunc --- Key: CASSANDRA-2387 URL: https://issues.apache.org/jira/browse/CASSANDRA-2387 Project: Cassandra Issue Type: Improvement Reporter: Jeremy Hanna Assignee: Jeremy Hanna Labels: contrib, hadoop, pig Attachments: loadstorecaster-patch.txt It appears that after we have applied validators to columns in the metadata that those column values appear as binary data when returned to pig. Validators pack values to bytebuffers to the appropriate width, so that seems to be the issue. So to address this, we should be able to create a loadstorecaster to convert cassandra data types to/from things that are readable by pig. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-2383) cassandra.bat does not handle folder names with space characters on windows
[ https://issues.apache.org/jira/browse/CASSANDRA-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-2383: - Assignee: Benjamin Coverston cassandra.bat does not handle folder names with space characters on windows --- Key: CASSANDRA-2383 URL: https://issues.apache.org/jira/browse/CASSANDRA-2383 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.7.4 Environment: OS : windows java : 1.6.0.23 Reporter: david lee Assignee: Benjamin Coverston Priority: Minor Fix For: 0.7.5 when cassandra home folder is placed inside a folder which has space characters in its name, log4j settings are not properly loaded and warning messages are shown. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2383) cassandra.bat does not handle folder names with space characters on windows
[ https://issues.apache.org/jira/browse/CASSANDRA-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2383: -- Fix Version/s: 0.7.5 cassandra.bat does not handle folder names with space characters on windows --- Key: CASSANDRA-2383 URL: https://issues.apache.org/jira/browse/CASSANDRA-2383 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.7.4 Environment: OS : windows java : 1.6.0.23 Reporter: david lee Assignee: Benjamin Coverston Priority: Minor Fix For: 0.7.5 when cassandra home folder is placed inside a folder which has space characters in its name, log4j settings are not properly loaded and warning messages are shown. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2321) Counter column values shows in hex values. Need to show it in string value.
[
https://issues.apache.org/jira/browse/CASSANDRA-2321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13011356#comment-13011356
]
Sylvain Lebresne commented on CASSANDRA-2321:
-
bq. I'm not sure this refactor is much of an improvement. Seems like the code
moves around a lot but volume and complexity are not really reduced.
I do believe the refactor is an improvement (granted, maybe not a huge one).
During validation we do a bunch of queries to DatabaseDescriptor to check the
cf exists, then to get its type (super or standard), then to get its value
validator, etc... Granted those are just hashMaps gets, but they are just
unnecessary. I do think that the method used by the refactor, that is getting
the metadata once and giving it to all other method is cleaner. There also the
fact that we revalidate the column family for each Mutation of a batch_mutate,
even if all of them are on the same cf, which this refactor fixes too.
I don't care so much about those and won't fight over it, but I think it would
be a pity to leave ThriftValidation in that state (and the refactoring is
really trivial). Note that I'll be perfectly ok with moving the refactor in
another ticket if that makes it better.
bq. Can't we just add a validateCounterCF to counter calls and
validateNonCounterCF otherwise?
Yes we could, up to the fact that the refactor would still make sense I think
for the reason above :)
bq. (I'd prefer to say counter/noncounter vs noncommutative/commutative but
if you really prefer the other that's okay too.)
When I have a few free cycles I plan to remove the 'commutative' wording
completely as I think this was premature generalization and make the code less
readable right now. So I'm on your side, I just went for consistency with the
rest of the code for now.
Counter column values shows in hex values. Need to show it in string value.
---
Key: CASSANDRA-2321
URL: https://issues.apache.org/jira/browse/CASSANDRA-2321
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.8
Environment: Linux
Reporter: Mubarak Seyed
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 0.8
Attachments: 0001-Don-t-allow-normal-query-on-counter-CF.patch
CounterColumnType.getString() returns hexString.
{code}
public String getString(ByteBuffer bytes)
{
return ByteBufferUtil.bytesToHex(bytes);
}
{code}
and python stress.py reader returns
[ColumnOrSuperColumn(column=None, super_column=SuperColumn(name='19',
columns=[Column(timestamp=1299984960277, name='56',
value='\x7f\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x08\x00\x00\x00\x00\x00\x00\x00,',
ttl=None), Column(timestamp=1299985019923, name='57',
value='\x7f\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00;\x00\x00\x00\x00\x00\x00\x08\xfd',
ttl=None))]
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2373) Index Out Of Bounds during Validation Compaction (Repair)
[ https://issues.apache.org/jira/browse/CASSANDRA-2373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13011357#comment-13011357 ] Jonathan Ellis commented on CASSANDRA-2373: --- is the sstable small enough to attach? Index Out Of Bounds during Validation Compaction (Repair) - Key: CASSANDRA-2373 URL: https://issues.apache.org/jira/browse/CASSANDRA-2373 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.4 Environment: CentOS on EC2 Reporter: Benjamin Coverston Stack Trace is below: ERROR [CompactionExecutor:1] 2011-03-23 19:11:39,488 AbstractCassandraDaemon.java (line 112) Fatal exception in thread Thread[CompactionExecutor:1,1,main] java.lang.IndexOutOfBoundsException at java.nio.Buffer.checkIndex(Unknown Source) at java.nio.HeapByteBuffer.getInt(Unknown Source) at org.apache.cassandra.db.DeletedColumn.getLocalDeletionTime(DeletedColumn.java:57) at org.apache.cassandra.db.ColumnFamilyStore.removeDeletedStandard(ColumnFamilyStore.java:879) at org.apache.cassandra.db.ColumnFamilyStore.removeDeletedColumnsOnly(ColumnFamilyStore.java:866) at org.apache.cassandra.db.ColumnFamilyStore.removeDeleted(ColumnFamilyStore.java:857) at org.apache.cassandra.io.PrecompactedRow.init(PrecompactedRow.java:94) at org.apache.cassandra.io.CompactionIterator.getCompactedRow(CompactionIterator.java:147) at org.apache.cassandra.io.CompactionIterator.getReduced(CompactionIterator.java:108) at org.apache.cassandra.io.CompactionIterator.getReduced(CompactionIterator.java:43) at org.apache.cassandra.utils.ReducingIterator.computeNext(ReducingIterator.java:73) at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:136) at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:131) at org.apache.commons.collections.iterators.FilterIterator.setNextObject(FilterIterator.java:183) at org.apache.commons.collections.iterators.FilterIterator.hasNext(FilterIterator.java:94) at org.apache.cassandra.db.CompactionManager.doValidationCompaction(CompactionManager.java:822) at org.apache.cassandra.db.CompactionManager.access$800(CompactionManager.java:56) at org.apache.cassandra.db.CompactionManager$6.call(CompactionManager.java:358) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2283) Streaming Old Format Data Fails in 0.7.3 after upgrade from 0.6.8
[ https://issues.apache.org/jira/browse/CASSANDRA-2283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13011360#comment-13011360 ] Jonathan Ellis commented on CASSANDRA-2283: --- IMO the right thing to do here is to deserialize enough of the data sent during stream to (a) rewrite it to latest format and (b) write bloom filter and row index -- currently this is done in a second pass post-stream. Streaming Old Format Data Fails in 0.7.3 after upgrade from 0.6.8 - Key: CASSANDRA-2283 URL: https://issues.apache.org/jira/browse/CASSANDRA-2283 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.3 Environment: 0.7.3 upgraded from 0.6.8, Linux Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode) Reporter: Erik Onnen After successfully upgrading a 0.6.8 ring to 0.7.3, we needed to bootstrap in a new node relatively quickly. When starting the new node with an assigned token in auto bootstrap mode, we see the following exceptions on the new node: INFO [main] 2011-03-07 10:37:32,671 StorageService.java (line 505) Joining: sleeping 3 ms for pending range setup INFO [main] 2011-03-07 10:38:02,679 StorageService.java (line 505) Bootstrapping INFO [HintedHandoff:1] 2011-03-07 10:38:02,899 HintedHandOffManager.java (line 304) Started hinted handoff for endpoint /10.211.14.200 INFO [HintedHandoff:1] 2011-03-07 10:38:02,900 HintedHandOffManager.java (line 360) Finished hinted handoff of 0 rows to endpoint /10.211.14.200 INFO [CompactionExecutor:1] 2011-03-07 10:38:04,924 SSTableReader.java (line 154) Opening /mnt/services/cassandra/var/data/0.7.3/data/Stuff/stuff-f-1 INFO [CompactionExecutor:1] 2011-03-07 10:38:05,390 SSTableReader.java (line 154) Opening /mnt/services/cassandra/var/data/0.7.3/data/Stuff/stuff-f-2 INFO [CompactionExecutor:1] 2011-03-07 10:38:05,768 SSTableReader.java (line 154) Opening /mnt/services/cassandra/var/data/0.7.3/data/Stuff/stuffid-f-1 INFO [CompactionExecutor:1] 2011-03-07 10:38:06,389 SSTableReader.java (line 154) Opening /mnt/services/cassandra/var/data/0.7.3/data/Stuff/stuffid-f-2 INFO [CompactionExecutor:1] 2011-03-07 10:38:06,581 SSTableReader.java (line 154) Opening /mnt/services/cassandra/var/data/0.7.3/data/Stuff/stuffid-f-3 ERROR [CompactionExecutor:1] 2011-03-07 10:38:07,056 AbstractCassandraDaemon.java (line 114) Fatal exception in thread Thread[CompactionExecutor:1,1,main] java.io.EOFException at org.apache.cassandra.io.sstable.IndexHelper.skipIndex(IndexHelper.java:65) at org.apache.cassandra.io.sstable.SSTableWriter$Builder.build(SSTableWriter.java:303) at org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:923) at org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:916) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) INFO [CompactionExecutor:1] 2011-03-07 10:38:08,480 SSTableReader.java (line 154) Opening /mnt/services/cassandra/var/data/0.7.3/data/Stuff/stuffid-f-5 INFO [CompactionExecutor:1] 2011-03-07 10:38:08,582 SSTableReader.java (line 154) Opening /mnt/services/cassandra/var/data/0.7.3/data/Stuff/stuffid_reg_idx-f-1 ERROR [CompactionExecutor:1] 2011-03-07 10:38:08,635 AbstractCassandraDaemon.java (line 114) Fatal exception in thread Thread[CompactionExecutor:1,1,main] java.io.EOFException at org.apache.cassandra.io.sstable.IndexHelper.skipIndex(IndexHelper.java:65) at org.apache.cassandra.io.sstable.SSTableWriter$Builder.build(SSTableWriter.java:303) at org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:923) at org.apache.cassandra.db.CompactionManager$9.call(CompactionManager.java:916) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) ERROR [CompactionExecutor:1] 2011-03-07 10:38:08,666 AbstractCassandraDaemon.java (line 114) Fatal exception in thread Thread[CompactionExecutor:1,1,main] java.io.EOFException at org.apache.cassandra.io.sstable.IndexHelper.skipIndex(IndexHelper.java:65) at
[jira] [Updated] (CASSANDRA-2284) Make changes to the set of memtables and sstables of a cfstore atomic
[ https://issues.apache.org/jira/browse/CASSANDRA-2284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2284: -- Reviewer: jbellis Priority: Minor (was: Major) Issue Type: Improvement (was: Bug) Make changes to the set of memtables and sstables of a cfstore atomic -- Key: CASSANDRA-2284 URL: https://issues.apache.org/jira/browse/CASSANDRA-2284 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 0.8 Attachments: 0001-Make-memtable-and-sstable-switches-atomic-v2.patch, 0001-Make-memtable-and-sstable-switches-atomic.patch Original Estimate: 8h Remaining Estimate: 8h Some switches happen in the set of memtables and sstables of a cfstore: * when we switch the memtable, the current memtable is replaced by a new one and add to the memtablesPendingFlush * when a memtable is fully flushed, it is removed from memtablesPendingFlush and the newly created sstable is added to the set of active sstables. * after compaction, compacted memtables are removed from the active sstables and the compacted sstable is added instead Only the last of these operations is atomic. This ticket proposes to makes all of them atomic, using the idea of the View idea hinted by Stu in the comments of CASSANDRA-1954. The main reason for this is to fix CASSANDRA-2105. But I think that another benefit of this is to make reasoning about those operations easier. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2284) Make changes to the set of memtables and sstables of a cfstore atomic
[
https://issues.apache.org/jira/browse/CASSANDRA-2284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-2284:
--
Attachment: 2284-v2-rebased.txt
I ran tests before committing and I'm seeing this failure:
{noformat}
[junit] Testcase:
testBackupAfterFlush(org.apache.cassandra.db.ColumnFamilyStoreTest): FAILED
[junit] can not find backedup file:Standard1-f-1-Data.db
[junit] junit.framework.AssertionFailedError: can not find backedup
file:Standard1-f-1-Data.db
[junit] at
org.apache.cassandra.db.ColumnFamilyStoreTest.testBackupAfterFlush(ColumnFamilyStoreTest.java:536)
{noformat}
Make changes to the set of memtables and sstables of a cfstore atomic
--
Key: CASSANDRA-2284
URL: https://issues.apache.org/jira/browse/CASSANDRA-2284
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 0.8
Attachments: 0001-Make-memtable-and-sstable-switches-atomic-v2.patch,
0001-Make-memtable-and-sstable-switches-atomic.patch, 2284-v2-rebased.txt
Original Estimate: 8h
Remaining Estimate: 8h
Some switches happen in the set of memtables and sstables of a cfstore:
* when we switch the memtable, the current memtable is replaced by a new
one and add to the memtablesPendingFlush
* when a memtable is fully flushed, it is removed from
memtablesPendingFlush and the newly created sstable is added to the set of
active sstables.
* after compaction, compacted memtables are removed from the active
sstables and the compacted sstable is added instead
Only the last of these operations is atomic. This ticket proposes to makes
all of them atomic, using the idea of the View idea hinted by Stu in the
comments of CASSANDRA-1954.
The main reason for this is to fix CASSANDRA-2105. But I think that another
benefit of this is to make reasoning about those operations easier.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (CASSANDRA-2284) Make changes to the set of memtables and sstables of a cfstore atomic
[ https://issues.apache.org/jira/browse/CASSANDRA-2284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reopened CASSANDRA-2284: --- Make changes to the set of memtables and sstables of a cfstore atomic -- Key: CASSANDRA-2284 URL: https://issues.apache.org/jira/browse/CASSANDRA-2284 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 0.8 Attachments: 0001-Make-memtable-and-sstable-switches-atomic-v2.patch, 0001-Make-memtable-and-sstable-switches-atomic.patch, 2284-v2-rebased.txt Original Estimate: 8h Remaining Estimate: 8h Some switches happen in the set of memtables and sstables of a cfstore: * when we switch the memtable, the current memtable is replaced by a new one and add to the memtablesPendingFlush * when a memtable is fully flushed, it is removed from memtablesPendingFlush and the newly created sstable is added to the set of active sstables. * after compaction, compacted memtables are removed from the active sstables and the compacted sstable is added instead Only the last of these operations is atomic. This ticket proposes to makes all of them atomic, using the idea of the View idea hinted by Stu in the comments of CASSANDRA-1954. The main reason for this is to fix CASSANDRA-2105. But I think that another benefit of this is to make reasoning about those operations easier. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-1034) Remove assumption that Key to Token is one-to-one
[
https://issues.apache.org/jira/browse/CASSANDRA-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13011373#comment-13011373
]
Sylvain Lebresne commented on CASSANDRA-1034:
-
bq. Less of a fan of pretending that Tokens and DK are equal if the token
component of DK is equal. Shouldn't we force caller to ask
Token.equals(DK.token) if that's what they mean? As you pointed out in RP
docstring, there is not an is-a relationship there.
The thing is, we need them to be equal for compareTo() (because we can't have
token keys nor token keys, otherwise that would mess up our ranges). Then
for the equals, the motivation is summed up by the Comparable documentation:
{noformat}
It is strongly recommended (though not required) that natural orderings be
consistent with equals. This is so because sorted sets (and sorted maps)
without explicit comparators behave strangely when they are used with
elements (or keys) whose natural ordering is inconsistent with equals. In
particular, such a sorted set (or sorted map) violates the general contract for
set (or map), which is defined in terms of the equals method.
{noformat}
And I do fear that we would get something inconsistent at some point.
But I'm not a super fan either, just felt the less evil of the two choices.
I'm happy with suggestion though and I'll work out the other remarks.
Remove assumption that Key to Token is one-to-one
-
Key: CASSANDRA-1034
URL: https://issues.apache.org/jira/browse/CASSANDRA-1034
Project: Cassandra
Issue Type: Bug
Reporter: Stu Hood
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 0.8
Attachments:
0001-Make-range-accept-both-Token-and-DecoratedKey.patch,
0002-LengthPartitioner.patch, 1034_v1.txt
get_range_slices assumes that Tokens do not collide and converts a KeyRange
to an AbstractBounds. For RandomPartitioner, this assumption isn't safe, and
would lead to a very weird heisenberg.
Converting AbstractBounds to use a DecoratedKey would solve this, because the
byte[] key portion of the DecoratedKey can act as a tiebreaker.
Alternatively, we could make DecoratedKey extend Token, and then use
DecoratedKeys in places where collisions are unacceptable.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2261) During Compaction, Corrupt SSTables with rows that cause failures should be identified and blacklisted.
[ https://issues.apache.org/jira/browse/CASSANDRA-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13011375#comment-13011375 ] Jonathan Ellis commented on CASSANDRA-2261: --- Weird, I'm getting patch failures on trunk already. Was the revision done against updated trunk? During Compaction, Corrupt SSTables with rows that cause failures should be identified and blacklisted. --- Key: CASSANDRA-2261 URL: https://issues.apache.org/jira/browse/CASSANDRA-2261 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.6 Reporter: Benjamin Coverston Assignee: Benjamin Coverston Priority: Minor Labels: not_a_pony Fix For: 0.7.5 Attachments: 2261.patch When a compaction of a set of SSTables fails because of corruption it will continue to try to compact that SSTable causing pending compactions to build up. One way to mitigate this problem would be to log the error, then identify the specific SSTable that caused the failure, subsequently blacklisting that SSTable and ensuring that it is no longer included in future compactions. For this we could simply store the problematic SSTable's name in memory. If it's not possible to identify the SSTable that caused the issue, then perhaps blacklisting the (ordered) permutation of SSTables to be compacted together is something that can be done to solve this problem in a more general case, and avoid issues where two (or more) SSTables have trouble compacting a particular row. For this option we would probably want to store the lists of the bad combinations in the system table somewhere s.t. these can survive a node failure (there have been a few cases where I have seen a compaction cause a node failure). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2261) During Compaction, Corrupt SSTables with rows that cause failures should be identified and blacklisted.
[ https://issues.apache.org/jira/browse/CASSANDRA-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13011377#comment-13011377 ] Jonathan Ellis commented on CASSANDRA-2261: --- Oh, I guess this targets 0.7. Are we that sure it won't cause problems? During Compaction, Corrupt SSTables with rows that cause failures should be identified and blacklisted. --- Key: CASSANDRA-2261 URL: https://issues.apache.org/jira/browse/CASSANDRA-2261 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.6 Reporter: Benjamin Coverston Assignee: Benjamin Coverston Priority: Minor Labels: not_a_pony Fix For: 0.7.5 Attachments: 2261.patch When a compaction of a set of SSTables fails because of corruption it will continue to try to compact that SSTable causing pending compactions to build up. One way to mitigate this problem would be to log the error, then identify the specific SSTable that caused the failure, subsequently blacklisting that SSTable and ensuring that it is no longer included in future compactions. For this we could simply store the problematic SSTable's name in memory. If it's not possible to identify the SSTable that caused the issue, then perhaps blacklisting the (ordered) permutation of SSTables to be compacted together is something that can be done to solve this problem in a more general case, and avoid issues where two (or more) SSTables have trouble compacting a particular row. For this option we would probably want to store the lists of the bad combinations in the system table somewhere s.t. these can survive a node failure (there have been a few cases where I have seen a compaction cause a node failure). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-1034) Remove assumption that Key to Token is one-to-one
[ https://issues.apache.org/jira/browse/CASSANDRA-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13011386#comment-13011386 ] Jonathan Ellis commented on CASSANDRA-1034: --- I understand the Comparable docs, but - that's primarily concerned w/ compareTo + equals b/t members of the same class - it's valid to say these are tied for sorting purposes, and yet they are not equal In other words I'm more worried about subtle bugs if we allow the equals, than if we don't. :) The Map example is a good one -- if I set map[token(1)] = foo map[dk(1, 1)] = bar I would expect two map entries, not one. (If you want one, you explicitly use asToken, then there is no ambiguity.) How about if we add an assert to both equals to make sure we don't pass in the other kind of object? Remove assumption that Key to Token is one-to-one - Key: CASSANDRA-1034 URL: https://issues.apache.org/jira/browse/CASSANDRA-1034 Project: Cassandra Issue Type: Bug Reporter: Stu Hood Assignee: Sylvain Lebresne Priority: Minor Fix For: 0.8 Attachments: 0001-Make-range-accept-both-Token-and-DecoratedKey.patch, 0002-LengthPartitioner.patch, 1034_v1.txt get_range_slices assumes that Tokens do not collide and converts a KeyRange to an AbstractBounds. For RandomPartitioner, this assumption isn't safe, and would lead to a very weird heisenberg. Converting AbstractBounds to use a DecoratedKey would solve this, because the byte[] key portion of the DecoratedKey can act as a tiebreaker. Alternatively, we could make DecoratedKey extend Token, and then use DecoratedKeys in places where collisions are unacceptable. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-1034) Remove assumption that Key to Token is one-to-one
[ https://issues.apache.org/jira/browse/CASSANDRA-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13011389#comment-13011389 ] Sylvain Lebresne commented on CASSANDRA-1034: - You're right, I'm convinced, it's probably safer to have equals be a true equals. I'll do the change. Remove assumption that Key to Token is one-to-one - Key: CASSANDRA-1034 URL: https://issues.apache.org/jira/browse/CASSANDRA-1034 Project: Cassandra Issue Type: Bug Reporter: Stu Hood Assignee: Sylvain Lebresne Priority: Minor Fix For: 0.8 Attachments: 0001-Make-range-accept-both-Token-and-DecoratedKey.patch, 0002-LengthPartitioner.patch, 1034_v1.txt get_range_slices assumes that Tokens do not collide and converts a KeyRange to an AbstractBounds. For RandomPartitioner, this assumption isn't safe, and would lead to a very weird heisenberg. Converting AbstractBounds to use a DecoratedKey would solve this, because the byte[] key portion of the DecoratedKey can act as a tiebreaker. Alternatively, we could make DecoratedKey extend Token, and then use DecoratedKeys in places where collisions are unacceptable. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1085540 - in /cassandra/trunk: ./ contrib/ interface/thrift/gen-java/org/apache/cassandra/thrift/ src/java/org/apache/cassandra/utils/
Author: jbellis Date: Fri Mar 25 19:53:03 2011 New Revision: 1085540 URL: http://svn.apache.org/viewvc?rev=1085540view=rev Log: merge from 0.7 Modified: cassandra/trunk/ (props changed) cassandra/trunk/contrib/ (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/NotFoundException.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/SuperColumn.java (props changed) cassandra/trunk/src/java/org/apache/cassandra/utils/ByteBufferUtil.java Propchange: cassandra/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Fri Mar 25 19:53:03 2011 @@ -1,5 +1,5 @@ /cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1081914,1083000 -/cassandra/branches/cassandra-0.7:1026516-1084291,1085372 +/cassandra/branches/cassandra-0.7:1026516-1084291,1085372,1085538 /cassandra/branches/cassandra-0.7.0:1053690-1055654 /cassandra/tags/cassandra-0.7.0-rc3:1051699-1053689 /incubator/cassandra/branches/cassandra-0.3:774578-796573 Propchange: cassandra/trunk/contrib/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Fri Mar 25 19:53:03 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-1084291,1085372 +/cassandra/branches/cassandra-0.7/contrib:1026516-1084291,1085372,1085538 /cassandra/branches/cassandra-0.7.0/contrib:1053690-1055654 /cassandra/tags/cassandra-0.7.0-rc3/contrib:1051699-1053689 /incubator/cassandra/branches/cassandra-0.3/contrib:774578-796573 Propchange: cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Fri Mar 25 19:53:03 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-1084291,1085372 +/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1084291,1085372,1085538 /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 /incubator/cassandra/branches/cassandra-0.3/interface/gen-java/org/apache/cassandra/service/Cassandra.java:774578-796573 Propchange: cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Fri Mar 25 19:53:03 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-1084291,1085372 +/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1026516-1084291,1085372,1085538 /cassandra/branches/cassandra-0.7.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1053690-1055654 /cassandra/tags/cassandra-0.7.0-rc3/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1051699-1053689 /incubator/cassandra/branches/cassandra-0.3/interface/gen-java/org/apache/cassandra/service/column_t.java:774578-792198 Propchange: cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Fri Mar 25 19:53:03 2011 @@ -1,5 +1,5 @@ /cassandra/branches/cassandra-0.6/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java:922689-1052356,1052358-1053452,1053454,1053456-1081914,1083000 -/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java:1026516-1084291,1085372 +/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java:1026516-1084291,1085372,1085538
[jira] [Updated] (CASSANDRA-1263) Push replication factor down to the replication strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-1263: -- Reviewer: jeromatron Push replication factor down to the replication strategy Key: CASSANDRA-1263 URL: https://issues.apache.org/jira/browse/CASSANDRA-1263 Project: Cassandra Issue Type: Task Components: Core Reporter: Jeremy Hanna Assignee: Jon Hermes Priority: Minor Fix For: 0.8 Attachments: 1263-2.txt, 1263-incomplete.txt, 1263.txt Original Estimate: 8h Remaining Estimate: 8h Currently the replication factor is in the keyspace metadata. As we've added the datacenter shard strategy, the replication factor becomes more computed by the replication strategy. It seems reasonable to therefore push the replication factor for the keyspace down to the replication strategy so that it can be handled in one place. This adds on the work being done in CASSANDRA-1066 since that ticket will make the replication strategy a member variable of keyspace metadata instead of just a quasi singleton giving the replication strategy state for each keyspace. That makes it able to have the replication factor. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2284) Make changes to the set of memtables and sstables of a cfstore atomic
[ https://issues.apache.org/jira/browse/CASSANDRA-2284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-2284: Attachment: 0001-Make-memtable-and-sstable-switches-atomic-v3.patch Memtable flush is not using CFStore.addSSTable anymore and thus was not going through the incremental backup code. Attached v3 fixes that (that involved moving the incremental backup code into DataTracker). Make changes to the set of memtables and sstables of a cfstore atomic -- Key: CASSANDRA-2284 URL: https://issues.apache.org/jira/browse/CASSANDRA-2284 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 0.8 Attachments: 0001-Make-memtable-and-sstable-switches-atomic-v2.patch, 0001-Make-memtable-and-sstable-switches-atomic-v3.patch, 0001-Make-memtable-and-sstable-switches-atomic.patch, 2284-v2-rebased.txt Original Estimate: 8h Remaining Estimate: 8h Some switches happen in the set of memtables and sstables of a cfstore: * when we switch the memtable, the current memtable is replaced by a new one and add to the memtablesPendingFlush * when a memtable is fully flushed, it is removed from memtablesPendingFlush and the newly created sstable is added to the set of active sstables. * after compaction, compacted memtables are removed from the active sstables and the compacted sstable is added instead Only the last of these operations is atomic. This ticket proposes to makes all of them atomic, using the idea of the View idea hinted by Stu in the comments of CASSANDRA-1954. The main reason for this is to fix CASSANDRA-2105. But I think that another benefit of this is to make reasoning about those operations easier. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2284) Make changes to the set of memtables and sstables of a cfstore atomic
[ https://issues.apache.org/jira/browse/CASSANDRA-2284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13011402#comment-13011402 ] Jonathan Ellis commented on CASSANDRA-2284: --- +1 Make changes to the set of memtables and sstables of a cfstore atomic -- Key: CASSANDRA-2284 URL: https://issues.apache.org/jira/browse/CASSANDRA-2284 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 0.8 Attachments: 0001-Make-memtable-and-sstable-switches-atomic-v2.patch, 0001-Make-memtable-and-sstable-switches-atomic-v3.patch, 0001-Make-memtable-and-sstable-switches-atomic.patch, 2284-v2-rebased.txt Original Estimate: 8h Remaining Estimate: 8h Some switches happen in the set of memtables and sstables of a cfstore: * when we switch the memtable, the current memtable is replaced by a new one and add to the memtablesPendingFlush * when a memtable is fully flushed, it is removed from memtablesPendingFlush and the newly created sstable is added to the set of active sstables. * after compaction, compacted memtables are removed from the active sstables and the compacted sstable is added instead Only the last of these operations is atomic. This ticket proposes to makes all of them atomic, using the idea of the View idea hinted by Stu in the comments of CASSANDRA-1954. The main reason for this is to fix CASSANDRA-2105. But I think that another benefit of this is to make reasoning about those operations easier. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[Cassandra Wiki] Update of ArchitectureInternals by JonHermes
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The ArchitectureInternals page has been changed by JonHermes. http://wiki.apache.org/cassandra/ArchitectureInternals?action=diffrev1=20rev2=21 -- * !StorageService is kind of the internal counterpart to !CassandraDaemon. It handles turning raw gossip into the right internal state. * !AbstractReplicationStrategy controls what nodes get secondary, tertiary, etc. replicas of each key range. Primary replica is always determined by the token ring (in !TokenMetadata) but you can do a lot of variation with the others. !RackUnaware just puts replicas on the next N-1 nodes in the ring. !RackAware puts the first non-primary replica in the next node in the ring in ANOTHER data center than the primary; then the remaining replicas in the same as the primary. * !MessagingService handles connection pooling and running internal commands on the appropriate stage (basically, a threaded executorservice). Stages are set up in !StageManager; currently there are read, write, and stream stages. (Streaming is for when one node copies large sections of its SSTables to another, for bootstrap or relocation on the ring.) The internal commands are defined in !StorageService; look for `registerVerbHandlers`. + * Configuration for the node (administrative stuff, such as which directories to store data in, as well as global configuration, such as which global partitioner to use) is held by !DatabaseDescriptor. Per-KS, per-CF, and per-Column metadata are all stored as migrations across the database and can be updated by calls to system_update/add_* thrift calls, or can be changed locally and temporarily at runtime. See ConfigurationNotes. = Write path = * !StorageProxy gets the nodes responsible for replicas of the keys from the !ReplicationStrategy, then sends !RowMutation messages to them.
[Cassandra Wiki] Update of ConfigurationNotes by JonHermes
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Cassandra Wiki for
change notification.
The ConfigurationNotes page has been changed by JonHermes.
http://wiki.apache.org/cassandra/ConfigurationNotes
--
New page:
Per-node options are loaded from yaml and held in !DatabaseDescriptor.
Per-KS, per-CF, and per-Column options are loaded from the !MigrationsTable at
startup and are encapsulated with KSMetaData, CFMetaData, and ColumnDefinition
objects, which are held by !DatabaseDescriptor as well as !Tables and
!ColumnFamilyStores respectively. When a migration arrives, it writes to the
!MigrationsTable, then propogates the changes out to the KS/CFMD objects in the
system.
Configuration can be changed at runtime without a restart (excluding the ones
that change on-disk format (which cannot be changed without clearing the
cluster) and ones that change routing). For per-node options, poke
!StorageService via JMX (which in turn pokes !DatabaseDescriptor). For per-KS
options, poke the appropriate !Table. For per-CF and per-Column options, poke
the appropriate !ColumnFamilyStore. These ephemeral changes are stronger than
migrations (they stay set regardless of new config coming in), but do not
persist between reboots.
How to add a new CF option post-1906:
* update cassandra.thrift and src/avro/internodo.genavro to add the new option
* ant gen-thrift-java, ant avro-generate
* set a static final T DEFAULT_ for it if there should be one.
* set the default in init()
* define CFMD foo(T prop) { foo = prop; return this } for the builder
* define T getFoo() {return foo;} since all optional params are private
* update deflate() and inflate() to handle the new option -CfDef and CfDef-
* update equals(), hashcode(), and tostring() to build with the new prop
* update applyImplicitDefaults()
* update convertTo{Thrift/Avro}()
* update apply()... this is the important method.
Done. Then, whenever you need the option in code, use
DD.getCFMD(ksname,cfname).getFoo();
[jira] [Created] (CASSANDRA-2388) ColumnFamilyRecordReader fails for a given split because a host is down, even if records could reasonably be read from other replica.
ColumnFamilyRecordReader fails for a given split because a host is down, even if records could reasonably be read from other replica. - Key: CASSANDRA-2388 URL: https://issues.apache.org/jira/browse/CASSANDRA-2388 Project: Cassandra Issue Type: Bug Components: Hadoop Reporter: Eldon Stegall Attachments: 0001_If_Host_Down_Try_Read_Split_On_Other_Endpoint.patch ColumnFamilyRecordReader only tries the first location for a given split. We should try multiple locations for a given split. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2388) ColumnFamilyRecordReader fails for a given split because a host is down, even if records could reasonably be read from other replica.
[ https://issues.apache.org/jira/browse/CASSANDRA-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eldon Stegall updated CASSANDRA-2388: - Attachment: 0001_If_Host_Down_Try_Read_Split_On_Other_Endpoint.patch ColumnFamilyRecordReader fails for a given split because a host is down, even if records could reasonably be read from other replica. - Key: CASSANDRA-2388 URL: https://issues.apache.org/jira/browse/CASSANDRA-2388 Project: Cassandra Issue Type: Bug Components: Hadoop Reporter: Eldon Stegall Attachments: 0001_If_Host_Down_Try_Read_Split_On_Other_Endpoint.patch ColumnFamilyRecordReader only tries the first location for a given split. We should try multiple locations for a given split. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[Cassandra Wiki] Update of ConfigurationNotes by JonHermes
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Cassandra Wiki for
change notification.
The ConfigurationNotes page has been changed by JonHermes.
http://wiki.apache.org/cassandra/ConfigurationNotes?action=diffrev1=1rev2=2
--
+ ==Basics==
+
Per-node options are loaded from yaml and held in !DatabaseDescriptor.
Per-KS, per-CF, and per-Column options are loaded from the !MigrationsTable
at startup and are encapsulated with KSMetaData, CFMetaData, and
ColumnDefinition objects, which are held by !DatabaseDescriptor as well as
!Tables and !ColumnFamilyStores respectively. When a migration arrives, it
writes to the !MigrationsTable, then propogates the changes out to the KS/CFMD
objects in the system.
Configuration can be changed at runtime without a restart (excluding the ones
that change on-disk format (which cannot be changed without clearing the
cluster) and ones that change routing). For per-node options, poke
!StorageService via JMX (which in turn pokes !DatabaseDescriptor). For per-KS
options, poke the appropriate !Table. For per-CF and per-Column options, poke
the appropriate !ColumnFamilyStore. These ephemeral changes are stronger than
migrations (they stay set regardless of new config coming in), but do not
persist between reboots.
- How to add a new CF option post-1906:
+ ==How to add a new CF option post-1906:==
+
- * update cassandra.thrift and src/avro/internodo.genavro to add the new option
+ * {{{ update cassandra.thrift and src/avro/internodo.genavro to add the new
option }}}
- * ant gen-thrift-java, ant avro-generate
+ * {{{ ant gen-thrift-java, ant avro-generate }}}
- * set a static final T DEFAULT_ for it if there should be one.
+ * {{{ set a static final T DEFAULT_ for it if there should be one. }}}
- * set the default in init()
+ * {{{ set the default in init() }}}
- * define CFMD foo(T prop) { foo = prop; return this } for the builder
+ * {{{ define CFMD foo(T prop) { foo = prop; return this } for the builder }}}
- * define T getFoo() {return foo;} since all optional params are private
+ * {{{ define T getFoo() {return foo;} since all optional params are private
}}}
- * update deflate() and inflate() to handle the new option -CfDef and CfDef-
+ * {{{ update deflate() and inflate() to handle the new option -CfDef and
CfDef- }}}
- * update equals(), hashcode(), and tostring() to build with the new prop
+ * {{{ update equals(), hashcode(), and tostring() to build with the new prop
}}}
- * update applyImplicitDefaults()
+ * {{{ update applyImplicitDefaults() }}}
- * update convertTo{Thrift/Avro}()
+ * {{{ update convertTo{Thrift/Avro}() }}}
- * update apply()... this is the important method.
+ * {{{ update apply()... this is the important method. }}}
Done. Then, whenever you need the option in code, use
DD.getCFMD(ksname,cfname).getFoo();
[Cassandra Wiki] Update of ConfigurationNotes by JonHermes
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Cassandra Wiki for
change notification.
The ConfigurationNotes page has been changed by JonHermes.
http://wiki.apache.org/cassandra/ConfigurationNotes?action=diffrev1=2rev2=3
--
==How to add a new CF option post-1906:==
- * {{{ update cassandra.thrift and src/avro/internodo.genavro to add the new
option }}}
+ * update cassandra.thrift and src/avro/internodo.genavro to add the new option
- * {{{ ant gen-thrift-java, ant avro-generate }}}
+ * ant gen-thrift-java, ant avro-generate
- * {{{ set a static final T DEFAULT_ for it if there should be one. }}}
+ * set a static final T DEFAULT_ for it if there should be one
- * {{{ set the default in init() }}}
+ * set the default in init()
- * {{{ define CFMD foo(T prop) { foo = prop; return this } for the builder }}}
+ * define CFMD foo(T prop) { foo = prop; return this } for the builder
- * {{{ define T getFoo() {return foo;} since all optional params are private
}}}
+ * define T getFoo() {return foo;} since all optional params are private
- * {{{ update deflate() and inflate() to handle the new option -CfDef and
CfDef- }}}
+ * update deflate() and inflate() to handle the new option -CfDef and CfDef-
- * {{{ update equals(), hashcode(), and tostring() to build with the new prop
}}}
+ * update equals(), hashcode(), and tostring() to build with the new prop
- * {{{ update applyImplicitDefaults() }}}
+ * update applyImplicitDefaults()
- * {{{ update convertTo{Thrift/Avro}() }}}
+ * update convertTo{Thrift/Avro}()
- * {{{ update apply()... this is the important method. }}}
+ * update apply()... this is the important method.
Done. Then, whenever you need the option in code, use
DD.getCFMD(ksname,cfname).getFoo();
[Cassandra Wiki] Update of ConfigurationNotes by JonHermes
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Cassandra Wiki for
change notification.
The ConfigurationNotes page has been changed by JonHermes.
http://wiki.apache.org/cassandra/ConfigurationNotes?action=diffrev1=3rev2=4
--
==How to add a new CF option post-1906:==
* update cassandra.thrift and src/avro/internodo.genavro to add the new option
+
* ant gen-thrift-java, ant avro-generate
+
* set a static final T DEFAULT_ for it if there should be one
+
* set the default in init()
+
* define CFMD foo(T prop) { foo = prop; return this } for the builder
+
* define T getFoo() {return foo;} since all optional params are private
+
- * update deflate() and inflate() to handle the new option -CfDef and CfDef-
+ * update deflate() and inflate() to handle the new option -!CfDef and
!CfDef-
+
* update equals(), hashcode(), and tostring() to build with the new prop
+
* update applyImplicitDefaults()
+
* update convertTo{Thrift/Avro}()
+
* update apply()... this is the important method.
Done. Then, whenever you need the option in code, use
DD.getCFMD(ksname,cfname).getFoo();
[Cassandra Wiki] Update of ConfigurationNotes by JonHermes
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The ConfigurationNotes page has been changed by JonHermes. http://wiki.apache.org/cassandra/ConfigurationNotes?action=diffrev1=5rev2=6 -- Per-node options are loaded from yaml and held in !DatabaseDescriptor. - Per-KS, per-CF, and per-Column options are loaded from the !MigrationsTable at startup and are encapsulated with KSMetaData, CFMetaData, and ColumnDefinition objects, which are held by !DatabaseDescriptor as well as !Tables and !ColumnFamilyStores respectively. When a migration arrives, it writes to the !MigrationsTable, then propogates the changes out to the KS/CFMD objects in the system. + Per-KS, per-CF, and per-Column options are loaded from the !MigrationsTable at startup and are encapsulated with KSMetaData, CFMetaData, and !ColumnDefinition objects, which are held by !DatabaseDescriptor as well as !Tables and !ColumnFamilyStores respectively. When a migration arrives, it writes to the !MigrationsTable, then propogates the changes out to the KS/CFMD objects in the system. Configuration can be changed at runtime without a restart (excluding the ones that change on-disk format (which cannot be changed without clearing the cluster) and ones that change routing). For per-node options, poke !StorageService via JMX (which in turn pokes !DatabaseDescriptor). For per-KS options, poke the appropriate !Table. For per-CF and per-Column options, poke the appropriate !ColumnFamilyStore. These ephemeral changes are stronger than migrations (they stay set regardless of new config coming in), but do not persist between reboots.
[Cassandra Wiki] Update of ConfigurationNotes by JonHermes
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The ConfigurationNotes page has been changed by JonHermes. http://wiki.apache.org/cassandra/ConfigurationNotes?action=diffrev1=6rev2=7 -- == How to add a new CF option post-1906 == - * update cassandra.thrift and src/avro/internodo.genavro to add the new option + * update cassandra.thrift and src/avro/internodo.genavro to add the new option '''AND UPDATE THE THRIFT API VERSION''' * ant gen-thrift-java, ant avro-generate
[jira] [Updated] (CASSANDRA-2311) type validated row keys
[
https://issues.apache.org/jira/browse/CASSANDRA-2311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Hermes updated CASSANDRA-2311:
--
Attachment: 2311.txt
ThriftValidation.validateKeyInColumnFamily(key, ksname, cfname) is the only
tricky part to this patch. I have to first validate the key is legit and the
column family is legit before I can scan the cf for the keyValidator to use to
validate the key.
Past that, it's just standard adding an option to CFMD and the required 10k of
code that comes with it.
In related news, check out http://wiki.apache.org/cassandra/ConfigurationNotes
for standard adding an option to CFMD notes.
type validated row keys
---
Key: CASSANDRA-2311
URL: https://issues.apache.org/jira/browse/CASSANDRA-2311
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Eric Evans
Assignee: Jon Hermes
Labels: cql
Fix For: 0.8
Attachments: 2311.txt
The idea here is to allow the assignment of a column-family-wide key type
used to perform validation, (similar to how default_validation_class does for
column values).
This should be as straightforward as extending the column family schema to
include the new attribute, and updating {{ThriftValidation.validateKey}} to
validate the key ({{AbstractType.validate}}).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2389) Send writes to stable replicas when replicate-on-write is disabled during bootstrap
Send writes to stable replicas when replicate-on-write is disabled during bootstrap --- Key: CASSANDRA-2389 URL: https://issues.apache.org/jira/browse/CASSANDRA-2389 Project: Cassandra Issue Type: Bug Reporter: Stu Hood During bootstrap with replicate-on-write disabled, our previous approach of widening the replica set via TokenMetadata.getWriteEndpoints is not the correct approach. Instead, since a write is not immediately bound for all replicas, it needs to be sent to a replica that isn't joining or leaving the replica set due to bootstrap. Example: with rf=3, 4 nodes are active in a particular replica set: 1 is joining the set, 1 is leaving the set, and 2 are stable in the set (not affected by the bootstrap). The 2 stable nodes are the ones to which it is safe to send un-replicated writes during the bootstrap. Note that running without replicate-on-write enabled is _never_ recommended, but while the setting exists, we should do the right thing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2388) ColumnFamilyRecordReader fails for a given split because a host is down, even if records could reasonably be read from other replica.
[ https://issues.apache.org/jira/browse/CASSANDRA-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13011464#comment-13011464 ] Brandon Williams commented on CASSANDRA-2388: - I'm not sure special casing NoRouteToHostException to be blacklisted is the best thing to do. I don't think connections are being setup so often that maintaining a blacklist for any reason is needed. ColumnFamilyRecordReader fails for a given split because a host is down, even if records could reasonably be read from other replica. - Key: CASSANDRA-2388 URL: https://issues.apache.org/jira/browse/CASSANDRA-2388 Project: Cassandra Issue Type: Bug Components: Hadoop Reporter: Eldon Stegall Attachments: 0001_If_Host_Down_Try_Read_Split_On_Other_Endpoint.patch ColumnFamilyRecordReader only tries the first location for a given split. We should try multiple locations for a given split. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2389) Send writes to stable replicas when replicate-on-write is disabled during bootstrap
[ https://issues.apache.org/jira/browse/CASSANDRA-2389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13011470#comment-13011470 ] Stu Hood commented on CASSANDRA-2389: - Nick pointed out that the set of endpoints that should be written to is the intersection of the post-bootstrap replica set with the pre-bootstrap replica set. I'm time crunched to implement this for our branch, but the full solution might involve calculating and maintaining a post-move/bootstrap clone of the ring. Send writes to stable replicas when replicate-on-write is disabled during bootstrap --- Key: CASSANDRA-2389 URL: https://issues.apache.org/jira/browse/CASSANDRA-2389 Project: Cassandra Issue Type: Bug Reporter: Stu Hood During bootstrap with replicate-on-write disabled, our previous approach of widening the replica set via TokenMetadata.getWriteEndpoints is not the correct approach. Instead, since a write is not immediately bound for all replicas, it needs to be sent to a replica that isn't joining or leaving the replica set due to bootstrap. Example: with rf=3, 4 nodes are active in a particular replica set: 1 is joining the set, 1 is leaving the set, and 2 are stable in the set (not affected by the bootstrap). The 2 stable nodes are the ones to which it is safe to send un-replicated writes during the bootstrap. Note that running without replicate-on-write enabled is _never_ recommended, but while the setting exists, we should do the right thing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[Cassandra Wiki] Update of FAQ by PeterSchuller
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The FAQ page has been changed by PeterSchuller. The comment on this change is: Add How does Cassandra decide which nodes have what data?. http://wiki.apache.org/cassandra/FAQ?action=diffrev1=106rev2=107 -- * [[#cleaning_compacted_tables|I compacted, so why did space used not decrease?]] * [[#mmap|Why does top report that Cassandra is using a lot more memory than the Java heap max?]] * [[#jna|I'm getting java.io.IOException: Cannot run program ln when trying to snapshot or update a keyspace]] + * [[#replicaplacement|How does Cassandra decide which nodes have what data?]] Anchor(cant_listen_on_ip_any) == Why can't I make Cassandra listen on 0.0.0.0 (all my addresses)? == @@ -402, +403 @@ == I'm getting java.io.IOException: Cannot run program ln when trying to snapshot or update a keyspace == Updating a keyspace first takes a snapshot. This involves creating hardlinks to the existing SSTables, but Java has no native way to create hard links, so it must fork ln. When forking, there must be as much memory free as the parent process, even though the child isn't going to use it all. Because Java is a large process, this is problematic. The solution is to install [[http://jna.java.net/|Java Native Access]] so it can create the hard links itself. + Anchor(replicaplacement) + + == How does Cassandra decide which nodes have what data? == + + The set of nodes (a single node, or several) responsible for any given piece of data is determined by: + + * The row key (data is partitioned on row key) + * The replication factor (decides emhow many/em nodes are in the replica set for a given row) + * The replication strategy (decides emwhich/em nodes are part of said replica set) + + In the case of the SimpleStrategy, replicas are placed on succeeding nodes in the ring. The first node is determined by the partitioner and the row key, and the remainder are placed on succeeding node. In the case of NetworkTopologyStrategy placement is affected by data-center and wrack awareness, and the placement will depend on how nodes in different racks or data centers are placed in the ring. + + It is important to understand that Cassandra emdoes not/em alter the replica set for a given row key based on changing characteristics like current load, which nodes are up or down, or which node your client happens to talk to. +
[Cassandra Wiki] Update of FAQ by PeterSchuller
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The FAQ page has been changed by PeterSchuller. The comment on this change is: fix markup. http://wiki.apache.org/cassandra/FAQ?action=diffrev1=107rev2=108 -- The set of nodes (a single node, or several) responsible for any given piece of data is determined by: * The row key (data is partitioned on row key) - * The replication factor (decides emhow many/em nodes are in the replica set for a given row) + * The replication factor (decides ''how many'' nodes are in the replica set for a given row) - * The replication strategy (decides emwhich/em nodes are part of said replica set) + * The replication strategy (decides ''which'' nodes are part of said replica set) In the case of the SimpleStrategy, replicas are placed on succeeding nodes in the ring. The first node is determined by the partitioner and the row key, and the remainder are placed on succeeding node. In the case of NetworkTopologyStrategy placement is affected by data-center and wrack awareness, and the placement will depend on how nodes in different racks or data centers are placed in the ring. - It is important to understand that Cassandra emdoes not/em alter the replica set for a given row key based on changing characteristics like current load, which nodes are up or down, or which node your client happens to talk to. + It is important to understand that Cassandra ''does not'' alter the replica set for a given row key based on changing characteristics like current load, which nodes are up or down, or which node your client happens to talk to.
[Cassandra Wiki] Update of ArticlesAndPresentations by BrandonWilliams
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The ArticlesAndPresentations page has been changed by BrandonWilliams. http://wiki.apache.org/cassandra/ArticlesAndPresentations?action=diffrev1=116rev2=117 -- = Other Articles = * [[http://ria101.wordpress.com/2011/02/08/cassandra-the-importance-of-system-clocks-avoiding-oom-and-how-to-escape-oom-meltdown/|Cassandra: the importance of system clocks, avoiding OOM and how to escape (unnecessary) OOM meltdown]], February 2011 * [[http://blog.adku.com/2011/02/hbase-vs-cassandra.html|Why Adku chose Cassandra over HBase]] + * [[http://blog.insidesystems.net/basic-time-series-with-cassandra]]Modelling basic time series data with Cassandra]] * [[http://cloudeventprocessing.com/2011/01/27/cassandras-data-model|Modeling market data with Cassandra]] * [[http://www.coreyhulen.org/?p=235|Installing]], [[http://www.coreyhulen.org/?p=277|monitoring]], and [[http://www.coreyhulen.org/?p=326|performance testing]] Cassandra on EC2 * [[http://blog.octo.com/en/nosql-lets-play-with-cassandra-part-13|Cassandra Overview]], [[http://blog.octo.com/en/nosql-lets-play-with-cassandra-part-23|Setup]] and [[http://blog.octo.com/en/nosql-lets-play-with-cassandra-part-13|Java Thrift Client]] : [[http://blog.octo.com/en/nosql-lets-play-with-cassandra-part-13/|Part1]], [[http://blog.octo.com/en/nosql-lets-play-with-cassandra-part-23/|Part2]] and [[http://blog.octo.com/en/nosql-lets-play-with-cassandra-part-33/|Part3]], June 2010
[Cassandra Wiki] Trivial Update of ArticlesAndPresentations by BrandonWilliams
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The ArticlesAndPresentations page has been changed by BrandonWilliams. http://wiki.apache.org/cassandra/ArticlesAndPresentations?action=diffrev1=117rev2=118 -- = Other Articles = * [[http://ria101.wordpress.com/2011/02/08/cassandra-the-importance-of-system-clocks-avoiding-oom-and-how-to-escape-oom-meltdown/|Cassandra: the importance of system clocks, avoiding OOM and how to escape (unnecessary) OOM meltdown]], February 2011 * [[http://blog.adku.com/2011/02/hbase-vs-cassandra.html|Why Adku chose Cassandra over HBase]] - * [[http://blog.insidesystems.net/basic-time-series-with-cassandra]]Modelling basic time series data with Cassandra]] + * [[http://blog.insidesystems.net/basic-time-series-with-cassandra]]|Modelling basic time series data with Cassandra]] * [[http://cloudeventprocessing.com/2011/01/27/cassandras-data-model|Modeling market data with Cassandra]] * [[http://www.coreyhulen.org/?p=235|Installing]], [[http://www.coreyhulen.org/?p=277|monitoring]], and [[http://www.coreyhulen.org/?p=326|performance testing]] Cassandra on EC2 * [[http://blog.octo.com/en/nosql-lets-play-with-cassandra-part-13|Cassandra Overview]], [[http://blog.octo.com/en/nosql-lets-play-with-cassandra-part-23|Setup]] and [[http://blog.octo.com/en/nosql-lets-play-with-cassandra-part-13|Java Thrift Client]] : [[http://blog.octo.com/en/nosql-lets-play-with-cassandra-part-13/|Part1]], [[http://blog.octo.com/en/nosql-lets-play-with-cassandra-part-23/|Part2]] and [[http://blog.octo.com/en/nosql-lets-play-with-cassandra-part-33/|Part3]], June 2010
[Cassandra Wiki] Trivial Update of ArticlesAndPresentations by BrandonWilliams
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The ArticlesAndPresentations page has been changed by BrandonWilliams. http://wiki.apache.org/cassandra/ArticlesAndPresentations?action=diffrev1=118rev2=119 -- = Other Articles = * [[http://ria101.wordpress.com/2011/02/08/cassandra-the-importance-of-system-clocks-avoiding-oom-and-how-to-escape-oom-meltdown/|Cassandra: the importance of system clocks, avoiding OOM and how to escape (unnecessary) OOM meltdown]], February 2011 * [[http://blog.adku.com/2011/02/hbase-vs-cassandra.html|Why Adku chose Cassandra over HBase]] - * [[http://blog.insidesystems.net/basic-time-series-with-cassandra]]|Modelling basic time series data with Cassandra]] + * [[http://blog.insidesystems.net/basic-time-series-with-cassandra|Modelling basic time series data with Cassandra]] * [[http://cloudeventprocessing.com/2011/01/27/cassandras-data-model|Modeling market data with Cassandra]] * [[http://www.coreyhulen.org/?p=235|Installing]], [[http://www.coreyhulen.org/?p=277|monitoring]], and [[http://www.coreyhulen.org/?p=326|performance testing]] Cassandra on EC2 * [[http://blog.octo.com/en/nosql-lets-play-with-cassandra-part-13|Cassandra Overview]], [[http://blog.octo.com/en/nosql-lets-play-with-cassandra-part-23|Setup]] and [[http://blog.octo.com/en/nosql-lets-play-with-cassandra-part-13|Java Thrift Client]] : [[http://blog.octo.com/en/nosql-lets-play-with-cassandra-part-13/|Part1]], [[http://blog.octo.com/en/nosql-lets-play-with-cassandra-part-23/|Part2]] and [[http://blog.octo.com/en/nosql-lets-play-with-cassandra-part-33/|Part3]], June 2010
[jira] [Updated] (CASSANDRA-2388) ColumnFamilyRecordReader fails for a given split because a host is down, even if records could reasonably be read from other replica.
[ https://issues.apache.org/jira/browse/CASSANDRA-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eldon Stegall updated CASSANDRA-2388: - Attachment: 0002_On_TException_try_next_split.patch ColumnFamilyRecordReader fails for a given split because a host is down, even if records could reasonably be read from other replica. - Key: CASSANDRA-2388 URL: https://issues.apache.org/jira/browse/CASSANDRA-2388 Project: Cassandra Issue Type: Bug Components: Hadoop Reporter: Eldon Stegall Attachments: 0001_If_Host_Down_Try_Read_Split_On_Other_Endpoint.patch, 0002_On_TException_try_next_split.patch ColumnFamilyRecordReader only tries the first location for a given split. We should try multiple locations for a given split. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2388) ColumnFamilyRecordReader fails for a given split because a host is down, even if records could reasonably be read from other replica.
[ https://issues.apache.org/jira/browse/CASSANDRA-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eldon Stegall updated CASSANDRA-2388: - Attachment: (was: 0001_If_Host_Down_Try_Read_Split_On_Other_Endpoint.patch) ColumnFamilyRecordReader fails for a given split because a host is down, even if records could reasonably be read from other replica. - Key: CASSANDRA-2388 URL: https://issues.apache.org/jira/browse/CASSANDRA-2388 Project: Cassandra Issue Type: Bug Components: Hadoop Reporter: Eldon Stegall Attachments: 0002_On_TException_try_next_split.patch ColumnFamilyRecordReader only tries the first location for a given split. We should try multiple locations for a given split. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
