[jira] [Commented] (CASSANDRA-2753) Capture the max client timestamp for an SSTable
[
https://issues.apache.org/jira/browse/CASSANDRA-2753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056362#comment-13056362
]
Alan Liang commented on CASSANDRA-2753:
---
bq. No support for supercolumns?
Wow. Good catch. I've added test tests for this as well.
bq. it would be more clear if observeColumnsInSSTable took a CFMetaData object
instead of a CF, to get a serializer from.
I've added a helper method CFMetaData.getColumnSerializer() to do this.
bq. nit: SSTMC.setMaxTimestamp would be more accurately named updateMaxTimestamp
Makes sense.
bq. IMO SSTM deserialize versioning logic would be clearer if it were all in
SSTMSerializer instead of split between that and openFromDescriptor.
Makes sense.
bq. Suggest adding a comment that SSTableWriter.append(AbstractCompactedRow
row) deliberately avoids calling updateMaxTimestamp b/c otherwise we'd have to
deserialize EchoedRow.
Sounds good.
bq. where is the max-timestamp-of-compacted-sstables logic? I didn't notice it.
I put this in ColumnFamilyStore.createCompactionWriter():
{code}
public SSTableWriter createCompactionWriter(long estimatedRows, String
location, CollectionSSTableReader sstables) throws IOException
{
ReplayPosition rp = ReplayPosition.getReplayPosition(sstables);
SSTableMetadata.Collector sstableMetadataCollector =
SSTableMetadata.createCollector().replayPosition(rp);
// get the max timestamp of the precompacted sstables
for (SSTableReader sstable : sstables)
sstableMetadataCollector.updateMaxTimestamp(sstable.getMaxTimestamp());
return new SSTableWriter(getTempSSTablePath(location), estimatedRows,
metadata, partitioner, sstableMetadataCollector);
}
{code}
bq. nit: renaming SSTableWriter.writeMetadata feels gratuitous
I renamed it back to writeMetadata.
bq. nit: prefer initializing fields that don't need constructor parameters, at
declaration time (looking at RowIndexer.sstMC)
Makes sense.
Capture the max client timestamp for an SSTable
---
Key: CASSANDRA-2753
URL: https://issues.apache.org/jira/browse/CASSANDRA-2753
Project: Cassandra
Issue Type: New Feature
Components: Core
Reporter: Alan Liang
Assignee: Alan Liang
Priority: Minor
Attachments:
0001-capture-max-timestamp-and-created-SSTableMetadata-to.patch,
0003-capture-max-timestamp-for-sstable-and-introduced-SST.patch
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2753) Capture the max client timestamp for an SSTable
[ https://issues.apache.org/jira/browse/CASSANDRA-2753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Liang updated CASSANDRA-2753: -- Attachment: 0001-capture-max-timestamp-and-created-SSTableMetadata-to-V2.patch V2 patch based on jbellis' comments Capture the max client timestamp for an SSTable --- Key: CASSANDRA-2753 URL: https://issues.apache.org/jira/browse/CASSANDRA-2753 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Alan Liang Assignee: Alan Liang Priority: Minor Attachments: 0001-capture-max-timestamp-and-created-SSTableMetadata-to-V2.patch, 0001-capture-max-timestamp-and-created-SSTableMetadata-to.patch, 0003-capture-max-timestamp-for-sstable-and-introduced-SST.patch -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1140470 - in /cassandra/branches/cassandra-0.8: CHANGES.txt src/java/org/apache/cassandra/service/RangeSliceResponseResolver.java src/java/org/apache/cassandra/service/RowRepairResolver.j
Author: slebresne
Date: Tue Jun 28 07:53:08 2011
New Revision: 1140470
URL: http://svn.apache.org/viewvc?rev=1140470view=rev
Log:
Fix potential NPE in range slice read repair
patch by slebresne; reviewed by jbellis for CASSANDRA-2823
Modified:
cassandra/branches/cassandra-0.8/CHANGES.txt
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/RangeSliceResponseResolver.java
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/RowRepairResolver.java
Modified: cassandra/branches/cassandra-0.8/CHANGES.txt
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/CHANGES.txt?rev=1140470r1=1140469r2=1140470view=diff
==
--- cassandra/branches/cassandra-0.8/CHANGES.txt (original)
+++ cassandra/branches/cassandra-0.8/CHANGES.txt Tue Jun 28 07:53:08 2011
@@ -7,6 +7,8 @@
* add ability to return endpoints to nodetool (CASSANDRA-2776)
* Add support for multiple (comma-delimited) coordinator addresses
to ColumnFamilyInputFormat (CASSANDRA-2807)
+ * fix potential NPE while scheduling read repair for range slice
+ (CASSANDRA-2823)
0.8.1
Modified:
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/RangeSliceResponseResolver.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/RangeSliceResponseResolver.java?rev=1140470r1=1140469r2=1140470view=diff
==
---
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/RangeSliceResponseResolver.java
(original)
+++
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/RangeSliceResponseResolver.java
Tue Jun 28 07:53:08 2011
@@ -117,7 +117,9 @@ public class RangeSliceResponseResolver
}
}
}
-RowRepairResolver.maybeScheduleRepairs(resolved, table, key,
versions, versionSources);
+// resolved can be null even if versions doesn't have all
nulls because of the call to removeDeleted in resolveSuperSet
+if (resolved != null)
+RowRepairResolver.maybeScheduleRepairs(resolved, table,
key, versions, versionSources);
versions.clear();
versionSources.clear();
return new Row(key, resolved);
Modified:
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/RowRepairResolver.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/RowRepairResolver.java?rev=1140470r1=1140469r2=1140470view=diff
==
---
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/RowRepairResolver.java
(original)
+++
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/RowRepairResolver.java
Tue Jun 28 07:53:08 2011
@@ -80,7 +80,9 @@ public class RowRepairResolver extends A
resolved = resolveSuperset(versions);
if (logger.isDebugEnabled())
logger.debug(versions merged);
-maybeScheduleRepairs(resolved, table, key, versions, endpoints);
+// resolved can be null even if versions doesn't have all nulls
because of the call to removeDeleted in resolveSuperSet
+if (resolved != null)
+maybeScheduleRepairs(resolved, table, key, versions,
endpoints);
}
else
{
[jira] [Resolved] (CASSANDRA-2823) NPE during range slices with rowrepairs
[
https://issues.apache.org/jira/browse/CASSANDRA-2823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne resolved CASSANDRA-2823.
-
Resolution: Fixed
Fix Version/s: 0.8.2
Reviewer: jbellis
Committed, thanks
NPE during range slices with rowrepairs
---
Key: CASSANDRA-2823
URL: https://issues.apache.org/jira/browse/CASSANDRA-2823
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.8.2
Environment: This is a trunk build with 2521 and 2433
I somewhat doubt that is related however.
Reporter: Terje Marthinussen
Assignee: Sylvain Lebresne
Fix For: 0.8.2
Attachments: 2823.patch
Doing some heavy testing of relatively fast feeding (5000+ mutations/sec) +
repair on all node + range slices.
Then occasionally killing a node here and there and restarting it.
Triggers the following NPE
ERROR [pool-2-thread-3] 2011-06-24 20:56:27,289 Cassandra.java (line 3210)
Internal error processing get_range_slices
java.lang.NullPointerException
at
org.apache.cassandra.service.RowRepairResolver.maybeScheduleRepairs(RowRepairResolver.java:109)
at
org.apache.cassandra.service.RangeSliceResponseResolver$2.getReduced(RangeSliceResponseResolver.java:112)
at
org.apache.cassandra.service.RangeSliceResponseResolver$2.getReduced(RangeSliceResponseResolver.java:83)
at
org.apache.cassandra.utils.MergeIterator$ManyToOne.consume(MergeIterator.java:161)
at
org.apache.cassandra.utils.MergeIterator.computeNext(MergeIterator.java:88)
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140)
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135)
at
org.apache.cassandra.service.RangeSliceResponseResolver.resolve(RangeSliceResponseResolver.java:120)
at
org.apache.cassandra.service.RangeSliceResponseResolver.resolve(RangeSliceResponseResolver.java:43)
Looking at the code in getReduced:
{noformat}
ColumnFamily resolved = versions.size() 1
?
RowRepairResolver.resolveSuperset(versions)
: versions.get(0);
{noformat}
seems like resolved becomes null when this happens and versions.size is
larger than 1.
RowRepairResolver.resolveSuperset() does actually return null if it cannot
resolve anything, so there is definately a case here which can occur and is
not handled.
It may also be an interesting question if it is guaranteed that
versions.add(current.left.cf);
can never return null?
Jonathan suggested on IRC that maybe
{noformat}
ColumnFamily resolved = versions.size() 1
?
RowRepairResolver.resolveSuperset(versions)
: versions.get(0);
if (resolved == null)
return new Row(key, resolved);
{noformat}
could be a fix.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1140472 - in /cassandra/branches/cassandra-0.8: CHANGES.txt src/java/org/apache/cassandra/db/SystemTable.java
Author: slebresne
Date: Tue Jun 28 07:58:56 2011
New Revision: 1140472
URL: http://svn.apache.org/viewvc?rev=1140472view=rev
Log:
Avoids race in SystemTable.getCurrentLocalNodeId
patch by slebresne; reviewed by jbellis for CASSANDRA-2824
Modified:
cassandra/branches/cassandra-0.8/CHANGES.txt
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/SystemTable.java
Modified: cassandra/branches/cassandra-0.8/CHANGES.txt
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/CHANGES.txt?rev=1140472r1=1140471r2=1140472view=diff
==
--- cassandra/branches/cassandra-0.8/CHANGES.txt (original)
+++ cassandra/branches/cassandra-0.8/CHANGES.txt Tue Jun 28 07:58:56 2011
@@ -9,6 +9,7 @@
to ColumnFamilyInputFormat (CASSANDRA-2807)
* fix potential NPE while scheduling read repair for range slice
(CASSANDRA-2823)
+ * Fix race in SystemTable.getCurrentLocalNodeId (CASSANDRA-2824)
0.8.1
Modified:
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/SystemTable.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/SystemTable.java?rev=1140472r1=1140471r2=1140472view=diff
==
---
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/SystemTable.java
(original)
+++
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/SystemTable.java
Tue Jun 28 07:58:56 2011
@@ -380,6 +380,8 @@ public class SystemTable
ColumnFamily cf =
table.getColumnFamilyStore(NODE_ID_CF).getColumnFamily(filter);
if (cf != null)
{
+// Even though gc_grace==0 on System table, we can have a race
where we get back tombstones (see CASSANDRA-2824)
+cf = ColumnFamilyStore.removeDeleted(cf, 0);
assert cf.getColumnCount() = 1;
if (cf.getColumnCount() 0)
id = cf.iterator().next().name();
[jira] [Updated] (CASSANDRA-2653) index scan errors out when zero columns are requested
[
https://issues.apache.org/jira/browse/CASSANDRA-2653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-2653:
Attachment: 2653_v3.patch
index scan errors out when zero columns are requested
-
Key: CASSANDRA-2653
URL: https://issues.apache.org/jira/browse/CASSANDRA-2653
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.7.6, 0.8.0 beta 2
Reporter: Jonathan Ellis
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 0.7.7, 0.8.1
Attachments:
0001-Handle-data-get-returning-null-in-secondary-indexes.patch,
0001-Handle-null-returns-in-data-index-query-v0.7.patch,
0001-Reset-SSTII-in-EchoedRow-constructor.patch, 2653_v2.patch,
2653_v3.patch, v1-0001-CASSANDRA-2653-reproduce-regression.txt
As reported by Tyler Hobbs as an addendum to CASSANDRA-2401,
{noformat}
ERROR 16:13:38,864 Fatal exception in thread Thread[ReadStage:16,5,main]
java.lang.AssertionError: No data found for
SliceQueryFilter(start=java.nio.HeapByteBuffer[pos=10 lim=10 cap=30],
finish=java.nio.HeapByteBuffer[pos=17 lim=17 cap=30], reversed=false,
count=0] in DecoratedKey(81509516161424251288255223397843705139,
6b657931):QueryPath(columnFamilyName='cf', superColumnName='null',
columnName='null') (original filter
SliceQueryFilter(start=java.nio.HeapByteBuffer[pos=10 lim=10 cap=30],
finish=java.nio.HeapByteBuffer[pos=17 lim=17 cap=30], reversed=false,
count=0]) from expression 'cf.626972746864617465 EQ 1'
at
org.apache.cassandra.db.ColumnFamilyStore.scan(ColumnFamilyStore.java:1517)
at
org.apache.cassandra.service.IndexScanVerbHandler.doVerb(IndexScanVerbHandler.java:42)
at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:72)
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)
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2824) assert err on SystemTable.getCurrentLocalNodeId during a cleanup
[ https://issues.apache.org/jira/browse/CASSANDRA-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056384#comment-13056384 ] Hudson commented on CASSANDRA-2824: --- Integrated in Cassandra-0.8 #195 (See [https://builds.apache.org/job/Cassandra-0.8/195/]) Avoids race in SystemTable.getCurrentLocalNodeId patch by slebresne; reviewed by jbellis for CASSANDRA-2824 slebresne : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1140472 Files : * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/SystemTable.java assert err on SystemTable.getCurrentLocalNodeId during a cleanup Key: CASSANDRA-2824 URL: https://issues.apache.org/jira/browse/CASSANDRA-2824 Project: Cassandra Issue Type: Bug Affects Versions: 0.8.0 Reporter: Jackson Chung Assignee: Sylvain Lebresne Priority: Minor Fix For: 0.8.2 Attachments: 2824.patch, 2824_v2.patch when running nodetool cleanup the following happened: $ ./bin/nodetool cleanup --host localhost Exception in thread main java.lang.AssertionError at org.apache.cassandra.db.SystemTable.getCurrentLocalNodeId(SystemTable.java:383) at org.apache.cassandra.utils.NodeId$LocalNodeIdHistory.init(NodeId.java:179) at org.apache.cassandra.utils.NodeId.clinit(NodeId.java:38) at org.apache.cassandra.utils.NodeId$OneShotRenewer.init(NodeId.java:159) at org.apache.cassandra.service.StorageService.forceTableCleanup(StorageService.java:1317) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:93) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:27) at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208) at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:120) at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:262) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1427) at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1265) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1360) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:788) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305) at sun.rmi.transport.Transport$1.run(Transport.java:159) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:155) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649) 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) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2823) NPE during range slices with rowrepairs
[
https://issues.apache.org/jira/browse/CASSANDRA-2823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056383#comment-13056383
]
Hudson commented on CASSANDRA-2823:
---
Integrated in Cassandra-0.8 #195 (See
[https://builds.apache.org/job/Cassandra-0.8/195/])
Fix potential NPE in range slice read repair
patch by slebresne; reviewed by jbellis for CASSANDRA-2823
slebresne :
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1140470
Files :
* /cassandra/branches/cassandra-0.8/CHANGES.txt
*
/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/RowRepairResolver.java
*
/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/RangeSliceResponseResolver.java
NPE during range slices with rowrepairs
---
Key: CASSANDRA-2823
URL: https://issues.apache.org/jira/browse/CASSANDRA-2823
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.8.2
Environment: This is a trunk build with 2521 and 2433
I somewhat doubt that is related however.
Reporter: Terje Marthinussen
Assignee: Sylvain Lebresne
Fix For: 0.8.2
Attachments: 2823.patch
Doing some heavy testing of relatively fast feeding (5000+ mutations/sec) +
repair on all node + range slices.
Then occasionally killing a node here and there and restarting it.
Triggers the following NPE
ERROR [pool-2-thread-3] 2011-06-24 20:56:27,289 Cassandra.java (line 3210)
Internal error processing get_range_slices
java.lang.NullPointerException
at
org.apache.cassandra.service.RowRepairResolver.maybeScheduleRepairs(RowRepairResolver.java:109)
at
org.apache.cassandra.service.RangeSliceResponseResolver$2.getReduced(RangeSliceResponseResolver.java:112)
at
org.apache.cassandra.service.RangeSliceResponseResolver$2.getReduced(RangeSliceResponseResolver.java:83)
at
org.apache.cassandra.utils.MergeIterator$ManyToOne.consume(MergeIterator.java:161)
at
org.apache.cassandra.utils.MergeIterator.computeNext(MergeIterator.java:88)
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140)
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135)
at
org.apache.cassandra.service.RangeSliceResponseResolver.resolve(RangeSliceResponseResolver.java:120)
at
org.apache.cassandra.service.RangeSliceResponseResolver.resolve(RangeSliceResponseResolver.java:43)
Looking at the code in getReduced:
{noformat}
ColumnFamily resolved = versions.size() 1
?
RowRepairResolver.resolveSuperset(versions)
: versions.get(0);
{noformat}
seems like resolved becomes null when this happens and versions.size is
larger than 1.
RowRepairResolver.resolveSuperset() does actually return null if it cannot
resolve anything, so there is definately a case here which can occur and is
not handled.
It may also be an interesting question if it is guaranteed that
versions.add(current.left.cf);
can never return null?
Jonathan suggested on IRC that maybe
{noformat}
ColumnFamily resolved = versions.size() 1
?
RowRepairResolver.resolveSuperset(versions)
: versions.get(0);
if (resolved == null)
return new Row(key, resolved);
{noformat}
could be a fix.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2653) index scan errors out when zero columns are requested
[
https://issues.apache.org/jira/browse/CASSANDRA-2653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056385#comment-13056385
]
Sylvain Lebresne commented on CASSANDRA-2653:
-
bq. doesn't this assert still have the the query to the index and the data is
not atomic problem?
No you're right, I focused on adding back the assert forgetting it wasn't safe
in the first place. Attaching v3 based on v2, but instead of asserting that the
row return contains the primary clause column, it skips the row if it doesn't
contain it. That is, instead of asserting the non-corruption of the index, it
ignores any possible corruption. But more importantly (one could hope we don't
have a bug that corrupt indexes), it will avoid returning incoherent result to
the user in the event of a race between reads and writes.
Trying to prevent the race from happening would require synchronization with
write, which will be much harder and less efficient. And we probably need to
have a fix for that out sooner than later (both the error when zero columns are
requested and the possibly to throw assertion errors wrongly).
In the longer term, I think we should explore the possibility of stopping to
care whether our secondary indexes are coherent at all time and repair them at
read time as this may allow us to get rid of the read-before-write. But it's a
longer term goal at best and work for another ticket.
index scan errors out when zero columns are requested
-
Key: CASSANDRA-2653
URL: https://issues.apache.org/jira/browse/CASSANDRA-2653
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.7.6, 0.8.0 beta 2
Reporter: Jonathan Ellis
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 0.7.7, 0.8.1
Attachments:
0001-Handle-data-get-returning-null-in-secondary-indexes.patch,
0001-Handle-null-returns-in-data-index-query-v0.7.patch,
0001-Reset-SSTII-in-EchoedRow-constructor.patch, 2653_v2.patch,
2653_v3.patch, v1-0001-CASSANDRA-2653-reproduce-regression.txt
As reported by Tyler Hobbs as an addendum to CASSANDRA-2401,
{noformat}
ERROR 16:13:38,864 Fatal exception in thread Thread[ReadStage:16,5,main]
java.lang.AssertionError: No data found for
SliceQueryFilter(start=java.nio.HeapByteBuffer[pos=10 lim=10 cap=30],
finish=java.nio.HeapByteBuffer[pos=17 lim=17 cap=30], reversed=false,
count=0] in DecoratedKey(81509516161424251288255223397843705139,
6b657931):QueryPath(columnFamilyName='cf', superColumnName='null',
columnName='null') (original filter
SliceQueryFilter(start=java.nio.HeapByteBuffer[pos=10 lim=10 cap=30],
finish=java.nio.HeapByteBuffer[pos=17 lim=17 cap=30], reversed=false,
count=0]) from expression 'cf.626972746864617465 EQ 1'
at
org.apache.cassandra.db.ColumnFamilyStore.scan(ColumnFamilyStore.java:1517)
at
org.apache.cassandra.service.IndexScanVerbHandler.doVerb(IndexScanVerbHandler.java:42)
at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:72)
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)
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2834) Avoid repair getting started twice at the same time for the same CF
[ https://issues.apache.org/jira/browse/CASSANDRA-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056399#comment-13056399 ] Sylvain Lebresne commented on CASSANDRA-2834: - bq. It may seem like it is possible to start repair twice at the same time on the same CF? It is possible. Right now the only cases where we abort a repair quickly is if some neighbors are dead. Repairing twice on the same CF is indeed useless and we can try to avoid it. This is however not totally trivial because the two repairs can be started on different nodes so we'll have to synchronize somehow. Rather, it's not hard per se, but this will require some addition to the network protocol and is thus a little longer term that one could hope. Note that this may be made simpler by CASSANDRA-1740 in that it would propose to have a way to abort a repair (which don't have so far). Avoid repair getting started twice at the same time for the same CF --- Key: CASSANDRA-2834 URL: https://issues.apache.org/jira/browse/CASSANDRA-2834 Project: Cassandra Issue Type: Improvement Reporter: Terje Marthinussen It may seem like it is possible to start repair twice at the same time on the same CF? Not 100% verified, but if this is indeed the case, we may want to consider avoiding that including making nodetool repair abort and return and error if repair is attempted on the same CF as one which already have repair running. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2521) Move away from Phantom References for Compaction/Memtable
[
https://issues.apache.org/jira/browse/CASSANDRA-2521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056406#comment-13056406
]
Sylvain Lebresne commented on CASSANDRA-2521:
-
bq. but I guess these may be results of references acquired which are not freed
as the streaming fills up the disk and fails.
Yes, until we have CASSANDRA-2433 (rebased with this), we don't detect failing
streaming and thus never delete the files (until restart). Which btw make me
say that we better have CASSANDRA-2433 if we have this ticket. But that was the
plan anyway.
bq. there are no less but 53 tmp files. A lot of concurrent streams here!
Though it is not related to this ticket, I'll note that CASSANDRA-2816 only
stagger the merkle tree creation, not the streaming. That is, the streaming
will be staggered to some extends, but if the streaming part is much longer
than the merkle tree creation one, you will still have lots of concurrent
stream going on. But -tmp files also includes the compaction that are going on,
and failed repair leaves -tmp file around, which could also help explaining
there large number. In any case, this is not related to the issue at hand :)
{quote}
However I noticed this in the log:
INFO [Thread-185] 2011-06-28 05:01:15,390 StorageService.java (line 2083)
requesting GC to free disk space
I guess we can get rid of that?
{quote}
In some cases (mmap with non-sun jvm at least) we are still relying on the GC
to free space.
Terje, if you can confirm that you didn't saw something utterly wrong with the
last patch (related to that patch, no repair), I'll commit it. I think having
it in trunk quicker will help with having more testing quicker. And given that
we don't want to have bugs in our force unmapping it'll be a good thing. In
particular, could be good to have someone try that on windows.
Move away from Phantom References for Compaction/Memtable
-
Key: CASSANDRA-2521
URL: https://issues.apache.org/jira/browse/CASSANDRA-2521
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Chris Goffinet
Assignee: Sylvain Lebresne
Fix For: 1.0
Attachments:
0001-Use-reference-counting-to-decide-when-a-sstable-can-.patch,
0001-Use-reference-counting-to-decide-when-a-sstable-can-v2.patch,
0002-Force-unmapping-files-before-deletion-v2.patch, 2521-v3.txt, 2521-v4.txt
http://wiki.apache.org/cassandra/MemtableSSTable
Let's move to using reference counting instead of relying on GC to be called
in StorageService.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2833) CounterColumn should have an optional binary field so that double can be incremented/decremented along with long
[ https://issues.apache.org/jira/browse/CASSANDRA-2833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056425#comment-13056425 ] Sylvain Lebresne commented on CASSANDRA-2833: - Do people really still use double nowadays ?! :) I mean I'll admit that I don't see right away why you can't use long to track durations or other values common to analytics. Don't get me wrong, that may require the client to multiply its values by some power of 10, but *not feasible* seems a bit of a strong word to me. I guess what I'm saying is that I think we should avoid being in the let's have it because it sounds cool (a.k.a feature creep) and make sure we stay in let's have it because it is generally useful and solve a problem that can't be solved otherwise easily land. And I'm not saying that adding double support is of the former kind, but I guess I'm not yet convinced it is completely of the latter kind either. Initial ranting being done, this is technically doable and fairly easily so. This will add a bit of clutter internally (imho, you'd want to add a DoubleCounterType (or RealCounterType so people don't think it doubles the value each time) and subclass/refactor CounterContext somehow) but probably not too much. CounterColumn should have an optional binary field so that double can be incremented/decremented along with long Key: CASSANDRA-2833 URL: https://issues.apache.org/jira/browse/CASSANDRA-2833 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Joe Stein Currently CounterColumn only has a long making it not feasible to track increment/decrement of durations or other values common to analytics represented as a double The change I am proposing to implement, after some discussions/advice in the irc to issues raised, is to add a new optional binary field to CounterColumn (thrift). I was thinking we could call it *operand* Under the hood (src/java/org/apache/cassandra/db/CounterColumn.java) I would handle things with byte[] moving between long and double as internal helper functions with case switch on type of operand we are setting might also need an optional enum for type perhaps too so the client can let the server know how it should materialize the bytes for when it += the value stored The clients should continue to work as expected and folks looking to use this can just do so. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2755) ColumnFamilyRecordWriter fails to throw a write exception encountered after the user begins to close the writer
[
https://issues.apache.org/jira/browse/CASSANDRA-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056446#comment-13056446
]
Mck SembWever commented on CASSANDRA-2755:
--
Jonathan: Is your patch being applied?
ColumnFamilyRecordWriter fails to throw a write exception encountered after
the user begins to close the writer
---
Key: CASSANDRA-2755
URL: https://issues.apache.org/jira/browse/CASSANDRA-2755
Project: Cassandra
Issue Type: Bug
Components: Hadoop
Affects Versions: 0.8.0
Reporter: Greg Katz
Assignee: Mck SembWever
Attachments: 2755-v2.txt, CASSANDRA-2755.patch
There appears to be a race condition in {{ColumnFamilyRecordWriter}} that can
result in the loss of an exception. Here is how it can happen (W stands for
the {{RangeClient}}'s worker thread; U stands for the
{{ColumnFamilyRecordWriter}} user's thread):
# W: {{RangeClient}}'s {{run}} method catches an exception originating in the
Thrift client/socket, but doesn't get a chance to set it on the
{{lastException}} field before it the thread is preempted.
# U: The user calls {{close}} which calls {{stopNicely}}. Because the
{{lastException}} field is null, {{stopNicely}} does not throw anything.
{{close}} then joins on the worker thread.
# W: The {{RangeClient}}'s {{run}} method sets the {{lastException}} field
and exits.
# U: Although the thread in {{close}} is waiting for the worker thread to
exit, it has already checked the {{lastException}} field so it doesn't detect
the presence of the last exception. Instead, {{close}} returns without
throwing anything.
This race condition means that intermittently write failures will go
undetected.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2823) NPE during range slices with rowrepairs
[
https://issues.apache.org/jira/browse/CASSANDRA-2823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056458#comment-13056458
]
Jonathan Ellis commented on CASSANDRA-2823:
---
does 0.7 need this?
NPE during range slices with rowrepairs
---
Key: CASSANDRA-2823
URL: https://issues.apache.org/jira/browse/CASSANDRA-2823
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.8.2
Environment: This is a trunk build with 2521 and 2433
I somewhat doubt that is related however.
Reporter: Terje Marthinussen
Assignee: Sylvain Lebresne
Fix For: 0.8.2
Attachments: 2823.patch
Doing some heavy testing of relatively fast feeding (5000+ mutations/sec) +
repair on all node + range slices.
Then occasionally killing a node here and there and restarting it.
Triggers the following NPE
ERROR [pool-2-thread-3] 2011-06-24 20:56:27,289 Cassandra.java (line 3210)
Internal error processing get_range_slices
java.lang.NullPointerException
at
org.apache.cassandra.service.RowRepairResolver.maybeScheduleRepairs(RowRepairResolver.java:109)
at
org.apache.cassandra.service.RangeSliceResponseResolver$2.getReduced(RangeSliceResponseResolver.java:112)
at
org.apache.cassandra.service.RangeSliceResponseResolver$2.getReduced(RangeSliceResponseResolver.java:83)
at
org.apache.cassandra.utils.MergeIterator$ManyToOne.consume(MergeIterator.java:161)
at
org.apache.cassandra.utils.MergeIterator.computeNext(MergeIterator.java:88)
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140)
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135)
at
org.apache.cassandra.service.RangeSliceResponseResolver.resolve(RangeSliceResponseResolver.java:120)
at
org.apache.cassandra.service.RangeSliceResponseResolver.resolve(RangeSliceResponseResolver.java:43)
Looking at the code in getReduced:
{noformat}
ColumnFamily resolved = versions.size() 1
?
RowRepairResolver.resolveSuperset(versions)
: versions.get(0);
{noformat}
seems like resolved becomes null when this happens and versions.size is
larger than 1.
RowRepairResolver.resolveSuperset() does actually return null if it cannot
resolve anything, so there is definately a case here which can occur and is
not handled.
It may also be an interesting question if it is guaranteed that
versions.add(current.left.cf);
can never return null?
Jonathan suggested on IRC that maybe
{noformat}
ColumnFamily resolved = versions.size() 1
?
RowRepairResolver.resolveSuperset(versions)
: versions.get(0);
if (resolved == null)
return new Row(key, resolved);
{noformat}
could be a fix.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2755) ColumnFamilyRecordWriter fails to throw a write exception encountered after the user begins to close the writer
[
https://issues.apache.org/jira/browse/CASSANDRA-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056459#comment-13056459
]
Jonathan Ellis commented on CASSANDRA-2755:
---
waiting for a +1, wasn't clear if your last comment was intended that way.
ColumnFamilyRecordWriter fails to throw a write exception encountered after
the user begins to close the writer
---
Key: CASSANDRA-2755
URL: https://issues.apache.org/jira/browse/CASSANDRA-2755
Project: Cassandra
Issue Type: Bug
Components: Hadoop
Affects Versions: 0.8.0
Reporter: Greg Katz
Assignee: Mck SembWever
Attachments: 2755-v2.txt, CASSANDRA-2755.patch
There appears to be a race condition in {{ColumnFamilyRecordWriter}} that can
result in the loss of an exception. Here is how it can happen (W stands for
the {{RangeClient}}'s worker thread; U stands for the
{{ColumnFamilyRecordWriter}} user's thread):
# W: {{RangeClient}}'s {{run}} method catches an exception originating in the
Thrift client/socket, but doesn't get a chance to set it on the
{{lastException}} field before it the thread is preempted.
# U: The user calls {{close}} which calls {{stopNicely}}. Because the
{{lastException}} field is null, {{stopNicely}} does not throw anything.
{{close}} then joins on the worker thread.
# W: The {{RangeClient}}'s {{run}} method sets the {{lastException}} field
and exits.
# U: Although the thread in {{close}} is waiting for the worker thread to
exit, it has already checked the {{lastException}} field so it doesn't detect
the presence of the last exception. Instead, {{close}} returns without
throwing anything.
This race condition means that intermittently write failures will go
undetected.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2755) ColumnFamilyRecordWriter fails to throw a write exception encountered after the user begins to close the writer
[
https://issues.apache.org/jira/browse/CASSANDRA-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056462#comment-13056462
]
Mck SembWever commented on CASSANDRA-2755:
--
Yes it was a +1
ColumnFamilyRecordWriter fails to throw a write exception encountered after
the user begins to close the writer
---
Key: CASSANDRA-2755
URL: https://issues.apache.org/jira/browse/CASSANDRA-2755
Project: Cassandra
Issue Type: Bug
Components: Hadoop
Affects Versions: 0.8.0
Reporter: Greg Katz
Assignee: Mck SembWever
Attachments: 2755-v2.txt, CASSANDRA-2755.patch
There appears to be a race condition in {{ColumnFamilyRecordWriter}} that can
result in the loss of an exception. Here is how it can happen (W stands for
the {{RangeClient}}'s worker thread; U stands for the
{{ColumnFamilyRecordWriter}} user's thread):
# W: {{RangeClient}}'s {{run}} method catches an exception originating in the
Thrift client/socket, but doesn't get a chance to set it on the
{{lastException}} field before it the thread is preempted.
# U: The user calls {{close}} which calls {{stopNicely}}. Because the
{{lastException}} field is null, {{stopNicely}} does not throw anything.
{{close}} then joins on the worker thread.
# W: The {{RangeClient}}'s {{run}} method sets the {{lastException}} field
and exits.
# U: Although the thread in {{close}} is waiting for the worker thread to
exit, it has already checked the {{lastException}} field so it doesn't detect
the presence of the last exception. Instead, {{close}} returns without
throwing anything.
This race condition means that intermittently write failures will go
undetected.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1140550 - in /cassandra/branches/cassandra-0.7: CHANGES.txt src/java/org/apache/cassandra/service/RangeSliceResponseResolver.java src/java/org/apache/cassandra/service/RowRepairResolver.j
Author: slebresne
Date: Tue Jun 28 12:12:15 2011
New Revision: 1140550
URL: http://svn.apache.org/viewvc?rev=1140550view=rev
Log:
Fix potential NPE during read repair
patch by slebresne; reviewed by jbellis for CASSANDRA-2823
Modified:
cassandra/branches/cassandra-0.7/CHANGES.txt
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/RangeSliceResponseResolver.java
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/RowRepairResolver.java
Modified: cassandra/branches/cassandra-0.7/CHANGES.txt
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/CHANGES.txt?rev=1140550r1=1140549r2=1140550view=diff
==
--- cassandra/branches/cassandra-0.7/CHANGES.txt (original)
+++ cassandra/branches/cassandra-0.7/CHANGES.txt Tue Jun 28 12:12:15 2011
@@ -22,6 +22,7 @@
(CASSANDRA-2766, CASSANDRA-2792)
* Expose number of threads blocked on submitting memtable to flush
(CASSANDRA-2817)
+ * Fix potential NPE during read repair (CASSANDRA-2823)
0.7.6
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/RangeSliceResponseResolver.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/RangeSliceResponseResolver.java?rev=1140550r1=1140549r2=1140550view=diff
==
---
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/RangeSliceResponseResolver.java
(original)
+++
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/RangeSliceResponseResolver.java
Tue Jun 28 12:12:15 2011
@@ -117,7 +117,9 @@ public class RangeSliceResponseResolver
}
}
}
-RowRepairResolver.maybeScheduleRepairs(resolved, table, key,
versions, versionSources);
+// resolved can be null even if versions doesn't have all
nulls because of the call to removeDeleted in resolveSuperSet
+if (resolved != null)
+RowRepairResolver.maybeScheduleRepairs(resolved, table,
key, versions, versionSources);
versions.clear();
versionSources.clear();
return new Row(key, resolved);
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/RowRepairResolver.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/RowRepairResolver.java?rev=1140550r1=1140549r2=1140550view=diff
==
---
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/RowRepairResolver.java
(original)
+++
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/RowRepairResolver.java
Tue Jun 28 12:12:15 2011
@@ -78,7 +78,9 @@ public class RowRepairResolver extends A
resolved = resolveSuperset(versions);
if (logger.isDebugEnabled())
logger.debug(versions merged);
-maybeScheduleRepairs(resolved, table, key, versions, endpoints);
+// resolved can be null even if versions doesn't have all nulls
because of the call to removeDeleted in resolveSuperSet
+if (resolved != null)
+maybeScheduleRepairs(resolved, table, key, versions,
endpoints);
}
else
{
svn commit: r1140551 - in /cassandra/branches/cassandra-0.8: ./ contrib/ interface/thrift/gen-java/org/apache/cassandra/thrift/
Author: slebresne Date: Tue Jun 28 12:13:51 2011 New Revision: 1140551 URL: http://svn.apache.org/viewvc?rev=1140551view=rev Log: Merge from 0.7 Modified: cassandra/branches/cassandra-0.8/ (props changed) cassandra/branches/cassandra-0.8/contrib/ (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/NotFoundException.java (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/SuperColumn.java (props changed) Propchange: cassandra/branches/cassandra-0.8/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Tue Jun 28 12:13:51 2011 @@ -1,5 +1,5 @@ /cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1131291 -/cassandra/branches/cassandra-0.7:1026516-1138710,1138996 +/cassandra/branches/cassandra-0.7:1026516-1138710,1138996,1140550 /cassandra/branches/cassandra-0.7.0:1053690-1055654 /cassandra/branches/cassandra-0.8:1090934-1125013,1125041 /cassandra/branches/cassandra-0.8.0:1125021-1130369 Propchange: cassandra/branches/cassandra-0.8/contrib/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Tue Jun 28 12:13:51 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-1138710,1138996 +/cassandra/branches/cassandra-0.7/contrib:1026516-1138710,1138996,1140550 /cassandra/branches/cassandra-0.7.0/contrib:1053690-1055654 /cassandra/branches/cassandra-0.8/contrib:1090934-1125013,1125041 /cassandra/branches/cassandra-0.8.0/contrib:1125021-1130369 Propchange: cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Tue Jun 28 12:13:51 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-1131291 -/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1138710,1138996 +/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1138710,1138996,1140550 /cassandra/branches/cassandra-0.7.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1053690-1055654 /cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1090934-1125013,1125041 /cassandra/branches/cassandra-0.8.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1125021-1130369 Propchange: cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Tue Jun 28 12:13:51 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-1131291 -/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1026516-1138710,1138996 +/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1026516-1138710,1138996,1140550 /cassandra/branches/cassandra-0.7.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1053690-1055654 /cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1090934-1125013,1125041 /cassandra/branches/cassandra-0.8.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1125021-1130369 Propchange: cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Tue Jun 28 12:13:51 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-1131291 -/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java:1026516-1138710,1138996
svn commit: r1140553 - in /cassandra/trunk: ./ contrib/ interface/thrift/gen-java/org/apache/cassandra/thrift/ src/java/org/apache/cassandra/service/
Author: slebresne Date: Tue Jun 28 12:15:18 2011 New Revision: 1140553 URL: http://svn.apache.org/viewvc?rev=1140553view=rev Log: Merge from 0.8 Modified: cassandra/trunk/ (props changed) cassandra/trunk/CHANGES.txt cassandra/trunk/contrib/ (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/NotFoundException.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/SuperColumn.java (props changed) cassandra/trunk/src/java/org/apache/cassandra/service/RangeSliceResponseResolver.java cassandra/trunk/src/java/org/apache/cassandra/service/RowRepairResolver.java Propchange: cassandra/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Tue Jun 28 12:15:18 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1131291 /cassandra/branches/cassandra-0.7:1026516-1138710,1138996 /cassandra/branches/cassandra-0.7.0:1053690-1055654 -/cassandra/branches/cassandra-0.8:1090934-1125013,1125019-1139360 +/cassandra/branches/cassandra-0.8:1090934-1125013,1125019-1139360,1140470 /cassandra/branches/cassandra-0.8.0:1125021-1130369 /cassandra/branches/cassandra-0.8.1:1101014-1125018 /cassandra/tags/cassandra-0.7.0-rc3:1051699-1053689 Modified: cassandra/trunk/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/trunk/CHANGES.txt?rev=1140553r1=1140552r2=1140553view=diff == --- cassandra/trunk/CHANGES.txt (original) +++ cassandra/trunk/CHANGES.txt Tue Jun 28 12:15:18 2011 @@ -16,6 +16,8 @@ * Expose number of threads blocked on submitting memtable to flush (CASSANDRA-2817) * add ability to return endpoints to nodetool (CASSANDRA-2776) + * fix potential NPE while scheduling read repair for range slice + (CASSANDRA-2823) 0.8.1 Propchange: cassandra/trunk/contrib/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Tue Jun 28 12:15:18 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6/contrib:922689-1052356,1052358-1053452,1053454,1053456-1068009 /cassandra/branches/cassandra-0.7/contrib:1026516-1138710,1138996 /cassandra/branches/cassandra-0.7.0/contrib:1053690-1055654 -/cassandra/branches/cassandra-0.8/contrib:1090934-1125013,1125019-1139360 +/cassandra/branches/cassandra-0.8/contrib:1090934-1125013,1125019-1139360,1140470 /cassandra/branches/cassandra-0.8.0/contrib:1125021-1130369 /cassandra/branches/cassandra-0.8.1/contrib:1101014-1125018 /cassandra/tags/cassandra-0.7.0-rc3/contrib:1051699-1053689 Propchange: cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Tue Jun 28 12:15:18 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:922689-1052356,1052358-1053452,1053454,1053456-1131291 /cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1138710,1138996 /cassandra/branches/cassandra-0.7.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1053690-1055654 -/cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1090934-1125013,1125019-1139360 +/cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1090934-1125013,1125019-1139360,1140470 /cassandra/branches/cassandra-0.8.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1125021-1130369 /cassandra/branches/cassandra-0.8.1/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1101014-1125018 /cassandra/tags/cassandra-0.7.0-rc3/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1051699-1053689 Propchange: cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Tue Jun 28 12:15:18 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:922689-1052356,1052358-1053452,1053454,1053456-1131291 /cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1026516-1138710,1138996
svn commit: r1140554 - in /cassandra/trunk: ./ contrib/ interface/thrift/gen-java/org/apache/cassandra/thrift/ src/java/org/apache/cassandra/db/
Author: slebresne Date: Tue Jun 28 12:16:08 2011 New Revision: 1140554 URL: http://svn.apache.org/viewvc?rev=1140554view=rev Log: Merge from 0.8 Modified: cassandra/trunk/ (props changed) cassandra/trunk/CHANGES.txt cassandra/trunk/contrib/ (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/NotFoundException.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/SuperColumn.java (props changed) cassandra/trunk/src/java/org/apache/cassandra/db/SystemTable.java Propchange: cassandra/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Tue Jun 28 12:16:08 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1131291 /cassandra/branches/cassandra-0.7:1026516-1138710,1138996 /cassandra/branches/cassandra-0.7.0:1053690-1055654 -/cassandra/branches/cassandra-0.8:1090934-1125013,1125019-1139360,1140470 +/cassandra/branches/cassandra-0.8:1090934-1125013,1125019-1139360,1140470,1140472 /cassandra/branches/cassandra-0.8.0:1125021-1130369 /cassandra/branches/cassandra-0.8.1:1101014-1125018 /cassandra/tags/cassandra-0.7.0-rc3:1051699-1053689 Modified: cassandra/trunk/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/trunk/CHANGES.txt?rev=1140554r1=1140553r2=1140554view=diff == --- cassandra/trunk/CHANGES.txt (original) +++ cassandra/trunk/CHANGES.txt Tue Jun 28 12:16:08 2011 @@ -18,6 +18,7 @@ * add ability to return endpoints to nodetool (CASSANDRA-2776) * fix potential NPE while scheduling read repair for range slice (CASSANDRA-2823) + * Fix race in SystemTable.getCurrentLocalNodeId (CASSANDRA-2824) 0.8.1 Propchange: cassandra/trunk/contrib/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Tue Jun 28 12:16:08 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6/contrib:922689-1052356,1052358-1053452,1053454,1053456-1068009 /cassandra/branches/cassandra-0.7/contrib:1026516-1138710,1138996 /cassandra/branches/cassandra-0.7.0/contrib:1053690-1055654 -/cassandra/branches/cassandra-0.8/contrib:1090934-1125013,1125019-1139360,1140470 +/cassandra/branches/cassandra-0.8/contrib:1090934-1125013,1125019-1139360,1140470,1140472 /cassandra/branches/cassandra-0.8.0/contrib:1125021-1130369 /cassandra/branches/cassandra-0.8.1/contrib:1101014-1125018 /cassandra/tags/cassandra-0.7.0-rc3/contrib:1051699-1053689 Propchange: cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Tue Jun 28 12:16:08 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:922689-1052356,1052358-1053452,1053454,1053456-1131291 /cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1138710,1138996 /cassandra/branches/cassandra-0.7.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1053690-1055654 -/cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1090934-1125013,1125019-1139360,1140470 +/cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1090934-1125013,1125019-1139360,1140470,1140472 /cassandra/branches/cassandra-0.8.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1125021-1130369 /cassandra/branches/cassandra-0.8.1/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1101014-1125018 /cassandra/tags/cassandra-0.7.0-rc3/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1051699-1053689 Propchange: cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Tue Jun 28 12:16:08 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:922689-1052356,1052358-1053452,1053454,1053456-1131291 /cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1026516-1138710,1138996 /cassandra/branches/cassandra-0.7.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1053690-1055654
[jira] [Commented] (CASSANDRA-2823) NPE during range slices with rowrepairs
[
https://issues.apache.org/jira/browse/CASSANDRA-2823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056464#comment-13056464
]
Sylvain Lebresne commented on CASSANDRA-2823:
-
You're right, 0.7 needs that too. I've committed it there too.
NPE during range slices with rowrepairs
---
Key: CASSANDRA-2823
URL: https://issues.apache.org/jira/browse/CASSANDRA-2823
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.8.2
Environment: This is a trunk build with 2521 and 2433
I somewhat doubt that is related however.
Reporter: Terje Marthinussen
Assignee: Sylvain Lebresne
Fix For: 0.8.2
Attachments: 2823.patch
Doing some heavy testing of relatively fast feeding (5000+ mutations/sec) +
repair on all node + range slices.
Then occasionally killing a node here and there and restarting it.
Triggers the following NPE
ERROR [pool-2-thread-3] 2011-06-24 20:56:27,289 Cassandra.java (line 3210)
Internal error processing get_range_slices
java.lang.NullPointerException
at
org.apache.cassandra.service.RowRepairResolver.maybeScheduleRepairs(RowRepairResolver.java:109)
at
org.apache.cassandra.service.RangeSliceResponseResolver$2.getReduced(RangeSliceResponseResolver.java:112)
at
org.apache.cassandra.service.RangeSliceResponseResolver$2.getReduced(RangeSliceResponseResolver.java:83)
at
org.apache.cassandra.utils.MergeIterator$ManyToOne.consume(MergeIterator.java:161)
at
org.apache.cassandra.utils.MergeIterator.computeNext(MergeIterator.java:88)
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140)
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135)
at
org.apache.cassandra.service.RangeSliceResponseResolver.resolve(RangeSliceResponseResolver.java:120)
at
org.apache.cassandra.service.RangeSliceResponseResolver.resolve(RangeSliceResponseResolver.java:43)
Looking at the code in getReduced:
{noformat}
ColumnFamily resolved = versions.size() 1
?
RowRepairResolver.resolveSuperset(versions)
: versions.get(0);
{noformat}
seems like resolved becomes null when this happens and versions.size is
larger than 1.
RowRepairResolver.resolveSuperset() does actually return null if it cannot
resolve anything, so there is definately a case here which can occur and is
not handled.
It may also be an interesting question if it is guaranteed that
versions.add(current.left.cf);
can never return null?
Jonathan suggested on IRC that maybe
{noformat}
ColumnFamily resolved = versions.size() 1
?
RowRepairResolver.resolveSuperset(versions)
: versions.get(0);
if (resolved == null)
return new Row(key, resolved);
{noformat}
could be a fix.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
buildbot success in ASF Buildbot on cassandra-trunk
The Buildbot has detected a restored build on builder cassandra-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/cassandra-trunk/builds/1397 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: isis_ubuntu Build Reason: scheduler Build Source Stamp: [branch cassandra/trunk] 1140553 Blamelist: slebresne Build succeeded! sincerely, -The Buildbot
[jira] [Updated] (CASSANDRA-2755) ColumnFamilyRecordWriter fails to throw a write exception encountered after the user begins to close the writer
[
https://issues.apache.org/jira/browse/CASSANDRA-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-2755:
--
Priority: Minor (was: Major)
Affects Version/s: (was: 0.8.0)
0.7.0
Fix Version/s: 0.8.2
0.7.7
ColumnFamilyRecordWriter fails to throw a write exception encountered after
the user begins to close the writer
---
Key: CASSANDRA-2755
URL: https://issues.apache.org/jira/browse/CASSANDRA-2755
Project: Cassandra
Issue Type: Bug
Components: Hadoop
Affects Versions: 0.7.0
Reporter: Greg Katz
Assignee: Mck SembWever
Priority: Minor
Fix For: 0.7.7, 0.8.2
Attachments: 2755-v2.txt, CASSANDRA-2755.patch
There appears to be a race condition in {{ColumnFamilyRecordWriter}} that can
result in the loss of an exception. Here is how it can happen (W stands for
the {{RangeClient}}'s worker thread; U stands for the
{{ColumnFamilyRecordWriter}} user's thread):
# W: {{RangeClient}}'s {{run}} method catches an exception originating in the
Thrift client/socket, but doesn't get a chance to set it on the
{{lastException}} field before it the thread is preempted.
# U: The user calls {{close}} which calls {{stopNicely}}. Because the
{{lastException}} field is null, {{stopNicely}} does not throw anything.
{{close}} then joins on the worker thread.
# W: The {{RangeClient}}'s {{run}} method sets the {{lastException}} field
and exits.
# U: Although the thread in {{close}} is waiting for the worker thread to
exit, it has already checked the {{lastException}} field so it doesn't detect
the presence of the last exception. Instead, {{close}} returns without
throwing anything.
This race condition means that intermittently write failures will go
undetected.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1140565 - in /cassandra/branches/cassandra-0.7: CHANGES.txt src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordWriter.java
Author: jbellis
Date: Tue Jun 28 12:28:00 2011
New Revision: 1140565
URL: http://svn.apache.org/viewvc?rev=1140565view=rev
Log:
fix race that could result in Hadoopwriter failing to throw exception for
encountered error
patch by Mck SembWever and jbellis for CASSANDRA-2755
Modified:
cassandra/branches/cassandra-0.7/CHANGES.txt
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordWriter.java
Modified: cassandra/branches/cassandra-0.7/CHANGES.txt
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/CHANGES.txt?rev=1140565r1=1140564r2=1140565view=diff
==
--- cassandra/branches/cassandra-0.7/CHANGES.txt (original)
+++ cassandra/branches/cassandra-0.7/CHANGES.txt Tue Jun 28 12:28:00 2011
@@ -23,6 +23,8 @@
* Expose number of threads blocked on submitting memtable to flush
(CASSANDRA-2817)
* Fix potential NPE during read repair (CASSANDRA-2823)
+ * fix race that could result in Hadoop writer failing to throw an
+ exception encountered after close() (CASSANDRA-2755)
0.7.6
Modified:
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordWriter.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordWriter.java?rev=1140565r1=1140564r2=1140565view=diff
==
---
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordWriter.java
(original)
+++
cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordWriter.java
Tue Jun 28 12:28:00 2011
@@ -32,15 +32,14 @@ import java.util.concurrent.TimeUnit;
import org.apache.cassandra.client.RingCache;
import org.apache.cassandra.dht.Range;
import org.apache.cassandra.thrift.*;
+import org.apache.cassandra.utils.ByteBufferUtil;
import org.apache.cassandra.utils.Pair;
import org.apache.hadoop.conf.Configuration;
-import org.apache.hadoop.mapreduce.OutputFormat;
import org.apache.hadoop.mapreduce.RecordWriter;
import org.apache.hadoop.mapreduce.TaskAttemptContext;
import org.apache.thrift.TException;
import org.apache.thrift.transport.TSocket;
-import org.apache.cassandra.utils.ByteBufferUtil;
/**
* The codeColumnFamilyRecordWriter/code maps the output lt;key, valuegt;
@@ -219,27 +218,33 @@ implements org.apache.hadoop.mapred.Reco
@Override
public void close(TaskAttemptContext context) throws IOException,
InterruptedException
{
-close((org.apache.hadoop.mapred.Reporter)null);
+close();
}
/** Fills the deprecated RecordWriter interface for streaming. */
@Deprecated
public void close(org.apache.hadoop.mapred.Reporter reporter) throws
IOException
{
+close();
+}
+
+private void close() throws IOException
+{
+// close all the clients before throwing anything
+IOException clientException = null;
for (RangeClient client : clients.values())
-client.stopNicely();
-try
{
-for (RangeClient client : clients.values())
+try
{
-client.join();
client.close();
}
+catch (IOException e)
+{
+clientException = e;
+}
}
-catch (InterruptedException e)
-{
-throw new AssertionError(e);
-}
+if (clientException != null)
+throw clientException;
}
/**
@@ -255,6 +260,9 @@ implements org.apache.hadoop.mapred.Reco
private final BlockingQueuePairByteBuffer, Mutation queue = new
ArrayBlockingQueuePairByteBuffer,Mutation(queueSize);
private volatile boolean run = true;
+// we want the caller to know if something went wrong, so we record
any unrecoverable exception while writing
+// so we can throw it on the caller's stack when he calls put() again,
or if there are no more put calls,
+// when the client is closed.
private volatile IOException lastException;
private Cassandra.Client thriftClient;
@@ -291,15 +299,25 @@ implements org.apache.hadoop.mapred.Reco
}
}
-public void stopNicely() throws IOException
+public void close() throws IOException
{
-if (lastException != null)
-throw lastException;
+// stop the run loop. this will result in closeInternal being
called by the time join() finishes.
run = false;
interrupt();
+try
+{
+this.join();
+}
+catch (InterruptedException e)
+{
+throw new AssertionError(e);
+}
+
+if (lastException != null)
+throw lastException;
svn commit: r1140567 - in /cassandra/branches/cassandra-0.8: ./ contrib/ interface/thrift/gen-java/org/apache/cassandra/thrift/ src/java/org/apache/cassandra/concurrent/ src/java/org/apache/cassandra/
Author: jbellis Date: Tue Jun 28 12:31:51 2011 New Revision: 1140567 URL: http://svn.apache.org/viewvc?rev=1140567view=rev Log: merge from 0.7 Modified: cassandra/branches/cassandra-0.8/ (props changed) cassandra/branches/cassandra-0.8/CHANGES.txt cassandra/branches/cassandra-0.8/contrib/ (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/NotFoundException.java (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/SuperColumn.java (props changed) cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/concurrent/DebuggableThreadPoolExecutor.java cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/HintedHandOffManager.java cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/compaction/CompactionManager.java cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordWriter.java Propchange: cassandra/branches/cassandra-0.8/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Tue Jun 28 12:31:51 2011 @@ -1,5 +1,5 @@ /cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1131291 -/cassandra/branches/cassandra-0.7:1026516-1138710,1138996,1140550 +/cassandra/branches/cassandra-0.7:1026516-1140565 /cassandra/branches/cassandra-0.7.0:1053690-1055654 /cassandra/branches/cassandra-0.8:1090934-1125013,1125041 /cassandra/branches/cassandra-0.8.0:1125021-1130369 Modified: cassandra/branches/cassandra-0.8/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/CHANGES.txt?rev=1140567r1=1140566r2=1140567view=diff == --- cassandra/branches/cassandra-0.8/CHANGES.txt (original) +++ cassandra/branches/cassandra-0.8/CHANGES.txt Tue Jun 28 12:31:51 2011 @@ -84,6 +84,8 @@ * fix repair hanging if a neighbor has nothing to send (CASSANDRA-2797) * purge tombstone even if row is in only one sstable (CASSANDRA-2801) * Fix wrong purge of deleted cf during compaction (CASSANDRA-2786) + * fix race that could result in Hadoop writer failing to throw an + exception encountered after close() (CASSANDRA-2755) 0.8.0-final @@ -202,9 +204,6 @@ * reduce contention on Table.flusherLock (CASSANDRA-1954) * try harder to detect failures during streaming, cleaning up temporary files more reliably (CASSANDRA-2088) - - -0.6.13 * shut down server for OOM on a Thrift thread (CASSANDRA-2269) * fix tombstone handling in repair and sstable2json (CASSANDRA-2279) * preserve version when streaming data from old sstables (CASSANDRA-2283) Propchange: cassandra/branches/cassandra-0.8/contrib/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Tue Jun 28 12:31:51 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-1138710,1138996,1140550 +/cassandra/branches/cassandra-0.7/contrib:1026516-1140565 /cassandra/branches/cassandra-0.7.0/contrib:1053690-1055654 /cassandra/branches/cassandra-0.8/contrib:1090934-1125013,1125041 /cassandra/branches/cassandra-0.8.0/contrib:1125021-1130369 Propchange: cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Tue Jun 28 12:31:51 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-1131291 -/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1138710,1138996,1140550 +/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1140565 /cassandra/branches/cassandra-0.7.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1053690-1055654 /cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1090934-1125013,1125041 /cassandra/branches/cassandra-0.8.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1125021-1130369 Propchange: cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java
[jira] [Commented] (CASSANDRA-2823) NPE during range slices with rowrepairs
[
https://issues.apache.org/jira/browse/CASSANDRA-2823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056472#comment-13056472
]
Hudson commented on CASSANDRA-2823:
---
Integrated in Cassandra-0.7 #514 (See
[https://builds.apache.org/job/Cassandra-0.7/514/])
Fix potential NPE during read repair
patch by slebresne; reviewed by jbellis for CASSANDRA-2823
slebresne :
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1140550
Files :
* /cassandra/branches/cassandra-0.7/CHANGES.txt
*
/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/RangeSliceResponseResolver.java
*
/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/RowRepairResolver.java
NPE during range slices with rowrepairs
---
Key: CASSANDRA-2823
URL: https://issues.apache.org/jira/browse/CASSANDRA-2823
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.8.2
Environment: This is a trunk build with 2521 and 2433
I somewhat doubt that is related however.
Reporter: Terje Marthinussen
Assignee: Sylvain Lebresne
Fix For: 0.8.2
Attachments: 2823.patch
Doing some heavy testing of relatively fast feeding (5000+ mutations/sec) +
repair on all node + range slices.
Then occasionally killing a node here and there and restarting it.
Triggers the following NPE
ERROR [pool-2-thread-3] 2011-06-24 20:56:27,289 Cassandra.java (line 3210)
Internal error processing get_range_slices
java.lang.NullPointerException
at
org.apache.cassandra.service.RowRepairResolver.maybeScheduleRepairs(RowRepairResolver.java:109)
at
org.apache.cassandra.service.RangeSliceResponseResolver$2.getReduced(RangeSliceResponseResolver.java:112)
at
org.apache.cassandra.service.RangeSliceResponseResolver$2.getReduced(RangeSliceResponseResolver.java:83)
at
org.apache.cassandra.utils.MergeIterator$ManyToOne.consume(MergeIterator.java:161)
at
org.apache.cassandra.utils.MergeIterator.computeNext(MergeIterator.java:88)
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140)
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135)
at
org.apache.cassandra.service.RangeSliceResponseResolver.resolve(RangeSliceResponseResolver.java:120)
at
org.apache.cassandra.service.RangeSliceResponseResolver.resolve(RangeSliceResponseResolver.java:43)
Looking at the code in getReduced:
{noformat}
ColumnFamily resolved = versions.size() 1
?
RowRepairResolver.resolveSuperset(versions)
: versions.get(0);
{noformat}
seems like resolved becomes null when this happens and versions.size is
larger than 1.
RowRepairResolver.resolveSuperset() does actually return null if it cannot
resolve anything, so there is definately a case here which can occur and is
not handled.
It may also be an interesting question if it is guaranteed that
versions.add(current.left.cf);
can never return null?
Jonathan suggested on IRC that maybe
{noformat}
ColumnFamily resolved = versions.size() 1
?
RowRepairResolver.resolveSuperset(versions)
: versions.get(0);
if (resolved == null)
return new Row(key, resolved);
{noformat}
could be a fix.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2835) CFMetadata don't set the default for Replicate_on_write correctly
CFMetadata don't set the default for Replicate_on_write correctly -- Key: CASSANDRA-2835 URL: https://issues.apache.org/jira/browse/CASSANDRA-2835 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.0 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Fix For: 0.8.2 Attachments: 2835.patch Replicate_on_write *must* default to true (defaulting to false is very dangerous and imho, the option of setting it to false shouldn't exist in the first place) and CFMetadata.DEFAULT_REPLICATE_ON_WRITE is correctly true. But it doesn't get set correctly. Instead, the code force the value of the cf_def even if it wasn't defined, resulting in setting it to false since that is the default value for a boolean in JAVA. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2835) CFMetadata don't set the default for Replicate_on_write correctly
[ https://issues.apache.org/jira/browse/CASSANDRA-2835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-2835: Attachment: 2835.patch CFMetadata don't set the default for Replicate_on_write correctly -- Key: CASSANDRA-2835 URL: https://issues.apache.org/jira/browse/CASSANDRA-2835 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.0 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Labels: counters Fix For: 0.8.2 Attachments: 2835.patch Replicate_on_write *must* default to true (defaulting to false is very dangerous and imho, the option of setting it to false shouldn't exist in the first place) and CFMetadata.DEFAULT_REPLICATE_ON_WRITE is correctly true. But it doesn't get set correctly. Instead, the code force the value of the cf_def even if it wasn't defined, resulting in setting it to false since that is the default value for a boolean in JAVA. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2835) CFMetadata don't set the default for Replicate_on_write correctly
[ https://issues.apache.org/jira/browse/CASSANDRA-2835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056475#comment-13056475 ] Jonathan Ellis commented on CASSANDRA-2835: --- +1 CFMetadata don't set the default for Replicate_on_write correctly -- Key: CASSANDRA-2835 URL: https://issues.apache.org/jira/browse/CASSANDRA-2835 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.0 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Labels: counters Fix For: 0.8.2 Attachments: 2835.patch Replicate_on_write *must* default to true (defaulting to false is very dangerous and imho, the option of setting it to false shouldn't exist in the first place) and CFMetadata.DEFAULT_REPLICATE_ON_WRITE is correctly true. But it doesn't get set correctly. Instead, the code force the value of the cf_def even if it wasn't defined, resulting in setting it to false since that is the default value for a boolean in JAVA. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[Cassandra Wiki] Update of Counters by SylvainLebresne
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Cassandra Wiki for
change notification.
The Counters page has been changed by SylvainLebresne:
http://wiki.apache.org/cassandra/Counters?action=diffrev1=13rev2=14
== Getting started ==
- In order to use counters in Cassandra you need to first set up a cluster, see
the [[http://wiki.apache.org/cassandra/GettingStarted|Getting started]] guide
for more information. Currently the counters code is slated for a release in
Cassandra 0.8.0.
+ In order to use counters in Cassandra you need to first set up a cluster, see
the [[http://wiki.apache.org/cassandra/GettingStarted|Getting started]] guide
for more information. Also note that counters are available starting with
Cassandra 0.8.0.
Configuration
+ To use counters, you have to define a column family (or super column family)
whose columns will act as counters. To create such a column family `counterCF`
using the CLI, you will have to do:
- When first setting up the cluster you can specify a column or super column
that will act as counters.
- For example using the cassandra.yaml configuration file:
-
{{{
+ [default@test] create column family counterCF with
default_validation_class=CounterColumnType and replicate_on_write=true;
- - name: Counter1
- default_validation_class: CounterColumnType
-
- - name: SuperCounter1
- column_type: Super
- default_validation_class: CounterColumnType
}}}
+ Setting the `default_validation_class` to `CounterColumnType` indicates that
the column will be counters. Setting `replicate_on_write=true` will be optional
starting in 0.8.2, but a bug made it default to false in 0.8.0 and 0.8.1, which
is unsafe.
Incrementing and accessing counters
svn commit: r1140585 - in /cassandra/branches/cassandra-0.8: CHANGES.txt NEWS.txt build.xml src/java/org/apache/cassandra/config/CFMetaData.java
Author: slebresne
Date: Tue Jun 28 13:14:55 2011
New Revision: 1140585
URL: http://svn.apache.org/viewvc?rev=1140585view=rev
Log:
Fix incorrect default setting for replicate_on_write
patch by slebresne; reviewed by jbellis for CASSANDRA-2835
Modified:
cassandra/branches/cassandra-0.8/CHANGES.txt
cassandra/branches/cassandra-0.8/NEWS.txt
cassandra/branches/cassandra-0.8/build.xml
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/config/CFMetaData.java
Modified: cassandra/branches/cassandra-0.8/CHANGES.txt
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/CHANGES.txt?rev=1140585r1=1140584r2=1140585view=diff
==
--- cassandra/branches/cassandra-0.8/CHANGES.txt (original)
+++ cassandra/branches/cassandra-0.8/CHANGES.txt Tue Jun 28 13:14:55 2011
@@ -10,6 +10,7 @@
* fix potential NPE while scheduling read repair for range slice
(CASSANDRA-2823)
* Fix race in SystemTable.getCurrentLocalNodeId (CASSANDRA-2824)
+ * Correctly set default for replicate_on_write (CASSANDRA-2835)
0.8.1
Modified: cassandra/branches/cassandra-0.8/NEWS.txt
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/NEWS.txt?rev=1140585r1=1140584r2=1140585view=diff
==
--- cassandra/branches/cassandra-0.8/NEWS.txt (original)
+++ cassandra/branches/cassandra-0.8/NEWS.txt Tue Jun 28 13:14:55 2011
@@ -1,3 +1,17 @@
+0.8.2
+=
+
+Upgrading
+-
+- 0.8.0 and 0.8.1 shipped with a bug that was setting the
+ replicate_on_write option for counter column families to false (this
+ option has no effect on non-counter column family). This is an unsafe
+ default and 0.8.2 correct this, the default for replicate_on_write is
+ now true. It is advised to update your counter column family definitions
+ if replicate_on_write was uncorrectly set to false (before or after
+ upgrade).
+
+
0.8.1
=
Modified: cassandra/branches/cassandra-0.8/build.xml
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/build.xml?rev=1140585r1=1140584r2=1140585view=diff
==
--- cassandra/branches/cassandra-0.8/build.xml (original)
+++ cassandra/branches/cassandra-0.8/build.xml Tue Jun 28 13:14:55 2011
@@ -25,7 +25,7 @@
property name=debuglevel value=source,lines,vars/
!-- default version and SCM information (we need the default SCM info as
people may checkout with git-svn) --
-property name=base.version value=0.8.1/
+property name=base.version value=0.8.2-dev/
property name=scm.default.path
value=cassandra/branches/cassandra-0.8/
property name=scm.default.connection
value=scm:svn:http://svn.apache.org/repos/asf/${scm.default.path}/
property name=scm.default.developerConnection
value=scm:svn:https://svn.apache.org/repos/asf/${scm.default.path}/
Modified:
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/config/CFMetaData.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/config/CFMetaData.java?rev=1140585r1=1140584r2=1140585view=diff
==
---
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/config/CFMetaData.java
(original)
+++
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/config/CFMetaData.java
Tue Jun 28 13:14:55 2011
@@ -614,6 +614,8 @@ public final class CFMetaData
{
if (!cf_def.isSetComment())
cf_def.setComment();
+if (!cf_def.isSetReplicate_on_write())
+
cf_def.setReplicate_on_write(CFMetaData.DEFAULT_REPLICATE_ON_WRITE);
if (!cf_def.isSetMin_compaction_threshold())
cf_def.setMin_compaction_threshold(CFMetaData.DEFAULT_MIN_COMPACTION_THRESHOLD);
if (!cf_def.isSetMax_compaction_threshold())
[jira] [Commented] (CASSANDRA-2835) CFMetadata don't set the default for Replicate_on_write correctly
[ https://issues.apache.org/jira/browse/CASSANDRA-2835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056493#comment-13056493 ] Sylvain Lebresne commented on CASSANDRA-2835: - Committed, thanks (I've included a not in the NEWS file as well as updated the wiki). CFMetadata don't set the default for Replicate_on_write correctly -- Key: CASSANDRA-2835 URL: https://issues.apache.org/jira/browse/CASSANDRA-2835 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.0 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Labels: counters Fix For: 0.8.2 Attachments: 2835.patch Replicate_on_write *must* default to true (defaulting to false is very dangerous and imho, the option of setting it to false shouldn't exist in the first place) and CFMetadata.DEFAULT_REPLICATE_ON_WRITE is correctly true. But it doesn't get set correctly. Instead, the code force the value of the cf_def even if it wasn't defined, resulting in setting it to false since that is the default value for a boolean in JAVA. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-957) convenience workflow for replacing dead node
[ https://issues.apache.org/jira/browse/CASSANDRA-957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056504#comment-13056504 ] Vijay commented on CASSANDRA-957: - Thanks Chris, I will give it a try... convenience workflow for replacing dead node Key: CASSANDRA-957 URL: https://issues.apache.org/jira/browse/CASSANDRA-957 Project: Cassandra Issue Type: Wish Components: Core, Tools Reporter: Jonathan Ellis Fix For: 1.0 Attachments: 0001-Support-bringing-back-a-node-to-the-cluster-that-exi.patch, 0002-Do-not-include-local-node-when-computing-workMap.patch Original Estimate: 24h Remaining Estimate: 24h Replacing a dead node with a new one is a common operation, but nodetool removetoken followed by bootstrap is inefficient (re-replicating data first to the remaining nodes, then to the new one) and manually bootstrapping to a token just less than the old one's, followed by nodetool removetoken is slightly painful and prone to manual errors. First question: how would you expose this in our tool ecosystem? It needs to be a startup-time option to the new node, so it can't be nodetool, and messing with the config xml definitely takes the convenience out. A one-off -DreplaceToken=XXY argument? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2755) ColumnFamilyRecordWriter fails to throw a write exception encountered after the user begins to close the writer
[
https://issues.apache.org/jira/browse/CASSANDRA-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056503#comment-13056503
]
Hudson commented on CASSANDRA-2755:
---
Integrated in Cassandra-0.7 #515 (See
[https://builds.apache.org/job/Cassandra-0.7/515/])
fix race that could result in Hadoopwriter failing to throw exception for
encountered error
patch by Mck SembWever and jbellis for CASSANDRA-2755
jbellis :
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1140565
Files :
* /cassandra/branches/cassandra-0.7/CHANGES.txt
*
/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordWriter.java
ColumnFamilyRecordWriter fails to throw a write exception encountered after
the user begins to close the writer
---
Key: CASSANDRA-2755
URL: https://issues.apache.org/jira/browse/CASSANDRA-2755
Project: Cassandra
Issue Type: Bug
Components: Hadoop
Affects Versions: 0.7.0
Reporter: Greg Katz
Assignee: Mck SembWever
Priority: Minor
Fix For: 0.7.7, 0.8.2
Attachments: 2755-v2.txt, CASSANDRA-2755.patch
There appears to be a race condition in {{ColumnFamilyRecordWriter}} that can
result in the loss of an exception. Here is how it can happen (W stands for
the {{RangeClient}}'s worker thread; U stands for the
{{ColumnFamilyRecordWriter}} user's thread):
# W: {{RangeClient}}'s {{run}} method catches an exception originating in the
Thrift client/socket, but doesn't get a chance to set it on the
{{lastException}} field before it the thread is preempted.
# U: The user calls {{close}} which calls {{stopNicely}}. Because the
{{lastException}} field is null, {{stopNicely}} does not throw anything.
{{close}} then joins on the worker thread.
# W: The {{RangeClient}}'s {{run}} method sets the {{lastException}} field
and exits.
# U: Although the thread in {{close}} is waiting for the worker thread to
exit, it has already checked the {{lastException}} field so it doesn't detect
the presence of the last exception. Instead, {{close}} returns without
throwing anything.
This race condition means that intermittently write failures will go
undetected.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2833) CounterColumn should have an optional binary field so that double can be incremented/decremented along with long
[ https://issues.apache.org/jira/browse/CASSANDRA-2833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056513#comment-13056513 ] Joe Stein commented on CASSANDRA-2833: -- the phrasing *not feasible* was a bit strong. In general I would argue that the up take of a system would want to have the edges smoothed out as it continued so that the flexibility of it being able to have workarounds are fantastic but as it evolved those workarounds can be internalized to the system. This burden is not always completely on the programming side but in essence the development team and having to explain to every developer that touches your system why you are multiplying by 10 and when they need to divide by 10 to get data out in the format they want. This just makes for an unclean implementation, granted functional for now with your nice workaround, by having to-do some type of naming conventions realPricing, longInventory so that folks do not incorrectly infer the wrong implementation of the counter in their own work effort. Not using double as a name anywhere is a really good point that is just going to add possible confusion. And, yes. floats are used a lot in Analytics in Mobile and Healthcare (at least two I can speak about directly) in addition to Advertising. In mobile the duration of users using application is a metric very much sought after and used and in Healthcare (as would also hold true for lots of other business verticals) when providing analyses of reimbursement between payer and provider. Most often these durations are coupled with a duration count because you do not always have 1:1 duration between uses and times you have that data though this complex type of counter I think representing as 2 columns (one long and one double) so the caller can create their average themselves which is how it is done now. What do you think about the idea to not upset existing users and support new ones with the thrift CounterColumn additional optional binary operand field? It was not my idea but I think a good one (thanks Stu Hood)? So the change could then be: 1) create a new CF RealCounterType - this would let the underlying code know to use the double instead of the long 2) change CounterColumn thrift and db accordingly so that old clients still work but new ones can use this new CF RealCounterType a) either with a optional double realvalue or b) optional binary operand 3) CounterContext seems it needs to have the support between long and double in how it wants to pass the data inside for the += in total as well as some overloading of writeElement looking at the context it seems cleaner to make the double in addition to long rather than storing it in bytes, granted this is the first time I am looking at :) or if we store it in bytes the conversion If you and others think this is a good change I am happy to start on it granted while it is probably a simple change it will take me some bumps and bruises as I go through it to get it working. And I do agree that change for the sake of change or because it is cool is never a good way to proceed which can be argued for this change, yes. But I am arguing that it is useful +1 but would like to hear from others so this change is not only for me maybe everyone else is ok the way it is CounterColumn should have an optional binary field so that double can be incremented/decremented along with long Key: CASSANDRA-2833 URL: https://issues.apache.org/jira/browse/CASSANDRA-2833 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Joe Stein Currently CounterColumn only has a long making it not feasible to track increment/decrement of durations or other values common to analytics represented as a double The change I am proposing to implement, after some discussions/advice in the irc to issues raised, is to add a new optional binary field to CounterColumn (thrift). I was thinking we could call it *operand* Under the hood (src/java/org/apache/cassandra/db/CounterColumn.java) I would handle things with byte[] moving between long and double as internal helper functions with case switch on type of operand we are setting might also need an optional enum for type perhaps too so the client can let the server know how it should materialize the bytes for when it += the value stored The clients should continue to work as expected and folks looking to use this can just do so. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2833) CounterColumn should have an optional binary field so that double can be incremented/decremented along with long
[
https://issues.apache.org/jira/browse/CASSANDRA-2833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056522#comment-13056522
]
Rick Shaw commented on CASSANDRA-2833:
--
A wrinkle that might be worth consideration is that the JDBC driver will
eventually need an {{AbstractType}} implementation of {{BigDecimal}}
({{NumericType}}?) in order to complete it data type support in
{{PreparedStatement}} and {{ResultSet}}.
This data type represents arbitrary-precision signed decimal numbers in a
generalized way. It has attributes similar to {{BigInteger}} ({{IntegerType}})
It is really a {{BigInteger}} representing the unscaled part with a long
representing the scaling.
This may be a better alternative than Double as a generalized counter type
targeted at analytics data.
CounterColumn should have an optional binary field so that double can be
incremented/decremented along with long
Key: CASSANDRA-2833
URL: https://issues.apache.org/jira/browse/CASSANDRA-2833
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Joe Stein
Currently CounterColumn only has a long making it not feasible to track
increment/decrement of durations or other values common to analytics
represented as a double
The change I am proposing to implement, after some discussions/advice in the
irc to issues raised, is to add a new optional binary field to CounterColumn
(thrift). I was thinking we could call it *operand*
Under the hood (src/java/org/apache/cassandra/db/CounterColumn.java) I would
handle things with byte[] moving between long and double as internal helper
functions with case switch on type of operand we are setting might also
need an optional enum for type perhaps too so the client can let the server
know how it should materialize the bytes for when it += the value stored
The clients should continue to work as expected and folks looking to use this
can just do so.
--
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=13056524#comment-13056524
]
Mck SembWever commented on CASSANDRA-2388:
--
bq. It looks like there's a ton of effort put in to avoiding making
sortByProximity work w/ non-local nodes
Because it's only when that local node is down that we actually need to sort...
When/if DynamicEndpointSnitch's limitation is fixed (and it can sort by
non-local nodes) then CassandraServer.java need not bypass it. But this won't
simplify the code in CFRR. Now that CFIF supports multiple initialAddresses the
method sortEndpointsByProximity(..) in CFIF can be rewritten (ie any connection
to any initialAddress is all we need, no need to mess around with trying to
connect through replica's to find information about replicas...)
bq. Wait, why do we even care? local node IS the right host to sort against
No. initialAddress is the right node to sort against. And it should be local
node. And then we don't care about the replica.
But when initialAddress is down, then we randomly connect to another c* node
so to find out of the replica we know about which are 1) up, 2) closest, and 3)
in the same dc. Then it is a random c* node that becomes the local node and
the call needs to be {{snitch.sortByProximity(initialAddress, addresses)}}.
But yes... the CFRR code is contorted. In many ways i prefer the simplicity of
the first patch (both in api and in implementation) despite it not being as
correct. i thought of this fallback to replica as a last resort to keep the
m/r job running, rather than an actively used feature where
DynamicEndpointSnitch's scores will maximise performance. But then i'm only
thinking in terms of a small c* cluster and i certainly am naive about what
performance gains these scores can give...
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
Affects Versions: 0.7.6, 0.8.0
Reporter: Eldon Stegall
Assignee: Jeremy Hanna
Labels: hadoop, inputformat
Fix For: 0.7.7, 0.8.2
Attachments: 0002_On_TException_try_next_split.patch,
CASSANDRA-2388.patch, CASSANDRA-2388.patch, CASSANDRA-2388.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] [Issue Comment Edited] (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=13056524#comment-13056524
]
Mck SembWever edited comment on CASSANDRA-2388 at 6/28/11 2:14 PM:
---
bq. It looks like there's a ton of effort put in to avoiding making
sortByProximity work w/ non-local nodes
Because it's only when that local node is down that we actually need to sort...
When/if DynamicEndpointSnitch's limitation is fixed (and it can sort by
non-local nodes) then CassandraServer.java need not bypass it. But this won't
simplify the code in CFRR. Now that CFIF supports multiple initialAddresses the
method CFRR.sortEndpointsByProximity(..) can be rewritten (ie any connection to
any initialAddress is all we need, no need to mess around with trying to
connect through replica's to find information about replicas...)
bq. Wait, why do we even care? local node IS the right host to sort against
No. initialAddress is the right node to sort against. And it should be local
node. And then we don't care about the replica.
But when initialAddress is down, then we randomly connect to another c* node
so to find out of the replica we know about which are 1) up, 2) closest, and 3)
in the same dc. Then it is a random c* node that becomes the local node and
the call needs to be {{snitch.sortByProximity(initialAddress, addresses)}}.
But yes... the CFRR code is contorted. In many ways i prefer the simplicity of
the first patch (both in api and in implementation) despite it not being as
correct. i thought of this fallback to replica as a last resort to keep the
m/r job running, rather than an actively used feature where
DynamicEndpointSnitch's scores will maximise performance. But then i'm only
thinking in terms of a small c* cluster and i certainly am naive about what
performance gains these scores can give...
was (Author: michaelsembwever):
bq. It looks like there's a ton of effort put in to avoiding making
sortByProximity work w/ non-local nodes
Because it's only when that local node is down that we actually need to sort...
When/if DynamicEndpointSnitch's limitation is fixed (and it can sort by
non-local nodes) then CassandraServer.java need not bypass it. But this won't
simplify the code in CFRR. Now that CFIF supports multiple initialAddresses the
method sortEndpointsByProximity(..) in CFIF can be rewritten (ie any connection
to any initialAddress is all we need, no need to mess around with trying to
connect through replica's to find information about replicas...)
bq. Wait, why do we even care? local node IS the right host to sort against
No. initialAddress is the right node to sort against. And it should be local
node. And then we don't care about the replica.
But when initialAddress is down, then we randomly connect to another c* node
so to find out of the replica we know about which are 1) up, 2) closest, and 3)
in the same dc. Then it is a random c* node that becomes the local node and
the call needs to be {{snitch.sortByProximity(initialAddress, addresses)}}.
But yes... the CFRR code is contorted. In many ways i prefer the simplicity of
the first patch (both in api and in implementation) despite it not being as
correct. i thought of this fallback to replica as a last resort to keep the
m/r job running, rather than an actively used feature where
DynamicEndpointSnitch's scores will maximise performance. But then i'm only
thinking in terms of a small c* cluster and i certainly am naive about what
performance gains these scores can give...
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
Affects Versions: 0.7.6, 0.8.0
Reporter: Eldon Stegall
Assignee: Jeremy Hanna
Labels: hadoop, inputformat
Fix For: 0.7.7, 0.8.2
Attachments: 0002_On_TException_try_next_split.patch,
CASSANDRA-2388.patch, CASSANDRA-2388.patch, CASSANDRA-2388.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] [Issue Comment Edited] (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=13056524#comment-13056524
]
Mck SembWever edited comment on CASSANDRA-2388 at 6/28/11 2:19 PM:
---
bq. It looks like there's a ton of effort put in to avoiding making
sortByProximity work w/ non-local nodes
Because it's only when that local node is down that we actually need to sort...
When/if DynamicEndpointSnitch's limitation is fixed (and it can sort by
non-local nodes) then CassandraServer.java need not bypass it. But this won't
simplify the code in CFRR. Now that CFIF supports multiple initialAddresses the
method CFRR.sortEndpointsByProximity(..) can be rewritten (ie any connection to
any initialAddress is all we need, no need to mess around with trying to
connect through replica's to find information about replicas...)
bq. Wait, why do we even care? local node IS the right host to sort against
Depends on this is CFRR's local node or CassandraServer's local node...
CFRR's local node is the right and only node worth sorting against, it being
the task tracker node.
But when c* on the task tracker node is down, then we randomly connect to
another c* node so to find out of the replica we know about which are 1) up, 2)
closest, and 3) in the same dc. Then it is a random c* node that becomes the
local node and the call needs to be {{snitch.sortByProximity(initialAddress,
addresses)}}.
But yes... the CFRR code is contorted. In many ways i prefer the simplicity of
the first patch (both in api and in implementation) despite it not being as
correct. i thought of this fallback to replica as a last resort to keep the
m/r job running, rather than an actively used feature where
DynamicEndpointSnitch's scores will maximise performance. But then i'm only
thinking in terms of a small c* cluster and i certainly am naive about what
performance gains these scores can give...
was (Author: michaelsembwever):
bq. It looks like there's a ton of effort put in to avoiding making
sortByProximity work w/ non-local nodes
Because it's only when that local node is down that we actually need to sort...
When/if DynamicEndpointSnitch's limitation is fixed (and it can sort by
non-local nodes) then CassandraServer.java need not bypass it. But this won't
simplify the code in CFRR. Now that CFIF supports multiple initialAddresses the
method CFRR.sortEndpointsByProximity(..) can be rewritten (ie any connection to
any initialAddress is all we need, no need to mess around with trying to
connect through replica's to find information about replicas...)
bq. Wait, why do we even care? local node IS the right host to sort against
No. initialAddress is the right node to sort against. And it should be local
node. And then we don't care about the replica.
But when initialAddress is down, then we randomly connect to another c* node
so to find out of the replica we know about which are 1) up, 2) closest, and 3)
in the same dc. Then it is a random c* node that becomes the local node and
the call needs to be {{snitch.sortByProximity(initialAddress, addresses)}}.
But yes... the CFRR code is contorted. In many ways i prefer the simplicity of
the first patch (both in api and in implementation) despite it not being as
correct. i thought of this fallback to replica as a last resort to keep the
m/r job running, rather than an actively used feature where
DynamicEndpointSnitch's scores will maximise performance. But then i'm only
thinking in terms of a small c* cluster and i certainly am naive about what
performance gains these scores can give...
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
Affects Versions: 0.7.6, 0.8.0
Reporter: Eldon Stegall
Assignee: Jeremy Hanna
Labels: hadoop, inputformat
Fix For: 0.7.7, 0.8.2
Attachments: 0002_On_TException_try_next_split.patch,
CASSANDRA-2388.patch, CASSANDRA-2388.patch, CASSANDRA-2388.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-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=13056546#comment-13056546 ] Jonathan Ellis commented on CASSANDRA-2388: --- bq. CFRR's local node is the right and only node worth sorting against, it being the task tracker node. Right. bq. Then it is a random c* node that becomes the local node We still want to sort by proxmity-to-TT, because CFRR connects directly to the split owner to do the reads. initialAddress isn't involved post-split-discovery. Again, all the complexity goes away if we just embed the snitch into CFIF/TT. One wrinkle: ec2snitch requires gossip, so TT would need a separate local ip to participate in the gossip ring. We could make that optional (and fall back to old recognize local data, otherwise you get a random replica behavior otherwise). 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 Affects Versions: 0.7.6, 0.8.0 Reporter: Eldon Stegall Assignee: Jeremy Hanna Labels: hadoop, inputformat Fix For: 0.7.7, 0.8.2 Attachments: 0002_On_TException_try_next_split.patch, CASSANDRA-2388.patch, CASSANDRA-2388.patch, CASSANDRA-2388.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 ] Mck SembWever updated CASSANDRA-2388: - Attachment: CASSANDRA-2388-addition1.patch Simplify CFRR now that multiple initialAddresses are supported. 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 Affects Versions: 0.7.6, 0.8.0 Reporter: Eldon Stegall Assignee: Jeremy Hanna Labels: hadoop, inputformat Fix For: 0.7.7, 0.8.2 Attachments: 0002_On_TException_try_next_split.patch, CASSANDRA-2388-addition1.patch, CASSANDRA-2388.patch, CASSANDRA-2388.patch, CASSANDRA-2388.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-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=13056556#comment-13056556 ] Jonathan Ellis commented on CASSANDRA-2388: --- Taking a step back: aren't we optimizing for (1) a corner case with (2) the wrong solution? Here's what I mean: 1) CFRR already prioritizes the local replica. So if you have = one TT for each replica, this only helps if the local C* node dies, BUT the TT does not. This doesn't happen often. 2) If we ARE in that situation, the right solution would be to send the job to a TT whose local replica IS live, not to read the data from a nonlocal replica. How can we signal that? 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 Affects Versions: 0.7.6, 0.8.0 Reporter: Eldon Stegall Assignee: Jeremy Hanna Labels: hadoop, inputformat Fix For: 0.7.7, 0.8.2 Attachments: 0002_On_TException_try_next_split.patch, CASSANDRA-2388-addition1.patch, CASSANDRA-2388.patch, CASSANDRA-2388.patch, CASSANDRA-2388.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-2653) index scan errors out when zero columns are requested
[
https://issues.apache.org/jira/browse/CASSANDRA-2653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056567#comment-13056567
]
Jonathan Ellis commented on CASSANDRA-2653:
---
+1
index scan errors out when zero columns are requested
-
Key: CASSANDRA-2653
URL: https://issues.apache.org/jira/browse/CASSANDRA-2653
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.7.6, 0.8.0 beta 2
Reporter: Jonathan Ellis
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 0.7.7, 0.8.1
Attachments:
0001-Handle-data-get-returning-null-in-secondary-indexes.patch,
0001-Handle-null-returns-in-data-index-query-v0.7.patch,
0001-Reset-SSTII-in-EchoedRow-constructor.patch, 2653_v2.patch,
2653_v3.patch, v1-0001-CASSANDRA-2653-reproduce-regression.txt
As reported by Tyler Hobbs as an addendum to CASSANDRA-2401,
{noformat}
ERROR 16:13:38,864 Fatal exception in thread Thread[ReadStage:16,5,main]
java.lang.AssertionError: No data found for
SliceQueryFilter(start=java.nio.HeapByteBuffer[pos=10 lim=10 cap=30],
finish=java.nio.HeapByteBuffer[pos=17 lim=17 cap=30], reversed=false,
count=0] in DecoratedKey(81509516161424251288255223397843705139,
6b657931):QueryPath(columnFamilyName='cf', superColumnName='null',
columnName='null') (original filter
SliceQueryFilter(start=java.nio.HeapByteBuffer[pos=10 lim=10 cap=30],
finish=java.nio.HeapByteBuffer[pos=17 lim=17 cap=30], reversed=false,
count=0]) from expression 'cf.626972746864617465 EQ 1'
at
org.apache.cassandra.db.ColumnFamilyStore.scan(ColumnFamilyStore.java:1517)
at
org.apache.cassandra.service.IndexScanVerbHandler.doVerb(IndexScanVerbHandler.java:42)
at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:72)
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)
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2653) index scan errors out when zero columns are requested
[
https://issues.apache.org/jira/browse/CASSANDRA-2653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-2653:
--
Fix Version/s: (was: 0.8.1)
0.8.2
index scan errors out when zero columns are requested
-
Key: CASSANDRA-2653
URL: https://issues.apache.org/jira/browse/CASSANDRA-2653
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.7.6, 0.8.0 beta 2
Reporter: Jonathan Ellis
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 0.7.7, 0.8.2
Attachments:
0001-Handle-data-get-returning-null-in-secondary-indexes.patch,
0001-Handle-null-returns-in-data-index-query-v0.7.patch,
0001-Reset-SSTII-in-EchoedRow-constructor.patch, 2653_v2.patch,
2653_v3.patch, v1-0001-CASSANDRA-2653-reproduce-regression.txt
As reported by Tyler Hobbs as an addendum to CASSANDRA-2401,
{noformat}
ERROR 16:13:38,864 Fatal exception in thread Thread[ReadStage:16,5,main]
java.lang.AssertionError: No data found for
SliceQueryFilter(start=java.nio.HeapByteBuffer[pos=10 lim=10 cap=30],
finish=java.nio.HeapByteBuffer[pos=17 lim=17 cap=30], reversed=false,
count=0] in DecoratedKey(81509516161424251288255223397843705139,
6b657931):QueryPath(columnFamilyName='cf', superColumnName='null',
columnName='null') (original filter
SliceQueryFilter(start=java.nio.HeapByteBuffer[pos=10 lim=10 cap=30],
finish=java.nio.HeapByteBuffer[pos=17 lim=17 cap=30], reversed=false,
count=0]) from expression 'cf.626972746864617465 EQ 1'
at
org.apache.cassandra.db.ColumnFamilyStore.scan(ColumnFamilyStore.java:1517)
at
org.apache.cassandra.service.IndexScanVerbHandler.doVerb(IndexScanVerbHandler.java:42)
at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:72)
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)
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1140691 - in /cassandra/site: publish/download/index.html publish/index.html src/settings.py
Author: slebresne
Date: Tue Jun 28 15:51:35 2011
New Revision: 1140691
URL: http://svn.apache.org/viewvc?rev=1140691view=rev
Log:
Update web site for 0.8.1 release
Modified:
cassandra/site/publish/download/index.html
cassandra/site/publish/index.html
cassandra/site/src/settings.py
Modified: cassandra/site/publish/download/index.html
URL:
http://svn.apache.org/viewvc/cassandra/site/publish/download/index.html?rev=1140691r1=1140690r2=1140691view=diff
==
--- cassandra/site/publish/download/index.html (original)
+++ cassandra/site/publish/download/index.html Tue Jun 28 15:51:35 2011
@@ -73,31 +73,31 @@
p
- The latest stable release of Apache Cassandra is 0.8.0
- (released on 2011-06-02). iIf you're just
+ The latest stable release of Apache Cassandra is 0.8.1
+ (released on 2011-06-28). iIf you're just
starting out, download this one./i
/p
ul
li
a class=filename
-
href=http://www.apache.org/dyn/closer.cgi?path=/cassandra/0.8.0/apache-cassandra-0.8.0-bin.tar.gz;
+
href=http://www.apache.org/dyn/closer.cgi?path=/cassandra/0.8.1/apache-cassandra-0.8.1-bin.tar.gz;
onclick=javascript:
pageTracker._trackPageview('/clicks/binary_download');
- apache-cassandra-0.8.0-bin.tar.gz
+ apache-cassandra-0.8.1-bin.tar.gz
/a
-[a
href=http://www.apache.org/dist/cassandra/0.8.0/apache-cassandra-0.8.0-bin.tar.gz.asc;PGP/a]
-[a
href=http://www.apache.org/dist/cassandra/0.8.0/apache-cassandra-0.8.0-bin.tar.gz.md5;MD5/a]
-[a
href=http://www.apache.org/dist/cassandra/0.8.0/apache-cassandra-0.8.0-bin.tar.gz.sha;SHA1/a]
+[a
href=http://www.apache.org/dist/cassandra/0.8.1/apache-cassandra-0.8.1-bin.tar.gz.asc;PGP/a]
+[a
href=http://www.apache.org/dist/cassandra/0.8.1/apache-cassandra-0.8.1-bin.tar.gz.md5;MD5/a]
+[a
href=http://www.apache.org/dist/cassandra/0.8.1/apache-cassandra-0.8.1-bin.tar.gz.sha;SHA1/a]
/li
li
a class=filename
-
href=http://www.apache.org/dyn/closer.cgi?path=/cassandra/0.8.0/apache-cassandra-0.8.0-src.tar.gz;
+
href=http://www.apache.org/dyn/closer.cgi?path=/cassandra/0.8.1/apache-cassandra-0.8.1-src.tar.gz;
onclick=javascript:
pageTracker._trackPageview('/clicks/source_download');
- apache-cassandra-0.8.0-src.tar.gz
+ apache-cassandra-0.8.1-src.tar.gz
/a
-[a
href=http://www.apache.org/dist/cassandra/0.8.0/apache-cassandra-0.8.0-src.tar.gz.asc;PGP/a]
-[a
href=http://www.apache.org/dist/cassandra/0.8.0/apache-cassandra-0.8.0-src.tar.gz.md5;MD5/a]
-[a
href=http://www.apache.org/dist/cassandra/0.8.0/apache-cassandra-0.8.0-src.tar.gz.sha;SHA1/a]
+[a
href=http://www.apache.org/dist/cassandra/0.8.1/apache-cassandra-0.8.1-src.tar.gz.asc;PGP/a]
+[a
href=http://www.apache.org/dist/cassandra/0.8.1/apache-cassandra-0.8.1-src.tar.gz.md5;MD5/a]
+[a
href=http://www.apache.org/dist/cassandra/0.8.1/apache-cassandra-0.8.1-src.tar.gz.sha;SHA1/a]
/li
/ul
@@ -162,15 +162,15 @@ New users to Cassandra should be sure to
h2Download/h2
div class=inner rc
p
-The latest release is b0.8.0/b
-span class=relnotes(a
href=https://svn.apache.org/repos/asf/cassandra/tags/cassandra-0.8.0/CHANGES.txt;Changes/a)/span
+The latest release is b0.8.1/b
+span class=relnotes(a
href=https://svn.apache.org/repos/asf/cassandra/tags/cassandra-0.8.1/CHANGES.txt;Changes/a)/span
/p
p
a class=filename
-
href=http://www.apache.org/dyn/closer.cgi?path=/cassandra/0.8.0/apache-cassandra-0.8.0-bin.tar.gz;
+
href=http://www.apache.org/dyn/closer.cgi?path=/cassandra/0.8.1/apache-cassandra-0.8.1-bin.tar.gz;
onclick=javascript:
pageTracker._trackPageview('/clicks/binary_download');
- apache-cassandra-0.8.0-bin.tar.gz
+ apache-cassandra-0.8.1-bin.tar.gz
/a
/p
@@ -187,7 +187,7 @@ New users to Cassandra should be sure to
Bleeding edge development snapshots of Cassandra are available for direct
download.
/p
p
-a
href=http://hudson.zones.apache.org/hudson/job/Cassandra/lastSuccessfulBuild/artifact/cassandra/build/;Latest
Builds/a (Hudson)
+a
href=https://builds.apache.org/job/Cassandra/lastSuccessfulBuild/artifact/cassandra/build/;Latest
trunk build/a (Jenkins)
/p
h3 class=hdrArchived Releases/h3
p
Modified: cassandra/site/publish/index.html
URL:
http://svn.apache.org/viewvc/cassandra/site/publish/index.html?rev=1140691r1=1140690r2=1140691view=diff
==
--- cassandra/site/publish/index.html (original)
+++ cassandra/site/publish/index.html Tue Jun 28 15:51:35 2011
@@ -82,15 +82,15 @@
h2Download/h2
div class=inner rc
p
-The latest release is b0.8.0/b
-span class=relnotes(a
href=https://svn.apache.org/repos/asf/cassandra/tags/cassandra-0.8.0/CHANGES.txt;Changes/a)/span
+The
svn commit: r1140700 - /cassandra/tags/cassandra-0.8.1/
Author: slebresne Date: Tue Jun 28 16:09:30 2011 New Revision: 1140700 URL: http://svn.apache.org/viewvc?rev=1140700view=rev Log: Create 0.8.1 tag Added: cassandra/tags/cassandra-0.8.1/ (props changed) - copied from r1139326, cassandra/branches/cassandra-0.8.1/ Propchange: cassandra/tags/cassandra-0.8.1/ -- --- svn:ignore (added) +++ svn:ignore Tue Jun 28 16:09:30 2011 @@ -0,0 +1,8 @@ +.classpath +.project +.settings +temp-testng-customsuite.xml +build +build.properties +.idea +out Propchange: cassandra/tags/cassandra-0.8.1/ -- --- svn:mergeinfo (added) +++ svn:mergeinfo Tue Jun 28 16:09:30 2011 @@ -0,0 +1,12 @@ +/cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1131291 +/cassandra/branches/cassandra-0.7:1026516-1133874,1135638 +/cassandra/branches/cassandra-0.7.0:1053690-1055654 +/cassandra/branches/cassandra-0.8:1090934-1125013,1125041 +/cassandra/branches/cassandra-0.8.0:1125021-1130369 +/cassandra/tags/cassandra-0.7.0-rc3:1051699-1053689 +/cassandra/tags/cassandra-0.8.0-rc1:1102511-1125020 +/cassandra/trunk:1129049-1129050,1129065 +/incubator/cassandra/branches/cassandra-0.3:774578-796573 +/incubator/cassandra/branches/cassandra-0.4:810145-834239,834349-834350 +/incubator/cassandra/branches/cassandra-0.5:72-915439 +/incubator/cassandra/branches/cassandra-0.6:911237-922688
[jira] [Created] (CASSANDRA-2836) Add CFS.estimatedKeys to cfstats output
Add CFS.estimatedKeys to cfstats output --- Key: CASSANDRA-2836 URL: https://issues.apache.org/jira/browse/CASSANDRA-2836 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Brandon Williams Priority: Trivial Fix For: 0.8.2 People ask for this all the time and making them resort to the hell that is JMX is not pleasant. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2521) Move away from Phantom References for Compaction/Memtable
[ https://issues.apache.org/jira/browse/CASSANDRA-2521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056645#comment-13056645 ] Terje Marthinussen commented on CASSANDRA-2521: --- Latest iteration of this patch look great in my case, but please note again, I have not tested mmap. Maybe you can make the full GC trigger conditional if mmap is used? Only thing missing beyond that is to get this into 0.8. Disk use is very significantly improved in some cases and I think this could easily be the biggest improvement you can do in 0.8.2 in terms of operation friendliness. Regarding the above mentioned tmp tables, there is definitely issues there, but don't think it is related to this patch so feel free to merge. Move away from Phantom References for Compaction/Memtable - Key: CASSANDRA-2521 URL: https://issues.apache.org/jira/browse/CASSANDRA-2521 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Chris Goffinet Assignee: Sylvain Lebresne Fix For: 1.0 Attachments: 0001-Use-reference-counting-to-decide-when-a-sstable-can-.patch, 0001-Use-reference-counting-to-decide-when-a-sstable-can-v2.patch, 0002-Force-unmapping-files-before-deletion-v2.patch, 2521-v3.txt, 2521-v4.txt http://wiki.apache.org/cassandra/MemtableSSTable Let's move to using reference counting instead of relying on GC to be called in StorageService. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2836) Add CFS.estimatedKeys to cfstats output
[
https://issues.apache.org/jira/browse/CASSANDRA-2836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056654#comment-13056654
]
Joe Stein commented on CASSANDRA-2836:
--
so the change looks like adding something like this
{code}
outs.println(\t\tNumber of Keys (estimate): + cfstore.estimateKeys());
{code}
maybe between
{code}
outs.println(\t\tSpace used (total): + cfstore.getTotalDiskSpaceUsed());
outs.println(\t\tNumber of Keys (estimate): + cfstore.estimateKeys());
outs.println(\t\tMemtable Columns Count: +
cfstore.getMemtableColumnsCount());
{code}
makes sense
in src/java/org/apache/cassandra/tools/NodeCmd.java
Add CFS.estimatedKeys to cfstats output
---
Key: CASSANDRA-2836
URL: https://issues.apache.org/jira/browse/CASSANDRA-2836
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Brandon Williams
Priority: Trivial
Fix For: 0.8.2
People ask for this all the time and making them resort to the hell that is
JMX is not pleasant.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2802) Enable encryption for data across the DC only.
[ https://issues.apache.org/jira/browse/CASSANDRA-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2802: -- Component/s: (was: Contrib) Core Priority: Minor (was: Trivial) Affects Version/s: (was: 0.7.7) 0.7.0 Fix Version/s: (was: 0.8.1) 0.8.2 Enable encryption for data across the DC only. -- Key: CASSANDRA-2802 URL: https://issues.apache.org/jira/browse/CASSANDRA-2802 Project: Cassandra Issue Type: New Feature Components: Core Affects Versions: 0.7.0 Environment: JVM Reporter: Vijay Assignee: Vijay Priority: Minor Fix For: 0.8.2 Make DC level Encryption option 1) Modify EncryptionOptions to add inter_dc option. 2) Modify OutboundTCPConnection.connect() to check if it is in the same DC and if the encryption option is enabled. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2836) Add CFS.estimatedKeys to cfstats output
[ https://issues.apache.org/jira/browse/CASSANDRA-2836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Stein updated CASSANDRA-2836: - Attachment: 2836.txt Add CFS.estimatedKeys to cfstats output --- Key: CASSANDRA-2836 URL: https://issues.apache.org/jira/browse/CASSANDRA-2836 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Brandon Williams Priority: Trivial Fix For: 0.8.2 Attachments: 2836.txt People ask for this all the time and making them resort to the hell that is JMX is not pleasant. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-2677) Optimize streaming to be single-pass
[ https://issues.apache.org/jira/browse/CASSANDRA-2677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-2677: - Assignee: (was: Sylvain Lebresne) Optimize streaming to be single-pass Key: CASSANDRA-2677 URL: https://issues.apache.org/jira/browse/CASSANDRA-2677 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Priority: Minor Fix For: 0.8.2 Streaming currently is a two-pass operation: one to write the Data component do disk from the socket, then another to build the index and bloom filter from it. This means we do about 2x the i/o we would if we created the index and BF during the original write. For node movement this was not considered to be a Big Deal because the stream target is not a member of the ring, so we can be inefficient without hurting live queries. But optimizing node movement to not require un/rebootstrap (CASSANDRA-1427) and bulk load (CASSANDRA-1278) mean we can stream to live nodes too. The main obstacle here is we don't know how many keys will be in the new sstable ahead of time, which we need to size the bloom filter correctly. We can solve this by including that information (or a close approximation) in the stream setup -- the source node can calculate that without hitting disk from the in-memory index summary. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-2034) Make Read Repair unnecessary when Hinted Handoff is enabled
[ https://issues.apache.org/jira/browse/CASSANDRA-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-2034: - Assignee: Patricio Echague (was: Sylvain Lebresne) Make Read Repair unnecessary when Hinted Handoff is enabled --- Key: CASSANDRA-2034 URL: https://issues.apache.org/jira/browse/CASSANDRA-2034 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Assignee: Patricio Echague Fix For: 1.0 Original Estimate: 8h Remaining Estimate: 8h Currently, HH is purely an optimization -- if a machine goes down, enabling HH means RR/AES will have less work to do, but you can't disable RR entirely in most situations since HH doesn't kick in until the FailureDetector does. Let's add a scheduled task to the mutate path, such that we return to the client normally after ConsistencyLevel is achieved, but after RpcTimeout we check the responseHandler write acks and write local hints for any missing targets. This would making disabling RR when HH is enabled a much more reasonable option, which has a huge impact on read throughput. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2506) Push read repair setting down to the DC-level
[ https://issues.apache.org/jira/browse/CASSANDRA-2506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2506: -- Assignee: Patricio Echague (was: Brandon Williams) Push read repair setting down to the DC-level - Key: CASSANDRA-2506 URL: https://issues.apache.org/jira/browse/CASSANDRA-2506 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Brandon Williams Assignee: Patricio Echague Fix For: 1.0 Currently, read repair is a global setting. However, when you have two DCs and use one for analytics, it would be nice to turn it off only for that DC so the live DC serving the application can still benefit from it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1140751 - in /cassandra/branches/cassandra-0.8: ./ contrib/ interface/thrift/gen-java/org/apache/cassandra/thrift/ src/java/org/apache/cassandra/gms/ src/java/org/apache/cassandra/net/
Author: jbellis Date: Tue Jun 28 17:50:43 2011 New Revision: 1140751 URL: http://svn.apache.org/viewvc?rev=1140751view=rev Log: fix Message version propagation fromold nodes to new ones patch by brandonwilliams and jbellis for CASSANDRA-2818 Modified: cassandra/branches/cassandra-0.8/ (props changed) cassandra/branches/cassandra-0.8/contrib/ (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/NotFoundException.java (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/SuperColumn.java (props changed) cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/gms/Gossiper.java cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/net/IncomingTcpConnection.java Propchange: cassandra/branches/cassandra-0.8/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Tue Jun 28 17:50:43 2011 @@ -1,5 +1,5 @@ /cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1131291 -/cassandra/branches/cassandra-0.7:1026516-1140565 +/cassandra/branches/cassandra-0.7:1026516-1140567 /cassandra/branches/cassandra-0.7.0:1053690-1055654 /cassandra/branches/cassandra-0.8:1090934-1125013,1125041 /cassandra/branches/cassandra-0.8.0:1125021-1130369 Propchange: cassandra/branches/cassandra-0.8/contrib/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Tue Jun 28 17:50:43 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-1140565 +/cassandra/branches/cassandra-0.7/contrib:1026516-1140567 /cassandra/branches/cassandra-0.7.0/contrib:1053690-1055654 /cassandra/branches/cassandra-0.8/contrib:1090934-1125013,1125041 /cassandra/branches/cassandra-0.8.0/contrib:1125021-1130369 Propchange: cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Tue Jun 28 17:50:43 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-1131291 -/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1140565 +/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1140567 /cassandra/branches/cassandra-0.7.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1053690-1055654 /cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1090934-1125013,1125041 /cassandra/branches/cassandra-0.8.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1125021-1130369 Propchange: cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Tue Jun 28 17:50:43 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-1131291 -/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1026516-1140565 +/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1026516-1140567 /cassandra/branches/cassandra-0.7.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1053690-1055654 /cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1090934-1125013,1125041 /cassandra/branches/cassandra-0.8.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1125021-1130369 Propchange: cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Tue Jun 28 17:50:43 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-1131291
[jira] [Resolved] (CASSANDRA-2818) 0.8.0 is unable to participate with nodes using a _newer_ protocol version
[ https://issues.apache.org/jira/browse/CASSANDRA-2818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-2818. --- Resolution: Fixed committed 0.8.0 is unable to participate with nodes using a _newer_ protocol version -- Key: CASSANDRA-2818 URL: https://issues.apache.org/jira/browse/CASSANDRA-2818 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.0 Reporter: Michael Allen Assignee: Brandon Williams Priority: Minor Fix For: 0.8.2 Attachments: 2818-disconnect.txt, 2818-v2.txt, 2818-v3.txt, 2818-v4.txt, 2818.txt When a 0.8.1 node tries to join a 0.8.0 ring, we see an endless supply of these in system.log: INFO [Thread-4] 2011-06-23 21:14:04,149 IncomingTcpConnection.java (line 103) Received connection from newer protocol version. Ignorning message. and the node never joins the ring. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1140759 - /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/tools/NodeCmd.java
Author: brandonwilliams Date: Tue Jun 28 17:59:17 2011 New Revision: 1140759 URL: http://svn.apache.org/viewvc?rev=1140759view=rev Log: Add CFS.estimatedKeys to cfstats output. Patch by Joe Stein, reviewed by brandonwilliams for CASSANDRA-2836 Modified: cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/tools/NodeCmd.java Modified: cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/tools/NodeCmd.java URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/tools/NodeCmd.java?rev=1140759r1=1140758r2=1140759view=diff == --- cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/tools/NodeCmd.java (original) +++ cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/tools/NodeCmd.java Tue Jun 28 17:59:17 2011 @@ -445,6 +445,7 @@ public class NodeCmd outs.println(\t\tSSTable count: + cfstore.getLiveSSTableCount()); outs.println(\t\tSpace used (live): + cfstore.getLiveDiskSpaceUsed()); outs.println(\t\tSpace used (total): + cfstore.getTotalDiskSpaceUsed()); +outs.println(\t\tNumber of Keys (estimate): + cfstore.estimateKeys()); outs.println(\t\tMemtable Columns Count: + cfstore.getMemtableColumnsCount()); outs.println(\t\tMemtable Data Size: + cfstore.getMemtableDataSize()); outs.println(\t\tMemtable Switch Count: + cfstore.getMemtableSwitchCount());
svn commit: r1140760 - in /cassandra/branches/cassandra-0.8: ./ src/java/org/apache/cassandra/db/ src/java/org/apache/cassandra/net/ src/java/org/apache/cassandra/service/ src/java/org/apache/cassandr
Author: jbellis
Date: Tue Jun 28 17:59:21 2011
New Revision: 1140760
URL: http://svn.apache.org/viewvc?rev=1140760view=rev
Log:
revert r1133167 (#2280)
Modified:
cassandra/branches/cassandra-0.8/CHANGES.txt
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/Table.java
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/net/MessagingService.java
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/AntiEntropyService.java
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/StorageService.java
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/streaming/StreamIn.java
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/streaming/StreamOut.java
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/streaming/StreamRequestMessage.java
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/streaming/StreamRequestVerbHandler.java
cassandra/branches/cassandra-0.8/test/unit/org/apache/cassandra/streaming/SerializationsTest.java
cassandra/branches/cassandra-0.8/test/unit/org/apache/cassandra/streaming/StreamingTransferTest.java
Modified: cassandra/branches/cassandra-0.8/CHANGES.txt
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/CHANGES.txt?rev=1140760r1=1140759r2=1140760view=diff
==
--- cassandra/branches/cassandra-0.8/CHANGES.txt (original)
+++ cassandra/branches/cassandra-0.8/CHANGES.txt Tue Jun 28 17:59:21 2011
@@ -50,14 +50,12 @@
* throttle migration replay (CASSANDRA-2714)
* optimize column serializer creation (CASSANDRA-2716)
* Added support for making bootstrap retry if nodes flap (CASSANDRA-2644)
- * Added statusthrift to nodetool to report if thrift server is running
- (CASSANDRA-2722)
+ * Added statusthrift to nodetool to report if thrift server is running
(CASSANDRA-2722)
* Fixed rows being cached if they do not exist (CASSANDRA-2723)
* fix truncate/compaction race (CASSANDRA-2673)
* Support passing tableName and cfName to RowCacheProviders (CASSANDRA-2702)
* workaround large resultsets causing large allocation retention
by nio sockets (CASSANDRA-2654)
- * restrict repair streaming to specific columnfamilies (CASSANDRA-2280)
* fix nodetool ring use with Ec2Snitch (CASSANDRA-2733)
* fix inconsistency window during bootstrap (CASSANDRA-833)
* fix removing columns and subcolumns that are supressed by a row or
Modified:
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/Table.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/Table.java?rev=1140760r1=1140759r2=1140760view=diff
==
---
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/Table.java
(original)
+++
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/Table.java
Tue Jun 28 17:59:21 2011
@@ -253,7 +253,7 @@ public class Table
}
/**
- * @return A list of open SSTableReaders
+ * @return A list of open SSTableReaders (TODO: ensure that the caller
doesn't modify these).
*/
public ListSSTableReader getAllSSTables()
{
Modified:
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/net/MessagingService.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/net/MessagingService.java?rev=1140760r1=1140759r2=1140760view=diff
==
---
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/net/MessagingService.java
(original)
+++
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/net/MessagingService.java
Tue Jun 28 17:59:21 2011
@@ -58,9 +58,7 @@ import org.cliffc.high_scale_lib.NonBloc
public final class MessagingService implements MessagingServiceMBean
{
public static final int VERSION_07 = 1;
-public static final int VERSION_080 = 2;
-public static final int version_ = 81;
-
+public static final int version_ = 2;
//TODO: make this parameter dynamic somehow. Not sure if config is
appropriate.
private SerializerType serializerType_ = SerializerType.BINARY;
Modified:
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/AntiEntropyService.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/AntiEntropyService.java?rev=1140760r1=1140759r2=1140760view=diff
==
---
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/AntiEntropyService.java
(original)
+++
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/AntiEntropyService.java
Tue Jun 28 17:59:21 2011
@@ -494,7 +494,7 @@ public class
svn commit: r1140762 - in /cassandra/trunk: ./ contrib/ interface/thrift/gen-java/org/apache/cassandra/thrift/ src/java/org/apache/cassandra/net/
Author: jbellis Date: Tue Jun 28 18:00:30 2011 New Revision: 1140762 URL: http://svn.apache.org/viewvc?rev=1140762view=rev Log: merge from 0.8 Modified: cassandra/trunk/ (props changed) cassandra/trunk/CHANGES.txt cassandra/trunk/contrib/ (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/NotFoundException.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/SuperColumn.java (props changed) cassandra/trunk/src/java/org/apache/cassandra/net/MessagingService.java Propchange: cassandra/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Tue Jun 28 18:00:30 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1131291 /cassandra/branches/cassandra-0.7:1026516-1140567 /cassandra/branches/cassandra-0.7.0:1053690-1055654 -/cassandra/branches/cassandra-0.8:1090934-1125013,1125019-1140755 +/cassandra/branches/cassandra-0.8:1090934-1125013,1125019-1140755,1140760 /cassandra/branches/cassandra-0.8.0:1125021-1130369 /cassandra/branches/cassandra-0.8.1:1101014-1125018 /cassandra/tags/cassandra-0.7.0-rc3:1051699-1053689 Modified: cassandra/trunk/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/trunk/CHANGES.txt?rev=1140762r1=1140761r2=1140762view=diff == --- cassandra/trunk/CHANGES.txt (original) +++ cassandra/trunk/CHANGES.txt Tue Jun 28 18:00:30 2011 @@ -7,6 +7,7 @@ (CASSANDRA-2062) * Fixed the ability to set compaction strategy in cli using create column family command (CASSANDRA-2778) * clean up tmp files after failed compaction (CASSANDRA-2468) + * restrict repair streaming to specific columnfamilies (CASSANDRA-2280) 0.8.2 @@ -71,7 +72,6 @@ * fix truncate/compaction race (CASSANDRA-2673) * workaround large resultsets causing large allocation retention by nio sockets (CASSANDRA-2654) - * restrict repair streaming to specific columnfamilies (CASSANDRA-2280) * fix nodetool ring use with Ec2Snitch (CASSANDRA-2733) * fix inconsistency window during bootstrap (CASSANDRA-833) * fix removing columns and subcolumns that are supressed by a row or Propchange: cassandra/trunk/contrib/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Tue Jun 28 18:00:30 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6/contrib:922689-1052356,1052358-1053452,1053454,1053456-1068009 /cassandra/branches/cassandra-0.7/contrib:1026516-1140567 /cassandra/branches/cassandra-0.7.0/contrib:1053690-1055654 -/cassandra/branches/cassandra-0.8/contrib:1090934-1125013,1125019-1140755 +/cassandra/branches/cassandra-0.8/contrib:1090934-1125013,1125019-1140755,1140760 /cassandra/branches/cassandra-0.8.0/contrib:1125021-1130369 /cassandra/branches/cassandra-0.8.1/contrib:1101014-1125018 /cassandra/tags/cassandra-0.7.0-rc3/contrib:1051699-1053689 Propchange: cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Tue Jun 28 18:00:30 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:922689-1052356,1052358-1053452,1053454,1053456-1131291 /cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1140567 /cassandra/branches/cassandra-0.7.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1053690-1055654 -/cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1090934-1125013,1125019-1140755 +/cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1090934-1125013,1125019-1140755,1140760 /cassandra/branches/cassandra-0.8.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1125021-1130369 /cassandra/branches/cassandra-0.8.1/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1101014-1125018 /cassandra/tags/cassandra-0.7.0-rc3/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1051699-1053689 Propchange: cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Tue Jun 28 18:00:30 2011 @@
[jira] [Updated] (CASSANDRA-2280) Request specific column families using StreamIn
[ https://issues.apache.org/jira/browse/CASSANDRA-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2280: -- Fix Version/s: (was: 0.8.2) 1.0 Reverted from 0.8 b/c of CASSANDRA-2818. Request specific column families using StreamIn --- Key: CASSANDRA-2280 URL: https://issues.apache.org/jira/browse/CASSANDRA-2280 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Stu Hood Assignee: Jonathan Ellis Fix For: 1.0 Attachments: 0001-Allow-specific-column-families-to-be-requested-for-str.txt, 0001-Allow-specific-column-families-to-be-requested-for-str.txt, 2280-v3.txt, 2280-v4.txt, 2280-v5.txt StreamIn.requestRanges only specifies a keyspace, meaning that requesting a range will request it for all column families: if you have a large number of CFs, this can cause quite a headache. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-2836) Add CFS.estimatedKeys to cfstats output
[ https://issues.apache.org/jira/browse/CASSANDRA-2836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-2836. - Resolution: Fixed Committed, thanks! Add CFS.estimatedKeys to cfstats output --- Key: CASSANDRA-2836 URL: https://issues.apache.org/jira/browse/CASSANDRA-2836 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Brandon Williams Assignee: Joe Stein Priority: Trivial Fix For: 0.8.2 Attachments: 2836.txt People ask for this all the time and making them resort to the hell that is JMX is not pleasant. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-2836) Add CFS.estimatedKeys to cfstats output
[ https://issues.apache.org/jira/browse/CASSANDRA-2836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams reassigned CASSANDRA-2836: --- Assignee: Joe Stein Add CFS.estimatedKeys to cfstats output --- Key: CASSANDRA-2836 URL: https://issues.apache.org/jira/browse/CASSANDRA-2836 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Brandon Williams Assignee: Joe Stein Priority: Trivial Fix For: 0.8.2 Attachments: 2836.txt People ask for this all the time and making them resort to the hell that is JMX is not pleasant. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2491) A new config parameter, broadcast_address
[ https://issues.apache.org/jira/browse/CASSANDRA-2491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056682#comment-13056682 ] Brandon Williams commented on CASSANDRA-2491: - This looks good, but now I'm getting a patch error: patch: malformed patch at line 198: Index: src/java/org/apache/cassandra/db/HintedHandOffManager.java A new config parameter, broadcast_address - Key: CASSANDRA-2491 URL: https://issues.apache.org/jira/browse/CASSANDRA-2491 Project: Cassandra Issue Type: Improvement Components: Core Environment: x86_64 GNU/Linux Reporter: Khee Chin Assignee: Khee Chin Priority: Trivial Labels: patch Fix For: 1.0 Attachments: 2491_broadcast_address.patch, 2491_broadcast_address_v2.patch, 2491_broadcast_address_v3.patch, 2491_broadcast_address_v4.patch, 2491_broadcast_address_v5.patch, 2491_broadcast_address_v6.patch Original Estimate: 336h Remaining Estimate: 336h A new config parameter, broadcast_address In a cluster setup where one or more nodes is behind a firewall and has a private ip address, listen_address does not allow the hosts behind the firewalls to be discovered by other nodes. Attached is a patch that introduces a new config parameter broadcast_address which allows Cassandra nodes to explicitly specify their external ip address. In addition, this allows listen_address to be set to 0.0.0.0 on the already firewalled node. broadcast_address fallsback to listen_address when it is not stated. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2837) Setting RR Chance via CliClient results in chance being too low
Setting RR Chance via CliClient results in chance being too low
Key: CASSANDRA-2837
URL: https://issues.apache.org/jira/browse/CASSANDRA-2837
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.7.6
Reporter: Bill de hOra
running a command like
{noformat}
update column family shorturls with read_repair_chance=0.4;
{noformat}
results in the value being set to 0.0040.
Affects 0.7.6.-2; seems to be fixed on trunk/0.8.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-2837) Setting RR Chance via CliClient results in chance being too low
[
https://issues.apache.org/jira/browse/CASSANDRA-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Hermes reassigned CASSANDRA-2837:
-
Assignee: Jon Hermes
Setting RR Chance via CliClient results in chance being too low
Key: CASSANDRA-2837
URL: https://issues.apache.org/jira/browse/CASSANDRA-2837
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.7.6
Reporter: Bill de hOra
Assignee: Jon Hermes
running a command like
{noformat}
update column family shorturls with read_repair_chance=0.4;
{noformat}
results in the value being set to 0.0040.
Affects 0.7.6.-2; seems to be fixed on trunk/0.8.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2837) Setting RR Chance via CliClient results in chance being too low
[
https://issues.apache.org/jira/browse/CASSANDRA-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill de hOra updated CASSANDRA-2837:
Description:
running a command like
{noformat}
update column family shorturls with read_repair_chance=0.4;
{noformat}
results in the value being set to 0.0040. Was expecting it to be 0.4.
Affects 0.7.6.-2; seems to be fixed on trunk/0.8.
was:
running a command like
{noformat}
update column family shorturls with read_repair_chance=0.4;
{noformat}
results in the value being set to 0.0040.
Affects 0.7.6.-2; seems to be fixed on trunk/0.8.
Assignee: (was: Jon Hermes)
Setting RR Chance via CliClient results in chance being too low
Key: CASSANDRA-2837
URL: https://issues.apache.org/jira/browse/CASSANDRA-2837
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.7.6
Reporter: Bill de hOra
running a command like
{noformat}
update column family shorturls with read_repair_chance=0.4;
{noformat}
results in the value being set to 0.0040. Was expecting it to be 0.4.
Affects 0.7.6.-2; seems to be fixed on trunk/0.8.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2837) Setting RR Chance via CliClient results in chance being too low
[
https://issues.apache.org/jira/browse/CASSANDRA-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Hermes updated CASSANDRA-2837:
--
Attachment: 2837.txt
Straightforward patch.
If the help says it expects a double from 0.0 to 1.0, it shouldn't then divide
by 100 as if expecting a percentage.
Setting RR Chance via CliClient results in chance being too low
Key: CASSANDRA-2837
URL: https://issues.apache.org/jira/browse/CASSANDRA-2837
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.7.6
Reporter: Bill de hOra
Fix For: 0.7.7
Attachments: 2837.txt
running a command like
{noformat}
update column family shorturls with read_repair_chance=0.4;
{noformat}
results in the value being set to 0.0040. Was expecting it to be 0.4.
Affects 0.7.6.-2; seems to be fixed on trunk/0.8.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-2837) Setting RR Chance via CliClient results in chance being too low
[
https://issues.apache.org/jira/browse/CASSANDRA-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Hermes reassigned CASSANDRA-2837:
-
Assignee: Jon Hermes
Setting RR Chance via CliClient results in chance being too low
Key: CASSANDRA-2837
URL: https://issues.apache.org/jira/browse/CASSANDRA-2837
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.7.6
Reporter: Bill de hOra
Assignee: Jon Hermes
Priority: Minor
Fix For: 0.7.7
Attachments: 2837.txt
running a command like
{noformat}
update column family shorturls with read_repair_chance=0.4;
{noformat}
results in the value being set to 0.0040. Was expecting it to be 0.4.
Affects 0.7.6.-2; seems to be fixed on trunk/0.8.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2837) Setting RR Chance via CliClient results in chance being too low
[
https://issues.apache.org/jira/browse/CASSANDRA-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Hermes updated CASSANDRA-2837:
--
Priority: Minor (was: Major)
Fix Version/s: 0.7.7
Setting RR Chance via CliClient results in chance being too low
Key: CASSANDRA-2837
URL: https://issues.apache.org/jira/browse/CASSANDRA-2837
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.7.6
Reporter: Bill de hOra
Priority: Minor
Fix For: 0.7.7
Attachments: 2837.txt
running a command like
{noformat}
update column family shorturls with read_repair_chance=0.4;
{noformat}
results in the value being set to 0.0040. Was expecting it to be 0.4.
Affects 0.7.6.-2; seems to be fixed on trunk/0.8.
--
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=13056787#comment-13056787 ] Brandon Williams commented on CASSANDRA-2388: - bq. If we ARE in that situation, the right solution would be to send the job to a TT whose local replica IS live, not to read the data from a nonlocal replica. How can we signal that? ISTM the right thing to do in that situation is just fail and let the JT reschedule somewhere else. 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 Affects Versions: 0.7.6, 0.8.0 Reporter: Eldon Stegall Assignee: Jeremy Hanna Labels: hadoop, inputformat Fix For: 0.7.7, 0.8.2 Attachments: 0002_On_TException_try_next_split.patch, CASSANDRA-2388-addition1.patch, CASSANDRA-2388.patch, CASSANDRA-2388.patch, CASSANDRA-2388.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-2383) log4j unable to load properties file from classpath
[
https://issues.apache.org/jira/browse/CASSANDRA-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056794#comment-13056794
]
David Allsopp commented on CASSANDRA-2383:
--
OK, have gone around in circles a bit on this!
-Dlog4j.defaultInitOverride enables AbstractCassandraDaemon to take charge of
the log4j configuration in order to make it dynamic (you can change the log4j
config file, and it should be updated using the log4j PropertyConfigurator
every 10 seconds).
The default value of log4j.configuration in the code and in the batch file is
log4j-server.properties, which is not a valid URL, so we drop into:
{noformat}
configLocation =
AbstractCassandraDaemon.class.getClassLoader().getResource(config);
{noformat}
as you said before. This *does* detect the correct file from
CASSANDRA_HOME/conf, since log4j logs the *full path* even though we only
supply the filename log4j-server.properties:
{noformat}
log4j:
[/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.properties]
does not exist.
{noformat}
getResource() returns a URL. Converting this to a file using getFile() works
fine when there are no spaces, and you can verify that the file exists. If
there are spaces, then this conversion produces a filename that includes the
%20 encoding for spaces - this is an incorrect filename.
We need instead to convert using:
{noformat}
new File(configLocation.toURI());
{noformat}
(with appropriate exception handling for URISyntaxException) which produces a
filename with spaces rather than %20.
log4j unable to load properties file from classpath
---
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: T Jake Luciani
Priority: Minor
Fix For: 0.7.7
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] [Issue Comment Edited] (CASSANDRA-2383) log4j unable to load properties file from classpath
[
https://issues.apache.org/jira/browse/CASSANDRA-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056794#comment-13056794
]
David Allsopp edited comment on CASSANDRA-2383 at 6/28/11 9:24 PM:
---
OK, have gone around in circles a bit on this!
-Dlog4j.defaultInitOverride enables AbstractCassandraDaemon to take charge of
the log4j configuration in order to make it dynamic (you can change the log4j
config file, and it should be updated using the log4j PropertyConfigurator
every 10 seconds).
The default value of log4j.configuration in the code and in the batch file is
log4j-server.properties, which is not a valid URL, so we drop into:
{noformat} configLocation =
AbstractCassandraDaemon.class.getClassLoader().getResource(config);{noformat}
as you said before. This *does* detect the correct file from
CASSANDRA_HOME/conf, since log4j logs the *full path* even though we only
supply the filename log4j-server.properties:
{noformat} log4j:
[/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.properties]
does not exist.{noformat}
getResource() returns a URL. Converting this to a file using getFile() works
fine when there are no spaces; one can verify that the file exists
(File.exists() == true). If there are spaces, then this conversion produces a
filename that includes the %20 encoding for spaces - this is an incorrect
filename.
We need instead to convert using:
{noformat} new File(configLocation.toURI());{noformat}
(with appropriate exception handling for URISyntaxException) which produces a
filename with spaces rather than %20.
was (Author: dallsopp):
OK, have gone around in circles a bit on this!
-Dlog4j.defaultInitOverride enables AbstractCassandraDaemon to take charge of
the log4j configuration in order to make it dynamic (you can change the log4j
config file, and it should be updated using the log4j PropertyConfigurator
every 10 seconds).
The default value of log4j.configuration in the code and in the batch file is
log4j-server.properties, which is not a valid URL, so we drop into:
{noformat}
configLocation =
AbstractCassandraDaemon.class.getClassLoader().getResource(config);
{noformat}
as you said before. This *does* detect the correct file from
CASSANDRA_HOME/conf, since log4j logs the *full path* even though we only
supply the filename log4j-server.properties:
{noformat}
log4j:
[/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.properties]
does not exist.
{noformat}
getResource() returns a URL. Converting this to a file using getFile() works
fine when there are no spaces, and you can verify that the file exists. If
there are spaces, then this conversion produces a filename that includes the
%20 encoding for spaces - this is an incorrect filename.
We need instead to convert using:
{noformat}
new File(configLocation.toURI());
{noformat}
(with appropriate exception handling for URISyntaxException) which produces a
filename with spaces rather than %20.
log4j unable to load properties file from classpath
---
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: T Jake Luciani
Priority: Minor
Fix For: 0.7.7
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-2836) Add CFS.estimatedKeys to cfstats output
[ https://issues.apache.org/jira/browse/CASSANDRA-2836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056799#comment-13056799 ] Hudson commented on CASSANDRA-2836: --- Integrated in Cassandra-0.8 #197 (See [https://builds.apache.org/job/Cassandra-0.8/197/]) Add CFS.estimatedKeys to cfstats output. Patch by Joe Stein, reviewed by brandonwilliams for CASSANDRA-2836 brandonwilliams : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1140759 Files : * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/tools/NodeCmd.java Add CFS.estimatedKeys to cfstats output --- Key: CASSANDRA-2836 URL: https://issues.apache.org/jira/browse/CASSANDRA-2836 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Brandon Williams Assignee: Joe Stein Priority: Trivial Fix For: 0.8.2 Attachments: 2836.txt People ask for this all the time and making them resort to the hell that is JMX is not pleasant. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2835) CFMetadata don't set the default for Replicate_on_write correctly
[ https://issues.apache.org/jira/browse/CASSANDRA-2835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056798#comment-13056798 ] Hudson commented on CASSANDRA-2835: --- Integrated in Cassandra-0.8 #197 (See [https://builds.apache.org/job/Cassandra-0.8/197/]) CFMetadata don't set the default for Replicate_on_write correctly -- Key: CASSANDRA-2835 URL: https://issues.apache.org/jira/browse/CASSANDRA-2835 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.0 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Labels: counters Fix For: 0.8.2 Attachments: 2835.patch Replicate_on_write *must* default to true (defaulting to false is very dangerous and imho, the option of setting it to false shouldn't exist in the first place) and CFMetadata.DEFAULT_REPLICATE_ON_WRITE is correctly true. But it doesn't get set correctly. Instead, the code force the value of the cf_def even if it wasn't defined, resulting in setting it to false since that is the default value for a boolean in JAVA. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2383) log4j unable to load properties file from classpath
[
https://issues.apache.org/jira/browse/CASSANDRA-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056826#comment-13056826
]
David Allsopp commented on CASSANDRA-2383:
--
Suggested fix for AbstractCassandraDaemon static initializer (apologies -
haven't got a suitable version of diff on this windows box yet). Untested on
linux as yet.
{noformat}
//Initialize logging in such a way that it checks for config changes every
10 seconds.
static
{
String config = System.getProperty(log4j.configuration,
log4j-server.properties);
String configFileName = null;
URL configLocation = null;
try
{
// try loading from a physical location first.
configLocation = new URL(config);
}
catch (MalformedURLException ex)
{
// load from the classpath.
configLocation =
AbstractCassandraDaemon.class.getClassLoader().getResource(config);
if (configLocation == null)
throw new RuntimeException(Couldn't figure out log4j
configuration.);
try
{
configFileName = new
File(configLocation.toURI()).getCanonicalPath();
}
catch (Exception e)
{
throw new RuntimeException(Couldn't convert
log4j configuration location to a valid file., e);
}
}
PropertyConfigurator.configureAndWatch(configFileName, 1);
org.apache.log4j.Logger.getLogger(AbstractCassandraDaemon.class).info(Logging
initialized);
}
{noformat}
log4j unable to load properties file from classpath
---
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: T Jake Luciani
Priority: Minor
Fix For: 0.7.7
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-2739) Cannot recover SSTable with version f (current version g) during the node decommission.
[ https://issues.apache.org/jira/browse/CASSANDRA-2739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056873#comment-13056873 ] Brandon Williams commented on CASSANDRA-2739: - Note that this can be encountered for any streaming operation (such as repair) and isn't limited to decommission. Cannot recover SSTable with version f (current version g) during the node decommission. --- Key: CASSANDRA-2739 URL: https://issues.apache.org/jira/browse/CASSANDRA-2739 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.0 Environment: centos, cassandra 0.7.4 upgrade to 0.8.0-final. Reporter: Dikang Gu Labels: decommission, version I upgrade the 4-nodes cassandra 0.7.4 cluster to 0.8.0-final. Then, I do the bin/nodetool decommission on one node, the decommission hangs there and I got the following errors on other nodes. ERROR [Thread-55] 2011-06-03 18:02:03,500 AbstractCassandraDaemon.java (line 113) Fatal exception in thread Thread[Thread-55,5,main] java.lang.RuntimeException: Cannot recover SSTable with version f (current version g). at org.apache.cassandra.io.sstable.SSTableWriter.createBuilder(SSTableWriter.java:240) at org.apache.cassandra.db.CompactionManager.submitSSTableBuild(CompactionManager.java:1088) at org.apache.cassandra.streaming.StreamInSession.finished(StreamInSession.java:108) at org.apache.cassandra.streaming.IncomingStreamReader.readFile(IncomingStreamReader.java:104) at org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:61) at org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:155) at org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:93) ERROR [Thread-56] 2011-06-03 18:02:04,285 AbstractCassandraDaemon.java (line 113) Fatal exception in thread Thread[Thread-56,5,main] java.lang.RuntimeException: Cannot recover SSTable with version f (current version g). at org.apache.cassandra.io.sstable.SSTableWriter.createBuilder(SSTableWriter.java:240) at org.apache.cassandra.db.CompactionManager.submitSSTableBuild(CompactionManager.java:1088) at org.apache.cassandra.streaming.StreamInSession.finished(StreamInSession.java:108) at org.apache.cassandra.streaming.IncomingStreamReader.readFile(IncomingStreamReader.java:104) at org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:61) at org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:155) at org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:93) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2589) row deletes do not remove columns
[ https://issues.apache.org/jira/browse/CASSANDRA-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Morton updated CASSANDRA-2589: Attachment: 0001-remove-deleted-columns-before-flushing-memtable-v08-2.patch 0001-remove-deleted-columns-before-flushing-memtable-v07-2.patch *-2.patch adds comment // Pedantically you could purge column level tombstones that are past GCGRace when writing to the SSTable. // But it can result in unexpected behaviour where deletes never make it to disk, // as they are lost and so cannot override existing column values. So we only remove deleted columns if there // is a CF level tombstone to ensure the delete makes it into an SSTable. row deletes do not remove columns - Key: CASSANDRA-2589 URL: https://issues.apache.org/jira/browse/CASSANDRA-2589 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Aaron Morton Assignee: Aaron Morton Priority: Minor Fix For: 0.8.2 Attachments: 0001-remove-deleted-columns-before-flushing-memtable-v07-2.patch, 0001-remove-deleted-columns-before-flushing-memtable-v07.patch, 0001-remove-deleted-columns-before-flushing-memtable-v08-2.patch, 0001-remove-deleted-columns-before-flushing-memtable-v08.patch When a row delete is issued CF.delete() sets the localDeletetionTime and markedForDeleteAt values but does not remove columns which have a lower time stamp. As a result: # Memory which could be freed is held on to (prob not too bad as it's already counted) # The deleted columns are serialised to disk, along with the CF info to say they are no longer valid. # NamesQueryFilter and SliceQueryFilter have to do more work as they filter out the irrelevant columns using QueryFilter.isRelevant() # Also columns written with a lower time stamp after the deletion are added to the CF without checking markedForDeletionAt. This can cause RR to fail, will create another ticket for that and link. This ticket is for a fix to removing the columns. Two options I could think of: # Check for deletion when serialising to SSTable and ignore columns if the have a lower timestamp. Otherwise leave as is so dead columns stay in memory. # Ensure at all times if the CF is deleted all columns it contains have a higher timestamp. ## I *think* this would include all column types (DeletedColumn as well) as the CF deletion has the same effect. But not sure. ## Deleting (potentially) all columns in delete() will take time. Could track the highest timestamp in the CF so the normal case of deleting all cols does not need to iterate. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2838) Query indexed column with key filte
Query indexed column with key filte --- Key: CASSANDRA-2838 URL: https://issues.apache.org/jira/browse/CASSANDRA-2838 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Danny Wang To be able to support query like this, (KEY foo AND KEY bar and name1 = value1 Currently I found this code // Start and finish keys, *and* column relations (KEY foo AND KEY bar and name1 = value1). if (select.isKeyRange() (select.getKeyFinish() != null) (select.getColumnRelations().size() 0)) throw new InvalidRequestException(You cannot combine key range and by-column clauses in a SELECT); in http://svn.apache.org/repos/asf/cassandra/trunk/src/java/org/apache/cassandra/cql/QueryProcessor.java -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2819) Split rpc timeout for read and write ops
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Melvin Wang updated CASSANDRA-2819: --- Attachment: rpc-rw-timeouts.patch Split rpc timeout for read and write ops Key: CASSANDRA-2819 URL: https://issues.apache.org/jira/browse/CASSANDRA-2819 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Stu Hood Assignee: Melvin Wang Fix For: 1.0 Attachments: rpc-rw-timeouts.patch Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2839) Small typos in the cli
Small typos in the cli -- Key: CASSANDRA-2839 URL: https://issues.apache.org/jira/browse/CASSANDRA-2839 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.6 Reporter: Joaquin Casares Assignee: Joaquin Casares Priority: Minor Fix For: 0.7.7 Attachments: 2839.diff Memtable thresholds: %s/%s/%s (millions of ops/minutes/MB) was displaying ops/MB/minutes. placement_strategy: the fully qualified class used to place replicas in this keyspace. Valid values are org.apache.cassandra.locator.SimpleStrategy, org.apache.cassandra.locator.NetworkTopologyStrategy, and org.apache.cassandra.locator.OldNetworkTopologyStrategy was being displayed but would only accept SimpleStrategy. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2839) Small typos in the cli
[ https://issues.apache.org/jira/browse/CASSANDRA-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joaquin Casares updated CASSANDRA-2839: --- Attachment: 2839.diff Small typos in the cli -- Key: CASSANDRA-2839 URL: https://issues.apache.org/jira/browse/CASSANDRA-2839 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.6 Reporter: Joaquin Casares Assignee: Joaquin Casares Priority: Minor Fix For: 0.7.7 Attachments: 2839.diff Memtable thresholds: %s/%s/%s (millions of ops/minutes/MB) was displaying ops/MB/minutes. placement_strategy: the fully qualified class used to place replicas in this keyspace. Valid values are org.apache.cassandra.locator.SimpleStrategy, org.apache.cassandra.locator.NetworkTopologyStrategy, and org.apache.cassandra.locator.OldNetworkTopologyStrategy was being displayed but would only accept SimpleStrategy. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-959) Allow different timeouts for different classes of operation
[ https://issues.apache.org/jira/browse/CASSANDRA-959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056909#comment-13056909 ] Jonathan Ellis commented on CASSANDRA-959: -- Resurrected in CASSANDRA-2819. Allow different timeouts for different classes of operation --- Key: CASSANDRA-959 URL: https://issues.apache.org/jira/browse/CASSANDRA-959 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Jonathan Ellis Priority: Minor Fix For: 0.8 beta 1 Currently we have one rpc timeout for intra-node operations. But applying the same timeout to read one row, read multiple rows [by key], and range query multiple rows feels like an increasingly uncomfortable fit. (See e.g. CASSANDRA-919.) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2034) Make Read Repair unnecessary when Hinted Handoff is enabled
[ https://issues.apache.org/jira/browse/CASSANDRA-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056910#comment-13056910 ] Jonathan Ellis commented on CASSANDRA-2034: --- bq. If we had different timeouts for writes than reads then it might be nice to use say 80% of the timeout for the normal write, and reserve 20% for the hint phase Different r/w timeouts is being added in CASSANDRA-2819. Make Read Repair unnecessary when Hinted Handoff is enabled --- Key: CASSANDRA-2034 URL: https://issues.apache.org/jira/browse/CASSANDRA-2034 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Assignee: Patricio Echague Fix For: 1.0 Original Estimate: 8h Remaining Estimate: 8h Currently, HH is purely an optimization -- if a machine goes down, enabling HH means RR/AES will have less work to do, but you can't disable RR entirely in most situations since HH doesn't kick in until the FailureDetector does. Let's add a scheduled task to the mutate path, such that we return to the client normally after ConsistencyLevel is achieved, but after RpcTimeout we check the responseHandler write acks and write local hints for any missing targets. This would making disabling RR when HH is enabled a much more reasonable option, which has a huge impact on read throughput. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2045) Simplify HH to decrease read load when nodes come back
[ https://issues.apache.org/jira/browse/CASSANDRA-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056913#comment-13056913 ] Jonathan Ellis commented on CASSANDRA-2045: --- Thought of something else: if we're storing the full mutation, why add the complexity of hint headers and forwarding? Can we just make the coordinator responsible for all hints instead? Simplify HH to decrease read load when nodes come back -- Key: CASSANDRA-2045 URL: https://issues.apache.org/jira/browse/CASSANDRA-2045 Project: Cassandra Issue Type: Improvement Reporter: Chris Goffinet Assignee: Nicholas Telford Fix For: 1.0 Attachments: 0001-Changed-storage-of-Hints-to-store-a-serialized-RowMu.patch, 0002-Refactored-HintedHandoffManager.sendRow-to-reduce-co.patch, 0003-Fixed-some-coding-style-issues.patch, 0004-Fixed-direct-usage-of-Gossiper.getEndpointStateForEn.patch, 0005-Removed-duplicate-failure-detection-conditionals.-It.patch, 0006-Removed-handling-of-old-style-hints.patch, 2045-v3.txt, CASSANDRA-2045-simplify-hinted-handoff-001.diff, CASSANDRA-2045-simplify-hinted-handoff-002.diff Currently when HH is enabled, hints are stored, and when a node comes back, we begin sending that node data. We do a lookup on the local node for the row to send. To help reduce read load (if a node is offline for long period of time) we should store the data we want forward the node locally instead. We wouldn't have to do any lookups, just take byte[] and send to the destination. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (CASSANDRA-2838) Query indexed column with key filte
[ https://issues.apache.org/jira/browse/CASSANDRA-2838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reopened CASSANDRA-2838: --- Query indexed column with key filte --- Key: CASSANDRA-2838 URL: https://issues.apache.org/jira/browse/CASSANDRA-2838 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Danny Wang To be able to support query like this, (KEY foo AND KEY bar and name1 = value1 Currently I found this code // Start and finish keys, *and* column relations (KEY foo AND KEY bar and name1 = value1). if (select.isKeyRange() (select.getKeyFinish() != null) (select.getColumnRelations().size() 0)) throw new InvalidRequestException(You cannot combine key range and by-column clauses in a SELECT); in http://svn.apache.org/repos/asf/cassandra/trunk/src/java/org/apache/cassandra/cql/QueryProcessor.java -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-2838) Query indexed column with key filte
[ https://issues.apache.org/jira/browse/CASSANDRA-2838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-2838. --- Resolution: Won't Fix Query indexed column with key filte --- Key: CASSANDRA-2838 URL: https://issues.apache.org/jira/browse/CASSANDRA-2838 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Danny Wang To be able to support query like this, (KEY foo AND KEY bar and name1 = value1 Currently I found this code // Start and finish keys, *and* column relations (KEY foo AND KEY bar and name1 = value1). if (select.isKeyRange() (select.getKeyFinish() != null) (select.getColumnRelations().size() 0)) throw new InvalidRequestException(You cannot combine key range and by-column clauses in a SELECT); in http://svn.apache.org/repos/asf/cassandra/trunk/src/java/org/apache/cassandra/cql/QueryProcessor.java -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-2838) Query indexed column with key filte
[ https://issues.apache.org/jira/browse/CASSANDRA-2838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-2838. --- Resolution: Fixed key comparisons are only useful for OPP, which you shouldn't be using. Query indexed column with key filte --- Key: CASSANDRA-2838 URL: https://issues.apache.org/jira/browse/CASSANDRA-2838 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Danny Wang To be able to support query like this, (KEY foo AND KEY bar and name1 = value1 Currently I found this code // Start and finish keys, *and* column relations (KEY foo AND KEY bar and name1 = value1). if (select.isKeyRange() (select.getKeyFinish() != null) (select.getColumnRelations().size() 0)) throw new InvalidRequestException(You cannot combine key range and by-column clauses in a SELECT); in http://svn.apache.org/repos/asf/cassandra/trunk/src/java/org/apache/cassandra/cql/QueryProcessor.java -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2383) log4j unable to load properties file from classpath
[ https://issues.apache.org/jira/browse/CASSANDRA-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056929#comment-13056929 ] Jonathan Ellis commented on CASSANDRA-2383: --- Looks like this breaks configuration parameter is a well-formed url? configLocation is never used if new URL succeeds. log4j unable to load properties file from classpath --- 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: T Jake Luciani Priority: Minor Fix For: 0.7.7 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
svn commit: r1140928 - in /cassandra/branches/cassandra-0.7: CHANGES.txt src/java/org/apache/cassandra/cli/CliClient.java
Author: jbellis Date: Wed Jun 29 01:14:44 2011 New Revision: 1140928 URL: http://svn.apache.org/viewvc?rev=1140928view=rev Log: fix CLI parsing of read_repair_chance patch by Jon Hermes; reviewed by jbellis for CASSANDRA-2837 Modified: cassandra/branches/cassandra-0.7/CHANGES.txt cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/CliClient.java Modified: cassandra/branches/cassandra-0.7/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/CHANGES.txt?rev=1140928r1=1140927r2=1140928view=diff == --- cassandra/branches/cassandra-0.7/CHANGES.txt (original) +++ cassandra/branches/cassandra-0.7/CHANGES.txt Wed Jun 29 01:14:44 2011 @@ -25,6 +25,7 @@ * Fix potential NPE during read repair (CASSANDRA-2823) * fix race that could result in Hadoop writer failing to throw an exception encountered after close() (CASSANDRA-2755) + * fix CLI parsing of read_repair_chance (CASSANDRA-2837) 0.7.6 Modified: cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/CliClient.java URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/CliClient.java?rev=1140928r1=1140927r2=1140928view=diff == --- cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/CliClient.java (original) +++ cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/CliClient.java Wed Jun 29 01:14:44 2011 @@ -902,10 +902,10 @@ public class CliClient extends CliUserHe cfDef.setKey_cache_size(Double.parseDouble(mValue)); break; case READ_REPAIR_CHANCE: -double chance = Double.parseDouble(mValue) / 100; +double chance = Double.parseDouble(mValue); if (chance 1) -throw new RuntimeException(Error: read_repair_chance / 100 should not be greater than 1.); +throw new RuntimeException(Error: read_repair_chance should not be greater than 1.); cfDef.setRead_repair_chance(chance); break;
svn commit: r1140934 - in /cassandra/branches/cassandra-0.8: ./ contrib/ interface/thrift/gen-java/org/apache/cassandra/thrift/
Author: jbellis Date: Wed Jun 29 01:24:46 2011 New Revision: 1140934 URL: http://svn.apache.org/viewvc?rev=1140934view=rev Log: merge from 0.7 Modified: cassandra/branches/cassandra-0.8/ (props changed) cassandra/branches/cassandra-0.8/contrib/ (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/NotFoundException.java (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/SuperColumn.java (props changed) Propchange: cassandra/branches/cassandra-0.8/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Wed Jun 29 01:24:46 2011 @@ -1,5 +1,5 @@ /cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1131291 -/cassandra/branches/cassandra-0.7:1026516-1140567 +/cassandra/branches/cassandra-0.7:1026516-1140567,1140928 /cassandra/branches/cassandra-0.7.0:1053690-1055654 /cassandra/branches/cassandra-0.8:1090934-1125013,1125041 /cassandra/branches/cassandra-0.8.0:1125021-1130369 Propchange: cassandra/branches/cassandra-0.8/contrib/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Wed Jun 29 01:24:46 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-1140567 +/cassandra/branches/cassandra-0.7/contrib:1026516-1140567,1140928 /cassandra/branches/cassandra-0.7.0/contrib:1053690-1055654 /cassandra/branches/cassandra-0.8/contrib:1090934-1125013,1125041 /cassandra/branches/cassandra-0.8.0/contrib:1125021-1130369 Propchange: cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Wed Jun 29 01:24:46 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-1131291 -/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1140567 +/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1140567,1140928 /cassandra/branches/cassandra-0.7.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1053690-1055654 /cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1090934-1125013,1125041 /cassandra/branches/cassandra-0.8.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1125021-1130369 Propchange: cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Wed Jun 29 01:24:46 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-1131291 -/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1026516-1140567 +/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1026516-1140567,1140928 /cassandra/branches/cassandra-0.7.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1053690-1055654 /cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1090934-1125013,1125041 /cassandra/branches/cassandra-0.8.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1125021-1130369 Propchange: cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Wed Jun 29 01:24:46 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-1131291 -/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java:1026516-1140567
svn commit: r1140935 - in /cassandra/trunk: CHANGES.txt src/java/org/apache/cassandra/db/ColumnFamilyStore.java src/java/org/apache/cassandra/db/Memtable.java
Author: jbellis
Date: Wed Jun 29 01:26:02 2011
New Revision: 1140935
URL: http://svn.apache.org/viewvc?rev=1140935view=rev
Log:
don't bother persisting columns shadowed by a row tombstone
patch by Aaron Morton; reviewed by jbellis for CASSANDRA-2589
Modified:
cassandra/trunk/CHANGES.txt
cassandra/trunk/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
cassandra/trunk/src/java/org/apache/cassandra/db/Memtable.java
Modified: cassandra/trunk/CHANGES.txt
URL:
http://svn.apache.org/viewvc/cassandra/trunk/CHANGES.txt?rev=1140935r1=1140934r2=1140935view=diff
==
--- cassandra/trunk/CHANGES.txt (original)
+++ cassandra/trunk/CHANGES.txt Wed Jun 29 01:26:02 2011
@@ -5,9 +5,11 @@
* make AbstractBounds.normalize de-overlapp overlapping ranges
(CASSANDRA-2641)
* replace CollatingIterator, ReducingIterator with MergeIterator
(CASSANDRA-2062)
- * Fixed the ability to set compaction strategy in cli using create column
family command (CASSANDRA-2778)
+ * Fixed the ability to set compaction strategy in cli using create column
+ family command (CASSANDRA-2778)
* clean up tmp files after failed compaction (CASSANDRA-2468)
* restrict repair streaming to specific columnfamilies (CASSANDRA-2280)
+ * don't bother persisting columns shadowed by a row tombstone (CASSANDRA-2589)
0.8.2
Modified:
cassandra/trunk/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
URL:
http://svn.apache.org/viewvc/cassandra/trunk/src/java/org/apache/cassandra/db/ColumnFamilyStore.java?rev=1140935r1=1140934r2=1140935view=diff
==
--- cassandra/trunk/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
(original)
+++ cassandra/trunk/src/java/org/apache/cassandra/db/ColumnFamilyStore.java Wed
Jun 29 01:26:02 2011
@@ -795,7 +795,7 @@ public class ColumnFamilyStore implement
return removeDeletedCF(cf, gcBefore);
}
-private static void removeDeletedColumnsOnly(ColumnFamily cf, int gcBefore)
+public static void removeDeletedColumnsOnly(ColumnFamily cf, int gcBefore)
{
if (cf.isSuper())
removeDeletedSuper(cf, gcBefore);
Modified: cassandra/trunk/src/java/org/apache/cassandra/db/Memtable.java
URL:
http://svn.apache.org/viewvc/cassandra/trunk/src/java/org/apache/cassandra/db/Memtable.java?rev=1140935r1=1140934r2=1140935view=diff
==
--- cassandra/trunk/src/java/org/apache/cassandra/db/Memtable.java (original)
+++ cassandra/trunk/src/java/org/apache/cassandra/db/Memtable.java Wed Jun 29
01:26:02 2011
@@ -232,7 +232,15 @@ public class Memtable
// (we can't clear out the map as-we-go to free up memory,
// since the memtable is being used for queries in the pending
flush category)
for (Map.EntryDecoratedKey, ColumnFamily entry :
columnFamilies.entrySet())
-writer.append(entry.getKey(), entry.getValue());
+{
+ColumnFamily cf = entry.getValue();
+if (cf.isMarkedForDelete())
+{
+// don't bother persisting data shadowed by a row tombstone
+ColumnFamilyStore.removeDeletedColumnsOnly(cf,
Integer.MIN_VALUE);
+}
+writer.append(entry.getKey(), cf);
+}
ssTable = writer.closeAndOpenReader();
}
svn commit: r1140938 - /cassandra/trunk/src/java/org/apache/cassandra/db/Memtable.java
Author: jbellis
Date: Wed Jun 29 01:28:22 2011
New Revision: 1140938
URL: http://svn.apache.org/viewvc?rev=1140938view=rev
Log:
use aaron's improved 2589 comment
Modified:
cassandra/trunk/src/java/org/apache/cassandra/db/Memtable.java
Modified: cassandra/trunk/src/java/org/apache/cassandra/db/Memtable.java
URL:
http://svn.apache.org/viewvc/cassandra/trunk/src/java/org/apache/cassandra/db/Memtable.java?rev=1140938r1=1140937r2=1140938view=diff
==
--- cassandra/trunk/src/java/org/apache/cassandra/db/Memtable.java (original)
+++ cassandra/trunk/src/java/org/apache/cassandra/db/Memtable.java Wed Jun 29
01:28:22 2011
@@ -236,7 +236,10 @@ public class Memtable
ColumnFamily cf = entry.getValue();
if (cf.isMarkedForDelete())
{
-// don't bother persisting data shadowed by a row tombstone
+// Pedantically, you could purge column level tombstones
that are past GcGRace when writing to the SSTable.
+// But it can result in unexpected behaviour where deletes
never make it to disk,
+// as they are lost and so cannot override existing column
values. So we only remove deleted columns if there
+// is a CF level tombstone to ensure the delete makes it
into an SSTable.
ColumnFamilyStore.removeDeletedColumnsOnly(cf,
Integer.MIN_VALUE);
}
writer.append(entry.getKey(), cf);
[jira] [Resolved] (CASSANDRA-2589) row deletes do not remove columns
[ https://issues.apache.org/jira/browse/CASSANDRA-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-2589. --- Resolution: Fixed Fix Version/s: (was: 0.8.2) 1.0 Thanks, committed v2. row deletes do not remove columns - Key: CASSANDRA-2589 URL: https://issues.apache.org/jira/browse/CASSANDRA-2589 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Aaron Morton Assignee: Aaron Morton Priority: Minor Fix For: 1.0 Attachments: 0001-remove-deleted-columns-before-flushing-memtable-v07-2.patch, 0001-remove-deleted-columns-before-flushing-memtable-v07.patch, 0001-remove-deleted-columns-before-flushing-memtable-v08-2.patch, 0001-remove-deleted-columns-before-flushing-memtable-v08.patch When a row delete is issued CF.delete() sets the localDeletetionTime and markedForDeleteAt values but does not remove columns which have a lower time stamp. As a result: # Memory which could be freed is held on to (prob not too bad as it's already counted) # The deleted columns are serialised to disk, along with the CF info to say they are no longer valid. # NamesQueryFilter and SliceQueryFilter have to do more work as they filter out the irrelevant columns using QueryFilter.isRelevant() # Also columns written with a lower time stamp after the deletion are added to the CF without checking markedForDeletionAt. This can cause RR to fail, will create another ticket for that and link. This ticket is for a fix to removing the columns. Two options I could think of: # Check for deletion when serialising to SSTable and ignore columns if the have a lower timestamp. Otherwise leave as is so dead columns stay in memory. # Ensure at all times if the CF is deleted all columns it contains have a higher timestamp. ## I *think* this would include all column types (DeletedColumn as well) as the CF deletion has the same effect. But not sure. ## Deleting (potentially) all columns in delete() will take time. Could track the highest timestamp in the CF so the normal case of deleting all cols does not need to iterate. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2837) Setting RR Chance via CliClient results in chance being too low
[
https://issues.apache.org/jira/browse/CASSANDRA-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056948#comment-13056948
]
Hudson commented on CASSANDRA-2837:
---
Integrated in Cassandra-0.7 #516 (See
[https://builds.apache.org/job/Cassandra-0.7/516/])
fix CLI parsing of read_repair_chance
patch by Jon Hermes; reviewed by jbellis for CASSANDRA-2837
jbellis :
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1140928
Files :
* /cassandra/branches/cassandra-0.7/CHANGES.txt
*
/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/cli/CliClient.java
Setting RR Chance via CliClient results in chance being too low
Key: CASSANDRA-2837
URL: https://issues.apache.org/jira/browse/CASSANDRA-2837
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.7.6
Reporter: Bill de hOra
Assignee: Jon Hermes
Priority: Minor
Fix For: 0.7.7
Attachments: 2837.txt
running a command like
{noformat}
update column family shorturls with read_repair_chance=0.4;
{noformat}
results in the value being set to 0.0040. Was expecting it to be 0.4.
Affects 0.7.6.-2; seems to be fixed on trunk/0.8.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2589) row deletes do not remove columns
[ https://issues.apache.org/jira/browse/CASSANDRA-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056959#comment-13056959 ] Hudson commented on CASSANDRA-2589: --- Integrated in Cassandra #944 (See [https://builds.apache.org/job/Cassandra/944/]) don't bother persisting columns shadowed by a row tombstone patch by Aaron Morton; reviewed by jbellis for CASSANDRA-2589 jbellis : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1140935 Files : * /cassandra/trunk/src/java/org/apache/cassandra/db/Memtable.java * /cassandra/trunk/CHANGES.txt * /cassandra/trunk/src/java/org/apache/cassandra/db/ColumnFamilyStore.java row deletes do not remove columns - Key: CASSANDRA-2589 URL: https://issues.apache.org/jira/browse/CASSANDRA-2589 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Aaron Morton Assignee: Aaron Morton Priority: Minor Fix For: 1.0 Attachments: 0001-remove-deleted-columns-before-flushing-memtable-v07-2.patch, 0001-remove-deleted-columns-before-flushing-memtable-v07.patch, 0001-remove-deleted-columns-before-flushing-memtable-v08-2.patch, 0001-remove-deleted-columns-before-flushing-memtable-v08.patch When a row delete is issued CF.delete() sets the localDeletetionTime and markedForDeleteAt values but does not remove columns which have a lower time stamp. As a result: # Memory which could be freed is held on to (prob not too bad as it's already counted) # The deleted columns are serialised to disk, along with the CF info to say they are no longer valid. # NamesQueryFilter and SliceQueryFilter have to do more work as they filter out the irrelevant columns using QueryFilter.isRelevant() # Also columns written with a lower time stamp after the deletion are added to the CF without checking markedForDeletionAt. This can cause RR to fail, will create another ticket for that and link. This ticket is for a fix to removing the columns. Two options I could think of: # Check for deletion when serialising to SSTable and ignore columns if the have a lower timestamp. Otherwise leave as is so dead columns stay in memory. # Ensure at all times if the CF is deleted all columns it contains have a higher timestamp. ## I *think* this would include all column types (DeletedColumn as well) as the CF deletion has the same effect. But not sure. ## Deleting (potentially) all columns in delete() will take time. Could track the highest timestamp in the CF so the normal case of deleting all cols does not need to iterate. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2838) Query indexed column with key filte
[ https://issues.apache.org/jira/browse/CASSANDRA-2838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056971#comment-13056971 ] Stu Hood commented on CASSANDRA-2838: - Isn't this CASSANDRA-1600? Query indexed column with key filte --- Key: CASSANDRA-2838 URL: https://issues.apache.org/jira/browse/CASSANDRA-2838 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Danny Wang To be able to support query like this, (KEY foo AND KEY bar and name1 = value1 Currently I found this code // Start and finish keys, *and* column relations (KEY foo AND KEY bar and name1 = value1). if (select.isKeyRange() (select.getKeyFinish() != null) (select.getColumnRelations().size() 0)) throw new InvalidRequestException(You cannot combine key range and by-column clauses in a SELECT); in http://svn.apache.org/repos/asf/cassandra/trunk/src/java/org/apache/cassandra/cql/QueryProcessor.java -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2491) A new config parameter, broadcast_address
[ https://issues.apache.org/jira/browse/CASSANDRA-2491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vijay updated CASSANDRA-2491: - Attachment: (was: 2491_broadcast_address_v2.patch) A new config parameter, broadcast_address - Key: CASSANDRA-2491 URL: https://issues.apache.org/jira/browse/CASSANDRA-2491 Project: Cassandra Issue Type: Improvement Components: Core Environment: x86_64 GNU/Linux Reporter: Khee Chin Assignee: Khee Chin Priority: Trivial Labels: patch Fix For: 1.0 Attachments: 2491_broadcast_address.patch, 2491_broadcast_address_v6.patch Original Estimate: 336h Remaining Estimate: 336h A new config parameter, broadcast_address In a cluster setup where one or more nodes is behind a firewall and has a private ip address, listen_address does not allow the hosts behind the firewalls to be discovered by other nodes. Attached is a patch that introduces a new config parameter broadcast_address which allows Cassandra nodes to explicitly specify their external ip address. In addition, this allows listen_address to be set to 0.0.0.0 on the already firewalled node. broadcast_address fallsback to listen_address when it is not stated. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2491) A new config parameter, broadcast_address
[ https://issues.apache.org/jira/browse/CASSANDRA-2491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vijay updated CASSANDRA-2491: - Attachment: (was: 2491_broadcast_address_v4.patch) A new config parameter, broadcast_address - Key: CASSANDRA-2491 URL: https://issues.apache.org/jira/browse/CASSANDRA-2491 Project: Cassandra Issue Type: Improvement Components: Core Environment: x86_64 GNU/Linux Reporter: Khee Chin Assignee: Khee Chin Priority: Trivial Labels: patch Fix For: 1.0 Attachments: 2491_broadcast_address.patch, 2491_broadcast_address_v6.patch Original Estimate: 336h Remaining Estimate: 336h A new config parameter, broadcast_address In a cluster setup where one or more nodes is behind a firewall and has a private ip address, listen_address does not allow the hosts behind the firewalls to be discovered by other nodes. Attached is a patch that introduces a new config parameter broadcast_address which allows Cassandra nodes to explicitly specify their external ip address. In addition, this allows listen_address to be set to 0.0.0.0 on the already firewalled node. broadcast_address fallsback to listen_address when it is not stated. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2491) A new config parameter, broadcast_address
[ https://issues.apache.org/jira/browse/CASSANDRA-2491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vijay updated CASSANDRA-2491: - Attachment: (was: 2491_broadcast_address_v3.patch) A new config parameter, broadcast_address - Key: CASSANDRA-2491 URL: https://issues.apache.org/jira/browse/CASSANDRA-2491 Project: Cassandra Issue Type: Improvement Components: Core Environment: x86_64 GNU/Linux Reporter: Khee Chin Assignee: Khee Chin Priority: Trivial Labels: patch Fix For: 1.0 Attachments: 2491_broadcast_address.patch, 2491_broadcast_address_v6.patch Original Estimate: 336h Remaining Estimate: 336h A new config parameter, broadcast_address In a cluster setup where one or more nodes is behind a firewall and has a private ip address, listen_address does not allow the hosts behind the firewalls to be discovered by other nodes. Attached is a patch that introduces a new config parameter broadcast_address which allows Cassandra nodes to explicitly specify their external ip address. In addition, this allows listen_address to be set to 0.0.0.0 on the already firewalled node. broadcast_address fallsback to listen_address when it is not stated. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2491) A new config parameter, broadcast_address
[ https://issues.apache.org/jira/browse/CASSANDRA-2491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vijay updated CASSANDRA-2491: - Attachment: (was: 2491_broadcast_address_v5.patch) A new config parameter, broadcast_address - Key: CASSANDRA-2491 URL: https://issues.apache.org/jira/browse/CASSANDRA-2491 Project: Cassandra Issue Type: Improvement Components: Core Environment: x86_64 GNU/Linux Reporter: Khee Chin Assignee: Khee Chin Priority: Trivial Labels: patch Fix For: 1.0 Attachments: 2491_broadcast_address.patch, 2491_broadcast_address_v6.patch Original Estimate: 336h Remaining Estimate: 336h A new config parameter, broadcast_address In a cluster setup where one or more nodes is behind a firewall and has a private ip address, listen_address does not allow the hosts behind the firewalls to be discovered by other nodes. Attached is a patch that introduces a new config parameter broadcast_address which allows Cassandra nodes to explicitly specify their external ip address. In addition, this allows listen_address to be set to 0.0.0.0 on the already firewalled node. broadcast_address fallsback to listen_address when it is not stated. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
