git commit: Remove CF.resolve()
Updated Branches:
refs/heads/trunk 3aaa0295c - 79c6e
Remove CF.resolve()
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/79c6eccc
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/79c6eccc
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/79c6eccc
Branch: refs/heads/trunk
Commit: 79c6e0760c2c19d3e83f5815307690ec0bdf
Parents: 3aaa029
Author: Aleksey Yeschenko alek...@apache.org
Authored: Thu Feb 13 11:44:21 2014 +0300
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Thu Feb 13 11:44:21 2014 +0300
--
src/java/org/apache/cassandra/db/ColumnFamily.java | 8
src/java/org/apache/cassandra/db/Mutation.java | 2 +-
.../cassandra/db/index/composites/CompositesSearcher.java| 2 +-
test/unit/org/apache/cassandra/db/RowTest.java | 2 +-
4 files changed, 3 insertions(+), 11 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/79c6eccc/src/java/org/apache/cassandra/db/ColumnFamily.java
--
diff --git a/src/java/org/apache/cassandra/db/ColumnFamily.java
b/src/java/org/apache/cassandra/db/ColumnFamily.java
index 66e8e33..3437410 100644
--- a/src/java/org/apache/cassandra/db/ColumnFamily.java
+++ b/src/java/org/apache/cassandra/db/ColumnFamily.java
@@ -389,14 +389,6 @@ public abstract class ColumnFamily implements
IterableCell, IRowCacheEntry
return cf1.diff(cf2);
}
-public void resolve(ColumnFamily cf)
-{
-// Row _does_ allow null CF objects :( seems a necessary evil for
efficiency
-if (cf == null)
-return;
-addAll(cf);
-}
-
public ColumnStats getColumnStats()
{
long minTimestampSeen = deletionInfo().isLive() ? Long.MAX_VALUE :
deletionInfo().minTimestamp();
http://git-wip-us.apache.org/repos/asf/cassandra/blob/79c6eccc/src/java/org/apache/cassandra/db/Mutation.java
--
diff --git a/src/java/org/apache/cassandra/db/Mutation.java
b/src/java/org/apache/cassandra/db/Mutation.java
index bb7dcef..3663380 100644
--- a/src/java/org/apache/cassandra/db/Mutation.java
+++ b/src/java/org/apache/cassandra/db/Mutation.java
@@ -191,7 +191,7 @@ public class Mutation implements IMutation
// not in the case where it wasn't there indeed.
ColumnFamily cf = modifications.put(entry.getKey(),
entry.getValue());
if (cf != null)
-entry.getValue().resolve(cf);
+entry.getValue().addAll(cf);
}
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/79c6eccc/src/java/org/apache/cassandra/db/index/composites/CompositesSearcher.java
--
diff --git
a/src/java/org/apache/cassandra/db/index/composites/CompositesSearcher.java
b/src/java/org/apache/cassandra/db/index/composites/CompositesSearcher.java
index fad3d50..41c9f41 100644
--- a/src/java/org/apache/cassandra/db/index/composites/CompositesSearcher.java
+++ b/src/java/org/apache/cassandra/db/index/composites/CompositesSearcher.java
@@ -274,7 +274,7 @@ public class CompositesSearcher extends
SecondaryIndexSearcher
if (data == null)
data =
ArrayBackedSortedColumns.factory.create(baseCfs.metadata);
-data.resolve(newData);
+data.addAll(newData);
columnsCount += dataFilter.lastCounted();
}
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/79c6eccc/test/unit/org/apache/cassandra/db/RowTest.java
--
diff --git a/test/unit/org/apache/cassandra/db/RowTest.java
b/test/unit/org/apache/cassandra/db/RowTest.java
index 4a686c5..9a91285 100644
--- a/test/unit/org/apache/cassandra/db/RowTest.java
+++ b/test/unit/org/apache/cassandra/db/RowTest.java
@@ -59,7 +59,7 @@ public class RowTest extends SchemaLoader
cf2.addColumn(column(one, B, 1));
cf2.addColumn(column(two, C, 1));
-cf1.resolve(cf2);
+cf1.addAll(cf2);
assert
Arrays.equals(cf1.getColumn(CellNames.simpleDense(ByteBufferUtil.bytes(one))).value().array(),
B.getBytes());
assert
Arrays.equals(cf1.getColumn(CellNames.simpleDense(ByteBufferUtil.bytes(two))).value().array(),
C.getBytes());
}
[jira] [Commented] (CASSANDRA-6697) Refactor Cell and CellName ByteBuffer accessors to avoid garbage allocation where possible
[ https://issues.apache.org/jira/browse/CASSANDRA-6697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900179#comment-13900179 ] Benedict commented on CASSANDRA-6697: - I agree this is far from the ideal situation, however I want to be certain at least that we *can* make this optimisation in a way we're happy with before moving us to off-heap Cell implementations, whether or not we apply it immediately. Without something like this, especially with compound primary keys, we could see dramatic increases in garbage production. Note that any name or CQL row lookup within a row will need 3.lg N bytebuffer constructions just to locate it. If we're looking up multiple names, this could rapidly get very problematic. Note that I don't expect throughput to *necessarily* be improved with this, but garbage is our number one enemy for latency, and latency spikes are one of our user's biggest headaches. Whilst this isn't ideal, I'm actually much happier with the result than I expected to be. It's pretty neat and tidy, and not *so* brittle - if ever in doubt just use referrable(), which is essentially our current semantics. I'm might be with you at least on mitigating it by defensively using it in places where there's any ambiguity (or potential for future ambiguity). There is one other approach to this, which is to pair this up more closely with the off-heap-memtable code, and maintain a per-thread free-list of bytebuffers that is automatically managed with the RefAction stuff introduced in CASSANDRA-6689. This might be slightly safer, although I'm not so fond of it. Harder to do micro-optimisations, and probably slightly increased overhead. Although a benefit is zero extra cost for on-heap. What I had hoped to use was escape analysis. But that won't be good enough for a long time, and even when it is, it almost certainly won't work with unsafe, which means we would have to move off of ByteBuffer, which may be infeasible. So it may never help us. Note after three failed attempts yesterday to edit the title, the correct dependent issue is CASSANDRA-6694. Refactor Cell and CellName ByteBuffer accessors to avoid garbage allocation where possible -- Key: CASSANDRA-6697 URL: https://issues.apache.org/jira/browse/CASSANDRA-6697 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Benedict Fix For: 2.1 This is a prerequisite for CASSANDRA-6689. The basic idea is to, if unsafe is available, abuse it to modify preallocated ByteBuffers so that when they are short lived they do not need to be instantiated. Initially this will only be helpful for comparisons and lookups on the BBs, but with some modifications to the read path we should be able to reduce the need in CASSANDRA-6689 to construct BBs to pass to the native protocol (thrift may have to continue as is) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6379) Replace index_interval with min/max_index_interval
[
https://issues.apache.org/jira/browse/CASSANDRA-6379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900201#comment-13900201
]
Aleksey Yeschenko commented on CASSANDRA-6379:
--
Thorough. LGTM, +1.
Replace index_interval with min/max_index_interval
--
Key: CASSANDRA-6379
URL: https://issues.apache.org/jira/browse/CASSANDRA-6379
Project: Cassandra
Issue Type: New Feature
Components: Core
Reporter: Tyler Hobbs
Assignee: Tyler Hobbs
Fix For: 2.1
Attachments: 6379-thrift-gen.txt, 6379.txt
As a continuation of the work in CASSANDRA-5519, we want to replace the
{{index_interval}} attribute of tables with {{min_index_interval}} and
{{max_index_interval}}.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6379) Replace index_interval with min/max_index_interval
[
https://issues.apache.org/jira/browse/CASSANDRA-6379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900204#comment-13900204
]
Aleksey Yeschenko commented on CASSANDRA-6379:
--
Well, almost. Should add max/min index intervals to CFMetaData
equals/toString/hashCode. Plus a nit - CFMetaData import in IndexSummary is in
the wrong spot.
Replace index_interval with min/max_index_interval
--
Key: CASSANDRA-6379
URL: https://issues.apache.org/jira/browse/CASSANDRA-6379
Project: Cassandra
Issue Type: New Feature
Components: Core
Reporter: Tyler Hobbs
Assignee: Tyler Hobbs
Fix For: 2.1
Attachments: 6379-thrift-gen.txt, 6379.txt
As a continuation of the work in CASSANDRA-5519, we want to replace the
{{index_interval}} attribute of tables with {{min_index_interval}} and
{{max_index_interval}}.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6697) Refactor Cell and CellName ByteBuffer accessors to avoid garbage allocation where possible
[ https://issues.apache.org/jira/browse/CASSANDRA-6697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900235#comment-13900235 ] Benedict commented on CASSANDRA-6697: - bq. If we're looking up multiple names, this could rapidly get very problematic Hmm. This might be even worse than I thought. When we're merging with data on disk, we're going to incur this cost at least O(n) times (where n = number of columns in memtable being extracted). This could be tremendous amounts of garbage - a query returning only 10k columns could generate several megabytes of garbage. Refactor Cell and CellName ByteBuffer accessors to avoid garbage allocation where possible -- Key: CASSANDRA-6697 URL: https://issues.apache.org/jira/browse/CASSANDRA-6697 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Benedict Fix For: 2.1 This is a prerequisite for CASSANDRA-6689. The basic idea is to, if unsafe is available, abuse it to modify preallocated ByteBuffers so that when they are short lived they do not need to be instantiated. Initially this will only be helpful for comparisons and lookups on the BBs, but with some modifications to the read path we should be able to reduce the need in CASSANDRA-6689 to construct BBs to pass to the native protocol (thrift may have to continue as is) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6697) Refactor Cell and CellName ByteBuffer accessors to avoid garbage allocation where possible
[ https://issues.apache.org/jira/browse/CASSANDRA-6697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900249#comment-13900249 ] Benedict commented on CASSANDRA-6697: - There is another option still, that might meet all of the criteria: instead of providing the scope, you provide something that to the accessor looks basically the same, but for which the resultant function is not defined (from the POV of the accessor). Callers of the accessors select the correct function: for comparisons we could grab a thread-local instance on which we set the comparator we want to actually compare with, and then pass in to the accessors a left() and right() function that is used to populate the comparator. The internal logic will be dependent on the same concepts as the scope approach, but the correct scoping should be enforced, assuming you don't use the function incorrectly. The downside is it might have slightly increased overhead. For comparisons, for instance, you'd probably need a special object with two child (left/right) objects which are passed to the accessors to wire up either side of the comparison. It also isn't as flexible. A further option still (still) is to have a special accessor for the function we want to perform. Since most of the time we just want to avoid the cost we care about comparison, having a special compareTo() method, and a special writeTo(BB) might be enough to deal with most of the situations we'll encounter. It won't help us when comparing two off-heap instances, though, without a further specialised accessor, without which we would probably not eliminate much of the O( N ) garbage during merging/collation of results. Still, this may be the best of the options other than the current tree. Refactor Cell and CellName ByteBuffer accessors to avoid garbage allocation where possible -- Key: CASSANDRA-6697 URL: https://issues.apache.org/jira/browse/CASSANDRA-6697 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Benedict Fix For: 2.1 This is a prerequisite for CASSANDRA-6689. The basic idea is to, if unsafe is available, abuse it to modify preallocated ByteBuffers so that when they are short lived they do not need to be instantiated. Initially this will only be helpful for comparisons and lookups on the BBs, but with some modifications to the read path we should be able to reduce the need in CASSANDRA-6689 to construct BBs to pass to the native protocol (thrift may have to continue as is) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6697) Refactor Cell and CellName ByteBuffer accessors to avoid garbage allocation where possible
[ https://issues.apache.org/jira/browse/CASSANDRA-6697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict updated CASSANDRA-6697: Description: This is a prerequisite for CASSANDRA-6694. The basic idea is to, if unsafe is available, abuse it to modify preallocated ByteBuffers so that when they are short lived they do not need to be instantiated. Initially this will only be helpful for comparisons and lookups on the BBs, but with some modifications to the read path we should be able to reduce the need in CASSANDRA-6694 to construct BBs to pass to the native protocol (thrift may have to continue as is) was: This is a prerequisite for CASSANDRA-6689. The basic idea is to, if unsafe is available, abuse it to modify preallocated ByteBuffers so that when they are short lived they do not need to be instantiated. Initially this will only be helpful for comparisons and lookups on the BBs, but with some modifications to the read path we should be able to reduce the need in CASSANDRA-6689 to construct BBs to pass to the native protocol (thrift may have to continue as is) Refactor Cell and CellName ByteBuffer accessors to avoid garbage allocation where possible -- Key: CASSANDRA-6697 URL: https://issues.apache.org/jira/browse/CASSANDRA-6697 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Benedict Fix For: 2.1 This is a prerequisite for CASSANDRA-6694. The basic idea is to, if unsafe is available, abuse it to modify preallocated ByteBuffers so that when they are short lived they do not need to be instantiated. Initially this will only be helpful for comparisons and lookups on the BBs, but with some modifications to the read path we should be able to reduce the need in CASSANDRA-6694 to construct BBs to pass to the native protocol (thrift may have to continue as is) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6697) Refactor Cell and CellName ByteBuffer accessors to avoid garbage allocation where possible
[ https://issues.apache.org/jira/browse/CASSANDRA-6697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900273#comment-13900273 ] Benedict commented on CASSANDRA-6697: - One last update to this thought process for now: The approach outlined in the current patch has the added benefit of trivially being optimised to NO-OPs for on-heap memtables through a private static final field set from information in DatabaseDescriptor (which should literally mean its removal by the C2 compiler). Given this, and that it would mean if we *did* introduce any weird bugs they could trivially be pinned down to here, and would not affect the current implementation - and that there aren't *that* many places outside of test cases where care would be needed, I'm now leaning reasonably strongly in favour of this route. Refactor Cell and CellName ByteBuffer accessors to avoid garbage allocation where possible -- Key: CASSANDRA-6697 URL: https://issues.apache.org/jira/browse/CASSANDRA-6697 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Benedict Fix For: 2.1 This is a prerequisite for CASSANDRA-6694. The basic idea is to, if unsafe is available, abuse it to modify preallocated ByteBuffers so that when they are short lived they do not need to be instantiated. Initially this will only be helpful for comparisons and lookups on the BBs, but with some modifications to the read path we should be able to reduce the need in CASSANDRA-6694 to construct BBs to pass to the native protocol (thrift may have to continue as is) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CASSANDRA-6699) NPE in migration stage on trunk
Brandon Williams created CASSANDRA-6699:
---
Summary: NPE in migration stage on trunk
Key: CASSANDRA-6699
URL: https://issues.apache.org/jira/browse/CASSANDRA-6699
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Brandon Williams
Fix For: 2.1
Simple to reproduce, start a cluster and run legacy stress against it:
{noformat}
ERROR 12:56:12 Error occurred during processing of message.
java.lang.RuntimeException: java.util.concurrent.ExecutionException:
java.lang.NullPointerException
at org.apache.cassandra.utils.FBUtilities.waitOnFuture(FBUtilities.java:411)
~[main/:na]
at
org.apache.cassandra.service.MigrationManager.announce(MigrationManager.java:281)
~[main/:na]
at
org.apache.cassandra.service.MigrationManager.announceNewColumnFamily(MigrationManager.java:211)
~[main/:na]
at
org.apache.cassandra.cql3.statements.CreateTableStatement.announceMigration(CreateTableStatement.java:105)
~[main/:na]
at
org.apache.cassandra.cql3.statements.SchemaAlteringStatement.execute(SchemaAlteringStatement.java:71)
~[main/:na]
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:180)
~[main/:na]
at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:214)
~[main/:na]
at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:204)
~[main/:na]
at
org.apache.cassandra.thrift.CassandraServer.execute_cql3_query(CassandraServer.java:1973)
~[main/:na]
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(Cassandra.java:4486)
~[thrift/:na]
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(Cassandra.java:4470)
~[thrift/:na]
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
~[libthrift-0.9.1.jar:0.9.1]
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
~[libthrift-0.9.1.jar:0.9.1]
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:194)
~[main/:na]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[na:1.7.0_51]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[na:1.7.0_51]
at java.lang.Thread.run(Thread.java:744) [na:1.7.0_51]
Caused by: java.util.concurrent.ExecutionException:
java.lang.NullPointerException
at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[na:1.7.0_51]
at java.util.concurrent.FutureTask.get(FutureTask.java:188) ~[na:1.7.0_51]
at org.apache.cassandra.utils.FBUtilities.waitOnFuture(FBUtilities.java:407)
~[main/:na]
... 16 common frames omitted
Caused by: java.lang.NullPointerException: null
at org.apache.cassandra.utils.ByteBufferUtil.string(ByteBufferUtil.java:167)
~[main/:na]
at
org.apache.cassandra.serializers.AbstractTextSerializer.deserialize(AbstractTextSerializer.java:39)
~[main/:na]
at
org.apache.cassandra.serializers.AbstractTextSerializer.deserialize(AbstractTextSerializer.java:26)
~[main/:na]
at org.apache.cassandra.db.marshal.AbstractType.compose(AbstractType.java:66)
~[main/:na]
at
org.apache.cassandra.cql3.UntypedResultSet$Row.getString(UntypedResultSet.java:150)
~[main/:na]
at
org.apache.cassandra.config.ColumnDefinition.fromSchema(ColumnDefinition.java:373)
~[main/:na]
at
org.apache.cassandra.config.CFMetaData.fromSchemaNoTriggers(CFMetaData.java:1712)
~[main/:na]
at org.apache.cassandra.config.CFMetaData.fromSchema(CFMetaData.java:1832)
~[main/:na]
at
org.apache.cassandra.config.KSMetaData.deserializeColumnFamilies(KSMetaData.java:320)
~[main/:na]
at org.apache.cassandra.db.DefsTables.mergeColumnFamilies(DefsTables.java:306)
~[main/:na]
at org.apache.cassandra.db.DefsTables.mergeSchema(DefsTables.java:181)
~[main/:na]
at
org.apache.cassandra.service.MigrationManager$2.runMayThrow(MigrationManager.java:299)
~[main/:na]
at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
~[main/:na]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
~[na:1.7.0_51]
at java.util.concurrent.FutureTask.run(FutureTask.java:262) ~[na:1.7.0_51]
... 3 common frames omitted
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6631) cassandra-stress failing in trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-6631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900357#comment-13900357
]
Benedict commented on CASSANDRA-6631:
-
Why don;t we need the dependencies file? Do you want users to download it?
It breaks the cassandra-stress bin as it stands, anyway, which isn't great IMO
cassandra-stress failing in trunk
-
Key: CASSANDRA-6631
URL: https://issues.apache.org/jira/browse/CASSANDRA-6631
Project: Cassandra
Issue Type: Bug
Components: Tools
Environment: Debian Stable Wheezy
Oracle JDK 1.7.0_51-b13
Reporter: Michael Shuler
Fix For: 2.1
Stress is failing in trunk.
- ant clean jar
- ./bin/cassandra -f
- ./tools/bin/cassandra-stress write
{noformat}
(trunk)mshuler@hana:~/git/cassandra$ ./tools/bin/cassandra-stress write
Created keyspaces. Sleeping 1s for propagation.
Warming up WRITE with 5 iterations...
Exception in thread Thread-0 java.lang.RuntimeException:
java.lang.IllegalArgumentException: replicate_on_write is not a column
defined in this metadata
at
org.apache.cassandra.stress.settings.StressSettings.getJavaDriverClient(StressSettings.java:142)
at
org.apache.cassandra.stress.settings.StressSettings.getSmartThriftClient(StressSettings.java:49)
at
org.apache.cassandra.stress.StressAction$Consumer.run(StressAction.java:273)
Caused by: java.lang.IllegalArgumentException: replicate_on_write is not a
column defined in this metadata
at
com.datastax.driver.core.ColumnDefinitions.getAllIdx(ColumnDefinitions.java:273)
at
com.datastax.driver.core.ColumnDefinitions.getFirstIdx(ColumnDefinitions.java:279)
at com.datastax.driver.core.Row.getBool(Row.java:117)
at
com.datastax.driver.core.TableMetadata$Options.init(TableMetadata.java:474)
at
com.datastax.driver.core.TableMetadata.build(TableMetadata.java:107)
at
com.datastax.driver.core.Metadata.buildTableMetadata(Metadata.java:128)
at com.datastax.driver.core.Metadata.rebuildSchema(Metadata.java:89)
at
com.datastax.driver.core.ControlConnection.refreshSchema(ControlConnection.java:259)
at
com.datastax.driver.core.ControlConnection.tryConnect(ControlConnection.java:214)
at
com.datastax.driver.core.ControlConnection.reconnectInternal(ControlConnection.java:161)
at
com.datastax.driver.core.ControlConnection.connect(ControlConnection.java:77)
at com.datastax.driver.core.Cluster$Manager.init(Cluster.java:890)
at
com.datastax.driver.core.Cluster$Manager.access$100(Cluster.java:806)
at com.datastax.driver.core.Cluster.getMetadata(Cluster.java:217)
at
org.apache.cassandra.stress.util.JavaDriverClient.connect(JavaDriverClient.java:75)
at
org.apache.cassandra.stress.settings.StressSettings.getJavaDriverClient(StressSettings.java:135)
... 2 more
Exception in thread Thread-19 java.lang.RuntimeException:
java.lang.IllegalArgumentException: replicate_on_write is not a column
defined in this metadata
at
org.apache.cassandra.stress.settings.StressSettings.getJavaDriverClient(StressSettings.java:142)
at
org.apache.cassandra.stress.settings.StressSettings.getSmartThriftClient(StressSettings.java:49)
at
org.apache.cassandra.stress.StressAction$Consumer.run(StressAction.java:273)
Caused by: java.lang.IllegalArgumentException: replicate_on_write is not a
column defined in this metadata
at
com.datastax.driver.core.ColumnDefinitions.getAllIdx(ColumnDefinitions.java:273)
at
com.datastax.driver.core.ColumnDefinitions.getFirstIdx(ColumnDefinitions.java:279)
at com.datastax.driver.core.Row.getBool(Row.java:117)
at
com.datastax.driver.core.TableMetadata$Options.init(TableMetadata.java:474)
at
com.datastax.driver.core.TableMetadata.build(TableMetadata.java:107)
at
com.datastax.driver.core.Metadata.buildTableMetadata(Metadata.java:128)
at com.datastax.driver.core.Metadata.rebuildSchema(Metadata.java:89)
at
com.datastax.driver.core.ControlConnection.refreshSchema(ControlConnection.java:259)
at
com.datastax.driver.core.ControlConnection.tryConnect(ControlConnection.java:214)
at
com.datastax.driver.core.ControlConnection.reconnectInternal(ControlConnection.java:161)
at
com.datastax.driver.core.ControlConnection.connect(ControlConnection.java:77)
at com.datastax.driver.core.Cluster$Manager.init(Cluster.java:890)
at
com.datastax.driver.core.Cluster$Manager.access$100(Cluster.java:806)
at com.datastax.driver.core.Cluster.getMetadata(Cluster.java:217)
at
[jira] [Commented] (CASSANDRA-6683) BADNESS_THRESHOLD does not working correctly with DynamicEndpointSnitch
[
https://issues.apache.org/jira/browse/CASSANDRA-6683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900365#comment-13900365
]
Chris Burroughs commented on CASSANDRA-6683:
bq. I think it would make more sense (and fix Kirill's case) to always call
sortByProximityWithScore() and then compare that ordering against the subsnitch
list.
FWIW Everyone I have shown this code to thought that's what it did based on the
description and then spent a lot of time being puzzled when they realized it
didn't.
BADNESS_THRESHOLD does not working correctly with DynamicEndpointSnitch
---
Key: CASSANDRA-6683
URL: https://issues.apache.org/jira/browse/CASSANDRA-6683
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: Linux 3.8.0-33-generic
Reporter: Kirill Bogdanov
Labels: snitch
Fix For: 2.0.6
There is a problem in *DynamicEndpointSnitch.java* in
sortByProximityWithBadness()
Before calling sortByProximityWithScore we comparing each nodes score ratios
to the badness threshold.
{code}
if ((first - next) / first BADNESS_THRESHOLD)
{
sortByProximityWithScore(address, addresses);
return;
}
{code}
This is not always the correct comparison because *first* score can be less
than *next* score and in that case we will compare a negative number with
positive.
The solution is to compute absolute value of the ratio:
{code}
if (Math.abs((first - next) / first) BADNESS_THRESHOLD)
{code}
This issue causing an incorrect sorting of DCs based on their performance and
affects performance of the snitch.
Thanks.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6631) cassandra-stress failing in trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-6631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900378#comment-13900378
]
Sylvain Lebresne commented on CASSANDRA-6631:
-
bq. Why don;t we need the dependencies file? Do you want users to download it?
No, I meant that all the dependencies the driver jar I put it needs should be
in C* already. This does mean that the stress should include the C* lib/ jars
in the classpath, which I assumed it does since I was able to run stress on my
box with what is in trunk (and Michael seemed to have confirmed it). What
problem do you see?
cassandra-stress failing in trunk
-
Key: CASSANDRA-6631
URL: https://issues.apache.org/jira/browse/CASSANDRA-6631
Project: Cassandra
Issue Type: Bug
Components: Tools
Environment: Debian Stable Wheezy
Oracle JDK 1.7.0_51-b13
Reporter: Michael Shuler
Fix For: 2.1
Stress is failing in trunk.
- ant clean jar
- ./bin/cassandra -f
- ./tools/bin/cassandra-stress write
{noformat}
(trunk)mshuler@hana:~/git/cassandra$ ./tools/bin/cassandra-stress write
Created keyspaces. Sleeping 1s for propagation.
Warming up WRITE with 5 iterations...
Exception in thread Thread-0 java.lang.RuntimeException:
java.lang.IllegalArgumentException: replicate_on_write is not a column
defined in this metadata
at
org.apache.cassandra.stress.settings.StressSettings.getJavaDriverClient(StressSettings.java:142)
at
org.apache.cassandra.stress.settings.StressSettings.getSmartThriftClient(StressSettings.java:49)
at
org.apache.cassandra.stress.StressAction$Consumer.run(StressAction.java:273)
Caused by: java.lang.IllegalArgumentException: replicate_on_write is not a
column defined in this metadata
at
com.datastax.driver.core.ColumnDefinitions.getAllIdx(ColumnDefinitions.java:273)
at
com.datastax.driver.core.ColumnDefinitions.getFirstIdx(ColumnDefinitions.java:279)
at com.datastax.driver.core.Row.getBool(Row.java:117)
at
com.datastax.driver.core.TableMetadata$Options.init(TableMetadata.java:474)
at
com.datastax.driver.core.TableMetadata.build(TableMetadata.java:107)
at
com.datastax.driver.core.Metadata.buildTableMetadata(Metadata.java:128)
at com.datastax.driver.core.Metadata.rebuildSchema(Metadata.java:89)
at
com.datastax.driver.core.ControlConnection.refreshSchema(ControlConnection.java:259)
at
com.datastax.driver.core.ControlConnection.tryConnect(ControlConnection.java:214)
at
com.datastax.driver.core.ControlConnection.reconnectInternal(ControlConnection.java:161)
at
com.datastax.driver.core.ControlConnection.connect(ControlConnection.java:77)
at com.datastax.driver.core.Cluster$Manager.init(Cluster.java:890)
at
com.datastax.driver.core.Cluster$Manager.access$100(Cluster.java:806)
at com.datastax.driver.core.Cluster.getMetadata(Cluster.java:217)
at
org.apache.cassandra.stress.util.JavaDriverClient.connect(JavaDriverClient.java:75)
at
org.apache.cassandra.stress.settings.StressSettings.getJavaDriverClient(StressSettings.java:135)
... 2 more
Exception in thread Thread-19 java.lang.RuntimeException:
java.lang.IllegalArgumentException: replicate_on_write is not a column
defined in this metadata
at
org.apache.cassandra.stress.settings.StressSettings.getJavaDriverClient(StressSettings.java:142)
at
org.apache.cassandra.stress.settings.StressSettings.getSmartThriftClient(StressSettings.java:49)
at
org.apache.cassandra.stress.StressAction$Consumer.run(StressAction.java:273)
Caused by: java.lang.IllegalArgumentException: replicate_on_write is not a
column defined in this metadata
at
com.datastax.driver.core.ColumnDefinitions.getAllIdx(ColumnDefinitions.java:273)
at
com.datastax.driver.core.ColumnDefinitions.getFirstIdx(ColumnDefinitions.java:279)
at com.datastax.driver.core.Row.getBool(Row.java:117)
at
com.datastax.driver.core.TableMetadata$Options.init(TableMetadata.java:474)
at
com.datastax.driver.core.TableMetadata.build(TableMetadata.java:107)
at
com.datastax.driver.core.Metadata.buildTableMetadata(Metadata.java:128)
at com.datastax.driver.core.Metadata.rebuildSchema(Metadata.java:89)
at
com.datastax.driver.core.ControlConnection.refreshSchema(ControlConnection.java:259)
at
com.datastax.driver.core.ControlConnection.tryConnect(ControlConnection.java:214)
at
com.datastax.driver.core.ControlConnection.reconnectInternal(ControlConnection.java:161)
at
com.datastax.driver.core.ControlConnection.connect(ControlConnection.java:77)
at
[jira] [Commented] (CASSANDRA-6631) cassandra-stress failing in trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-6631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900386#comment-13900386
]
Benedict commented on CASSANDRA-6631:
-
Ah, I just needed to rebuild the project. Thanks
cassandra-stress failing in trunk
-
Key: CASSANDRA-6631
URL: https://issues.apache.org/jira/browse/CASSANDRA-6631
Project: Cassandra
Issue Type: Bug
Components: Tools
Environment: Debian Stable Wheezy
Oracle JDK 1.7.0_51-b13
Reporter: Michael Shuler
Fix For: 2.1
Stress is failing in trunk.
- ant clean jar
- ./bin/cassandra -f
- ./tools/bin/cassandra-stress write
{noformat}
(trunk)mshuler@hana:~/git/cassandra$ ./tools/bin/cassandra-stress write
Created keyspaces. Sleeping 1s for propagation.
Warming up WRITE with 5 iterations...
Exception in thread Thread-0 java.lang.RuntimeException:
java.lang.IllegalArgumentException: replicate_on_write is not a column
defined in this metadata
at
org.apache.cassandra.stress.settings.StressSettings.getJavaDriverClient(StressSettings.java:142)
at
org.apache.cassandra.stress.settings.StressSettings.getSmartThriftClient(StressSettings.java:49)
at
org.apache.cassandra.stress.StressAction$Consumer.run(StressAction.java:273)
Caused by: java.lang.IllegalArgumentException: replicate_on_write is not a
column defined in this metadata
at
com.datastax.driver.core.ColumnDefinitions.getAllIdx(ColumnDefinitions.java:273)
at
com.datastax.driver.core.ColumnDefinitions.getFirstIdx(ColumnDefinitions.java:279)
at com.datastax.driver.core.Row.getBool(Row.java:117)
at
com.datastax.driver.core.TableMetadata$Options.init(TableMetadata.java:474)
at
com.datastax.driver.core.TableMetadata.build(TableMetadata.java:107)
at
com.datastax.driver.core.Metadata.buildTableMetadata(Metadata.java:128)
at com.datastax.driver.core.Metadata.rebuildSchema(Metadata.java:89)
at
com.datastax.driver.core.ControlConnection.refreshSchema(ControlConnection.java:259)
at
com.datastax.driver.core.ControlConnection.tryConnect(ControlConnection.java:214)
at
com.datastax.driver.core.ControlConnection.reconnectInternal(ControlConnection.java:161)
at
com.datastax.driver.core.ControlConnection.connect(ControlConnection.java:77)
at com.datastax.driver.core.Cluster$Manager.init(Cluster.java:890)
at
com.datastax.driver.core.Cluster$Manager.access$100(Cluster.java:806)
at com.datastax.driver.core.Cluster.getMetadata(Cluster.java:217)
at
org.apache.cassandra.stress.util.JavaDriverClient.connect(JavaDriverClient.java:75)
at
org.apache.cassandra.stress.settings.StressSettings.getJavaDriverClient(StressSettings.java:135)
... 2 more
Exception in thread Thread-19 java.lang.RuntimeException:
java.lang.IllegalArgumentException: replicate_on_write is not a column
defined in this metadata
at
org.apache.cassandra.stress.settings.StressSettings.getJavaDriverClient(StressSettings.java:142)
at
org.apache.cassandra.stress.settings.StressSettings.getSmartThriftClient(StressSettings.java:49)
at
org.apache.cassandra.stress.StressAction$Consumer.run(StressAction.java:273)
Caused by: java.lang.IllegalArgumentException: replicate_on_write is not a
column defined in this metadata
at
com.datastax.driver.core.ColumnDefinitions.getAllIdx(ColumnDefinitions.java:273)
at
com.datastax.driver.core.ColumnDefinitions.getFirstIdx(ColumnDefinitions.java:279)
at com.datastax.driver.core.Row.getBool(Row.java:117)
at
com.datastax.driver.core.TableMetadata$Options.init(TableMetadata.java:474)
at
com.datastax.driver.core.TableMetadata.build(TableMetadata.java:107)
at
com.datastax.driver.core.Metadata.buildTableMetadata(Metadata.java:128)
at com.datastax.driver.core.Metadata.rebuildSchema(Metadata.java:89)
at
com.datastax.driver.core.ControlConnection.refreshSchema(ControlConnection.java:259)
at
com.datastax.driver.core.ControlConnection.tryConnect(ControlConnection.java:214)
at
com.datastax.driver.core.ControlConnection.reconnectInternal(ControlConnection.java:161)
at
com.datastax.driver.core.ControlConnection.connect(ControlConnection.java:77)
at com.datastax.driver.core.Cluster$Manager.init(Cluster.java:890)
at
com.datastax.driver.core.Cluster$Manager.access$100(Cluster.java:806)
at com.datastax.driver.core.Cluster.getMetadata(Cluster.java:217)
at
org.apache.cassandra.stress.util.JavaDriverClient.connect(JavaDriverClient.java:75)
at
[jira] [Commented] (CASSANDRA-6631) cassandra-stress failing in trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-6631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900380#comment-13900380
]
Benedict commented on CASSANDRA-6631:
-
bq. What problem do you see?
{quote}
Exception in thread Thread-22 java.lang.NoClassDefFoundError:
com/codahale/metrics/Metric
at com.datastax.driver.core.Cluster$Manager.init(Cluster.java:940)
at com.datastax.driver.core.Cluster$Manager.init(Cluster.java:885)
at com.datastax.driver.core.Cluster.init(Cluster.java:88)
at com.datastax.driver.core.Cluster.buildFrom(Cluster.java:144)
at com.datastax.driver.core.Cluster$Builder.build(Cluster.java:850)
at
org.apache.cassandra.stress.util.JavaDriverClient.connect(JavaDriverClient.java:74)
at
org.apache.cassandra.stress.settings.StressSettings.getJavaDriverClient(StressSettings.java:134)
at
org.apache.cassandra.stress.settings.StressSettings.getSmartThriftClient(StressSettings.java:49)
at
org.apache.cassandra.stress.StressAction$Consumer.run(StressAction.java:277)
Caused by: java.lang.ClassNotFoundException: com.codahale.metrics.Metric
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
{quote}
bq. This does mean that the stress should include the C* lib/ jars in the
classpath
Right, I'll have a look at the script and check what's happening
cassandra-stress failing in trunk
-
Key: CASSANDRA-6631
URL: https://issues.apache.org/jira/browse/CASSANDRA-6631
Project: Cassandra
Issue Type: Bug
Components: Tools
Environment: Debian Stable Wheezy
Oracle JDK 1.7.0_51-b13
Reporter: Michael Shuler
Fix For: 2.1
Stress is failing in trunk.
- ant clean jar
- ./bin/cassandra -f
- ./tools/bin/cassandra-stress write
{noformat}
(trunk)mshuler@hana:~/git/cassandra$ ./tools/bin/cassandra-stress write
Created keyspaces. Sleeping 1s for propagation.
Warming up WRITE with 5 iterations...
Exception in thread Thread-0 java.lang.RuntimeException:
java.lang.IllegalArgumentException: replicate_on_write is not a column
defined in this metadata
at
org.apache.cassandra.stress.settings.StressSettings.getJavaDriverClient(StressSettings.java:142)
at
org.apache.cassandra.stress.settings.StressSettings.getSmartThriftClient(StressSettings.java:49)
at
org.apache.cassandra.stress.StressAction$Consumer.run(StressAction.java:273)
Caused by: java.lang.IllegalArgumentException: replicate_on_write is not a
column defined in this metadata
at
com.datastax.driver.core.ColumnDefinitions.getAllIdx(ColumnDefinitions.java:273)
at
com.datastax.driver.core.ColumnDefinitions.getFirstIdx(ColumnDefinitions.java:279)
at com.datastax.driver.core.Row.getBool(Row.java:117)
at
com.datastax.driver.core.TableMetadata$Options.init(TableMetadata.java:474)
at
com.datastax.driver.core.TableMetadata.build(TableMetadata.java:107)
at
com.datastax.driver.core.Metadata.buildTableMetadata(Metadata.java:128)
at com.datastax.driver.core.Metadata.rebuildSchema(Metadata.java:89)
at
com.datastax.driver.core.ControlConnection.refreshSchema(ControlConnection.java:259)
at
com.datastax.driver.core.ControlConnection.tryConnect(ControlConnection.java:214)
at
com.datastax.driver.core.ControlConnection.reconnectInternal(ControlConnection.java:161)
at
com.datastax.driver.core.ControlConnection.connect(ControlConnection.java:77)
at com.datastax.driver.core.Cluster$Manager.init(Cluster.java:890)
at
com.datastax.driver.core.Cluster$Manager.access$100(Cluster.java:806)
at com.datastax.driver.core.Cluster.getMetadata(Cluster.java:217)
at
org.apache.cassandra.stress.util.JavaDriverClient.connect(JavaDriverClient.java:75)
at
org.apache.cassandra.stress.settings.StressSettings.getJavaDriverClient(StressSettings.java:135)
... 2 more
Exception in thread Thread-19 java.lang.RuntimeException:
java.lang.IllegalArgumentException: replicate_on_write is not a column
defined in this metadata
at
org.apache.cassandra.stress.settings.StressSettings.getJavaDriverClient(StressSettings.java:142)
at
org.apache.cassandra.stress.settings.StressSettings.getSmartThriftClient(StressSettings.java:49)
at
[jira] [Updated] (CASSANDRA-6700) When considering schema pull/push, use the real version of the peer
[ https://issues.apache.org/jira/browse/CASSANDRA-6700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-6700: - Attachment: 6700.txt When considering schema pull/push, use the real version of the peer --- Key: CASSANDRA-6700 URL: https://issues.apache.org/jira/browse/CASSANDRA-6700 Project: Cassandra Issue Type: Bug Components: Core Reporter: Piotr Kołaczkowski Assignee: Aleksey Yeschenko Attachments: 6700.txt -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CASSANDRA-6700) When considering schema pull/push, use the real version of the peer
Piotr Kołaczkowski created CASSANDRA-6700: - Summary: When considering schema pull/push, use the real version of the peer Key: CASSANDRA-6700 URL: https://issues.apache.org/jira/browse/CASSANDRA-6700 Project: Cassandra Issue Type: Bug Components: Core Reporter: Piotr Kołaczkowski Assignee: Aleksey Yeschenko Attachments: 6700.txt -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6700) When considering schema pull/push, use the real version of the peer
[ https://issues.apache.org/jira/browse/CASSANDRA-6700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Kołaczkowski updated CASSANDRA-6700: -- Description: IncomingTcpConnection#handleModernVersion sets version to min(my version, version of the peer). This messes up schema pull/push. (was: IncomingTcpConnection#handleModernVersion sets version to min(myVersion, version of the peer). This messes up schema pull/push.) When considering schema pull/push, use the real version of the peer --- Key: CASSANDRA-6700 URL: https://issues.apache.org/jira/browse/CASSANDRA-6700 Project: Cassandra Issue Type: Bug Components: Core Reporter: Piotr Kołaczkowski Assignee: Aleksey Yeschenko Attachments: 6700.txt IncomingTcpConnection#handleModernVersion sets version to min(my version, version of the peer). This messes up schema pull/push. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6700) When considering schema pull/push, use the real version of the peer
[ https://issues.apache.org/jira/browse/CASSANDRA-6700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Kołaczkowski updated CASSANDRA-6700: -- Description: IncomingTcpConnection#handleModernVersion sets version to min(myVersion, version of the peer). This messes up schema pull/push. When considering schema pull/push, use the real version of the peer --- Key: CASSANDRA-6700 URL: https://issues.apache.org/jira/browse/CASSANDRA-6700 Project: Cassandra Issue Type: Bug Components: Core Reporter: Piotr Kołaczkowski Assignee: Aleksey Yeschenko Attachments: 6700.txt IncomingTcpConnection#handleModernVersion sets version to min(myVersion, version of the peer). This messes up schema pull/push. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6700) When considering schema pull/push, use the real version of the peer
[ https://issues.apache.org/jira/browse/CASSANDRA-6700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Kołaczkowski updated CASSANDRA-6700: -- Reviewer: Piotr Kołaczkowski When considering schema pull/push, use the real version of the peer --- Key: CASSANDRA-6700 URL: https://issues.apache.org/jira/browse/CASSANDRA-6700 Project: Cassandra Issue Type: Bug Components: Core Reporter: Piotr Kołaczkowski Assignee: Aleksey Yeschenko Attachments: 6700.txt IncomingTcpConnection#handleModernVersion sets version to min(my version, version of the peer). This messes up schema pull/push. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6700) When considering schema pull/push, use the real version of the peer
[ https://issues.apache.org/jira/browse/CASSANDRA-6700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900462#comment-13900462 ] Piotr Kołaczkowski commented on CASSANDRA-6700: --- +1 LGTM When considering schema pull/push, use the real version of the peer --- Key: CASSANDRA-6700 URL: https://issues.apache.org/jira/browse/CASSANDRA-6700 Project: Cassandra Issue Type: Bug Components: Core Reporter: Piotr Kołaczkowski Assignee: Aleksey Yeschenko Attachments: 6700.txt IncomingTcpConnection#handleModernVersion sets version to min(my version, version of the peer). This messes up schema pull/push. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
git commit: Use real node messaging versions for schema exchange decisions
Updated Branches:
refs/heads/cassandra-1.2 b2dfaed31 - de72e7fc0
Use real node messaging versions for schema exchange decisions
patch by Aleksey Yeschenko; reviewed by Piotr KoÅaczkowski for
CASSANDRA-6700
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/de72e7fc
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/de72e7fc
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/de72e7fc
Branch: refs/heads/cassandra-1.2
Commit: de72e7fc0a750fdb2fcd752092e5a07a7f47046e
Parents: b2dfaed
Author: Aleksey Yeschenko alek...@apache.org
Authored: Thu Feb 13 19:26:48 2014 +0300
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Thu Feb 13 19:26:48 2014 +0300
--
CHANGES.txt | 1 +
.../cassandra/net/IncomingTcpConnection.java| 4 +--
.../apache/cassandra/net/MessagingService.java | 28 +---
.../cassandra/service/MigrationManager.java | 4 +--
4 files changed, 23 insertions(+), 14 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/de72e7fc/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index de7c307..872934a 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -6,6 +6,7 @@
* Compact hints after partial replay to clean out tombstones (CASSANDRA-)
* Log USING TTL/TIMESTAMP in a counter update warning (CASSANDRA-6649)
* Don't exchange schema between nodes with different versions (CASSANDRA-6695)
+ * Use real node messaging versions for schema exchange decisions
(CASSANDRA-6700)
1.2.15
http://git-wip-us.apache.org/repos/asf/cassandra/blob/de72e7fc/src/java/org/apache/cassandra/net/IncomingTcpConnection.java
--
diff --git a/src/java/org/apache/cassandra/net/IncomingTcpConnection.java
b/src/java/org/apache/cassandra/net/IncomingTcpConnection.java
index 3b24a7f..d0126c7 100644
--- a/src/java/org/apache/cassandra/net/IncomingTcpConnection.java
+++ b/src/java/org/apache/cassandra/net/IncomingTcpConnection.java
@@ -130,8 +130,8 @@ public class IncomingTcpConnection extends Thread
logger.info(Received messages from newer protocol version {}.
Ignoring, version);
return;
}
-MessagingService.instance().setVersion(from,
Math.min(MessagingService.current_version, maxVersion));
-logger.debug(set version for {} to {}, from,
Math.min(MessagingService.current_version, maxVersion));
+MessagingService.instance().setVersion(from, maxVersion);
+logger.debug(Set version for {} to {} (will use {}), from,
maxVersion, Math.min(MessagingService.current_version, maxVersion));
// outbound side will reconnect if necessary to upgrade version
while (true)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/de72e7fc/src/java/org/apache/cassandra/net/MessagingService.java
--
diff --git a/src/java/org/apache/cassandra/net/MessagingService.java
b/src/java/org/apache/cassandra/net/MessagingService.java
index bfc3957..09fa272 100644
--- a/src/java/org/apache/cassandra/net/MessagingService.java
+++ b/src/java/org/apache/cassandra/net/MessagingService.java
@@ -800,10 +800,10 @@ public final class MessagingService implements
MessagingServiceMBean
/**
* @return the last version associated with address, or @param version if
this is the first such version
*/
-public int setVersion(InetAddress address, int version)
+public int setVersion(InetAddress endpoint, int version)
{
-logger.debug(Setting version {} for {}, version, address);
-Integer v = versions.put(address, version);
+logger.debug(Setting version {} for {}, version, endpoint);
+Integer v = versions.put(endpoint, version);
return v == null ? version : v;
}
@@ -813,27 +813,35 @@ public final class MessagingService implements
MessagingServiceMBean
versions.remove(endpoint);
}
-public Integer getVersion(InetAddress address)
+public int getVersion(InetAddress endpoint)
{
-Integer v = versions.get(address);
+Integer v = versions.get(endpoint);
if (v == null)
{
// we don't know the version. assume current. we'll know soon
enough if that was incorrect.
-logger.trace(Assuming current protocol version for {}, address);
+logger.trace(Assuming current protocol version for {}, endpoint);
return MessagingService.current_version;
}
else
-return v;
+return Math.min(v, MessagingService.current_version);
}
-public int getVersion(String address)
[jira] [Updated] (CASSANDRA-6700) Use real node messaging versions for schema exchange decisions
[ https://issues.apache.org/jira/browse/CASSANDRA-6700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-6700: - Summary: Use real node messaging versions for schema exchange decisions (was: When considering schema pull/push, use the real version of the peer) Use real node messaging versions for schema exchange decisions -- Key: CASSANDRA-6700 URL: https://issues.apache.org/jira/browse/CASSANDRA-6700 Project: Cassandra Issue Type: Bug Components: Core Reporter: Piotr Kołaczkowski Assignee: Aleksey Yeschenko Attachments: 6700.txt IncomingTcpConnection#handleModernVersion sets version to min(my version, version of the peer). This messes up schema pull/push. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[1/3] git commit: Use real node messaging versions for schema exchange decisions
Updated Branches:
refs/heads/trunk 79c6e - 21de3328a
Use real node messaging versions for schema exchange decisions
patch by Aleksey Yeschenko; reviewed by Piotr KoÅaczkowski for
CASSANDRA-6700
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/de72e7fc
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/de72e7fc
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/de72e7fc
Branch: refs/heads/trunk
Commit: de72e7fc0a750fdb2fcd752092e5a07a7f47046e
Parents: b2dfaed
Author: Aleksey Yeschenko alek...@apache.org
Authored: Thu Feb 13 19:26:48 2014 +0300
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Thu Feb 13 19:26:48 2014 +0300
--
CHANGES.txt | 1 +
.../cassandra/net/IncomingTcpConnection.java| 4 +--
.../apache/cassandra/net/MessagingService.java | 28 +---
.../cassandra/service/MigrationManager.java | 4 +--
4 files changed, 23 insertions(+), 14 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/de72e7fc/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index de7c307..872934a 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -6,6 +6,7 @@
* Compact hints after partial replay to clean out tombstones (CASSANDRA-)
* Log USING TTL/TIMESTAMP in a counter update warning (CASSANDRA-6649)
* Don't exchange schema between nodes with different versions (CASSANDRA-6695)
+ * Use real node messaging versions for schema exchange decisions
(CASSANDRA-6700)
1.2.15
http://git-wip-us.apache.org/repos/asf/cassandra/blob/de72e7fc/src/java/org/apache/cassandra/net/IncomingTcpConnection.java
--
diff --git a/src/java/org/apache/cassandra/net/IncomingTcpConnection.java
b/src/java/org/apache/cassandra/net/IncomingTcpConnection.java
index 3b24a7f..d0126c7 100644
--- a/src/java/org/apache/cassandra/net/IncomingTcpConnection.java
+++ b/src/java/org/apache/cassandra/net/IncomingTcpConnection.java
@@ -130,8 +130,8 @@ public class IncomingTcpConnection extends Thread
logger.info(Received messages from newer protocol version {}.
Ignoring, version);
return;
}
-MessagingService.instance().setVersion(from,
Math.min(MessagingService.current_version, maxVersion));
-logger.debug(set version for {} to {}, from,
Math.min(MessagingService.current_version, maxVersion));
+MessagingService.instance().setVersion(from, maxVersion);
+logger.debug(Set version for {} to {} (will use {}), from,
maxVersion, Math.min(MessagingService.current_version, maxVersion));
// outbound side will reconnect if necessary to upgrade version
while (true)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/de72e7fc/src/java/org/apache/cassandra/net/MessagingService.java
--
diff --git a/src/java/org/apache/cassandra/net/MessagingService.java
b/src/java/org/apache/cassandra/net/MessagingService.java
index bfc3957..09fa272 100644
--- a/src/java/org/apache/cassandra/net/MessagingService.java
+++ b/src/java/org/apache/cassandra/net/MessagingService.java
@@ -800,10 +800,10 @@ public final class MessagingService implements
MessagingServiceMBean
/**
* @return the last version associated with address, or @param version if
this is the first such version
*/
-public int setVersion(InetAddress address, int version)
+public int setVersion(InetAddress endpoint, int version)
{
-logger.debug(Setting version {} for {}, version, address);
-Integer v = versions.put(address, version);
+logger.debug(Setting version {} for {}, version, endpoint);
+Integer v = versions.put(endpoint, version);
return v == null ? version : v;
}
@@ -813,27 +813,35 @@ public final class MessagingService implements
MessagingServiceMBean
versions.remove(endpoint);
}
-public Integer getVersion(InetAddress address)
+public int getVersion(InetAddress endpoint)
{
-Integer v = versions.get(address);
+Integer v = versions.get(endpoint);
if (v == null)
{
// we don't know the version. assume current. we'll know soon
enough if that was incorrect.
-logger.trace(Assuming current protocol version for {}, address);
+logger.trace(Assuming current protocol version for {}, endpoint);
return MessagingService.current_version;
}
else
-return v;
+return Math.min(v, MessagingService.current_version);
}
-public int getVersion(String address) throws
[2/3] git commit: Merge branch 'cassandra-1.2' into cassandra-2.0
Merge branch 'cassandra-1.2' into cassandra-2.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/78df8a33 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/78df8a33 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/78df8a33 Branch: refs/heads/trunk Commit: 78df8a33caf864c51ba2a10cb04f77ac6b043bfc Parents: 15ee948 de72e7f Author: Aleksey Yeschenko alek...@apache.org Authored: Thu Feb 13 19:32:03 2014 +0300 Committer: Aleksey Yeschenko alek...@apache.org Committed: Thu Feb 13 19:32:03 2014 +0300 -- CHANGES.txt | 1 + .../cassandra/net/IncomingTcpConnection.java| 4 +-- .../apache/cassandra/net/MessagingService.java | 28 +--- .../cassandra/service/MigrationManager.java | 4 +-- 4 files changed, 23 insertions(+), 14 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/78df8a33/CHANGES.txt -- diff --cc CHANGES.txt index 9509a76,872934a..7425625 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -20,33 -6,24 +20,34 @@@ Merged from 1.2 * Compact hints after partial replay to clean out tombstones (CASSANDRA-) * Log USING TTL/TIMESTAMP in a counter update warning (CASSANDRA-6649) * Don't exchange schema between nodes with different versions (CASSANDRA-6695) + * Use real node messaging versions for schema exchange decisions (CASSANDRA-6700) - -1.2.15 - * Move handling of migration event source to solve bootstrap race (CASSANDRA-6648) - * Make sure compaction throughput value doesn't overflow with int math (CASSANDRA-6647) - - -1.2.14 - * Reverted code to limit CQL prepared statement cache by size (CASSANDRA-6592) - * add cassandra.default_messaging_version property to allow easier - upgrading from 1.1 (CASSANDRA-6619) - * Allow executing CREATE statements multiple times (CASSANDRA-6471) - * Don't send confusing info with timeouts (CASSANDRA-6491) - * Don't resubmit counter mutation runnables internally (CASSANDRA-6427) - * Don't drop local mutations without a hint (CASSANDRA-6510) - * Don't allow null max_hint_window_in_ms (CASSANDRA-6419) - * Validate SliceRange start and finish lengths (CASSANDRA-6521) +2.0.5 + * Reduce garbage generated by bloom filter lookups (CASSANDRA-6609) + * Add ks.cf names to tombstone logging (CASSANDRA-6597) + * Use LOCAL_QUORUM for LWT operations at LOCAL_SERIAL (CASSANDRA-6495) + * Wait for gossip to settle before accepting client connections (CASSANDRA-4288) + * Delete unfinished compaction incrementally (CASSANDRA-6086) + * Allow specifying custom secondary index options in CQL3 (CASSANDRA-6480) + * Improve replica pinning for cache efficiency in DES (CASSANDRA-6485) + * Fix LOCAL_SERIAL from thrift (CASSANDRA-6584) + * Don't special case received counts in CAS timeout exceptions (CASSANDRA-6595) + * Add support for 2.1 global counter shards (CASSANDRA-6505) + * Fix NPE when streaming connection is not yet established (CASSANDRA-6210) + * Avoid rare duplicate read repair triggering (CASSANDRA-6606) + * Fix paging discardFirst (CASSANDRA-6555) + * Fix ArrayIndexOutOfBoundsException in 2ndary index query (CASSANDRA-6470) + * Release sstables upon rebuilding 2i (CASSANDRA-6635) + * Add AbstractCompactionStrategy.startup() method (CASSANDRA-6637) + * SSTableScanner may skip rows during cleanup (CASSANDRA-6638) + * sstables from stalled repair sessions can resurrect deleted data (CASSANDRA-6503) + * Switch stress to use ITransportFactory (CASSANDRA-6641) + * Fix IllegalArgumentException during prepare (CASSANDRA-6592) + * Fix possible loss of 2ndary index entries during compaction (CASSANDRA-6517) + * Fix direct Memory on architectures that do not support unaligned long access + (CASSANDRA-6628) + * Let scrub optionally skip broken counter partitions (CASSANDRA-5930) +Merged from 1.2: * fsync compression metadata (CASSANDRA-6531) * Validate CF existence on execution for prepared statement (CASSANDRA-6535) * Add ability to throttle batchlog replay (CASSANDRA-6550) http://git-wip-us.apache.org/repos/asf/cassandra/blob/78df8a33/src/java/org/apache/cassandra/net/IncomingTcpConnection.java -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/78df8a33/src/java/org/apache/cassandra/net/MessagingService.java -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/78df8a33/src/java/org/apache/cassandra/service/MigrationManager.java --
[2/2] git commit: Merge branch 'cassandra-1.2' into cassandra-2.0
Merge branch 'cassandra-1.2' into cassandra-2.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/78df8a33 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/78df8a33 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/78df8a33 Branch: refs/heads/cassandra-2.0 Commit: 78df8a33caf864c51ba2a10cb04f77ac6b043bfc Parents: 15ee948 de72e7f Author: Aleksey Yeschenko alek...@apache.org Authored: Thu Feb 13 19:32:03 2014 +0300 Committer: Aleksey Yeschenko alek...@apache.org Committed: Thu Feb 13 19:32:03 2014 +0300 -- CHANGES.txt | 1 + .../cassandra/net/IncomingTcpConnection.java| 4 +-- .../apache/cassandra/net/MessagingService.java | 28 +--- .../cassandra/service/MigrationManager.java | 4 +-- 4 files changed, 23 insertions(+), 14 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/78df8a33/CHANGES.txt -- diff --cc CHANGES.txt index 9509a76,872934a..7425625 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -20,33 -6,24 +20,34 @@@ Merged from 1.2 * Compact hints after partial replay to clean out tombstones (CASSANDRA-) * Log USING TTL/TIMESTAMP in a counter update warning (CASSANDRA-6649) * Don't exchange schema between nodes with different versions (CASSANDRA-6695) + * Use real node messaging versions for schema exchange decisions (CASSANDRA-6700) - -1.2.15 - * Move handling of migration event source to solve bootstrap race (CASSANDRA-6648) - * Make sure compaction throughput value doesn't overflow with int math (CASSANDRA-6647) - - -1.2.14 - * Reverted code to limit CQL prepared statement cache by size (CASSANDRA-6592) - * add cassandra.default_messaging_version property to allow easier - upgrading from 1.1 (CASSANDRA-6619) - * Allow executing CREATE statements multiple times (CASSANDRA-6471) - * Don't send confusing info with timeouts (CASSANDRA-6491) - * Don't resubmit counter mutation runnables internally (CASSANDRA-6427) - * Don't drop local mutations without a hint (CASSANDRA-6510) - * Don't allow null max_hint_window_in_ms (CASSANDRA-6419) - * Validate SliceRange start and finish lengths (CASSANDRA-6521) +2.0.5 + * Reduce garbage generated by bloom filter lookups (CASSANDRA-6609) + * Add ks.cf names to tombstone logging (CASSANDRA-6597) + * Use LOCAL_QUORUM for LWT operations at LOCAL_SERIAL (CASSANDRA-6495) + * Wait for gossip to settle before accepting client connections (CASSANDRA-4288) + * Delete unfinished compaction incrementally (CASSANDRA-6086) + * Allow specifying custom secondary index options in CQL3 (CASSANDRA-6480) + * Improve replica pinning for cache efficiency in DES (CASSANDRA-6485) + * Fix LOCAL_SERIAL from thrift (CASSANDRA-6584) + * Don't special case received counts in CAS timeout exceptions (CASSANDRA-6595) + * Add support for 2.1 global counter shards (CASSANDRA-6505) + * Fix NPE when streaming connection is not yet established (CASSANDRA-6210) + * Avoid rare duplicate read repair triggering (CASSANDRA-6606) + * Fix paging discardFirst (CASSANDRA-6555) + * Fix ArrayIndexOutOfBoundsException in 2ndary index query (CASSANDRA-6470) + * Release sstables upon rebuilding 2i (CASSANDRA-6635) + * Add AbstractCompactionStrategy.startup() method (CASSANDRA-6637) + * SSTableScanner may skip rows during cleanup (CASSANDRA-6638) + * sstables from stalled repair sessions can resurrect deleted data (CASSANDRA-6503) + * Switch stress to use ITransportFactory (CASSANDRA-6641) + * Fix IllegalArgumentException during prepare (CASSANDRA-6592) + * Fix possible loss of 2ndary index entries during compaction (CASSANDRA-6517) + * Fix direct Memory on architectures that do not support unaligned long access + (CASSANDRA-6628) + * Let scrub optionally skip broken counter partitions (CASSANDRA-5930) +Merged from 1.2: * fsync compression metadata (CASSANDRA-6531) * Validate CF existence on execution for prepared statement (CASSANDRA-6535) * Add ability to throttle batchlog replay (CASSANDRA-6550) http://git-wip-us.apache.org/repos/asf/cassandra/blob/78df8a33/src/java/org/apache/cassandra/net/IncomingTcpConnection.java -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/78df8a33/src/java/org/apache/cassandra/net/MessagingService.java -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/78df8a33/src/java/org/apache/cassandra/service/MigrationManager.java --
[1/2] git commit: Use real node messaging versions for schema exchange decisions
Updated Branches:
refs/heads/cassandra-2.0 15ee94897 - 78df8a33c
Use real node messaging versions for schema exchange decisions
patch by Aleksey Yeschenko; reviewed by Piotr KoÅaczkowski for
CASSANDRA-6700
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/de72e7fc
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/de72e7fc
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/de72e7fc
Branch: refs/heads/cassandra-2.0
Commit: de72e7fc0a750fdb2fcd752092e5a07a7f47046e
Parents: b2dfaed
Author: Aleksey Yeschenko alek...@apache.org
Authored: Thu Feb 13 19:26:48 2014 +0300
Committer: Aleksey Yeschenko alek...@apache.org
Committed: Thu Feb 13 19:26:48 2014 +0300
--
CHANGES.txt | 1 +
.../cassandra/net/IncomingTcpConnection.java| 4 +--
.../apache/cassandra/net/MessagingService.java | 28 +---
.../cassandra/service/MigrationManager.java | 4 +--
4 files changed, 23 insertions(+), 14 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/de72e7fc/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index de7c307..872934a 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -6,6 +6,7 @@
* Compact hints after partial replay to clean out tombstones (CASSANDRA-)
* Log USING TTL/TIMESTAMP in a counter update warning (CASSANDRA-6649)
* Don't exchange schema between nodes with different versions (CASSANDRA-6695)
+ * Use real node messaging versions for schema exchange decisions
(CASSANDRA-6700)
1.2.15
http://git-wip-us.apache.org/repos/asf/cassandra/blob/de72e7fc/src/java/org/apache/cassandra/net/IncomingTcpConnection.java
--
diff --git a/src/java/org/apache/cassandra/net/IncomingTcpConnection.java
b/src/java/org/apache/cassandra/net/IncomingTcpConnection.java
index 3b24a7f..d0126c7 100644
--- a/src/java/org/apache/cassandra/net/IncomingTcpConnection.java
+++ b/src/java/org/apache/cassandra/net/IncomingTcpConnection.java
@@ -130,8 +130,8 @@ public class IncomingTcpConnection extends Thread
logger.info(Received messages from newer protocol version {}.
Ignoring, version);
return;
}
-MessagingService.instance().setVersion(from,
Math.min(MessagingService.current_version, maxVersion));
-logger.debug(set version for {} to {}, from,
Math.min(MessagingService.current_version, maxVersion));
+MessagingService.instance().setVersion(from, maxVersion);
+logger.debug(Set version for {} to {} (will use {}), from,
maxVersion, Math.min(MessagingService.current_version, maxVersion));
// outbound side will reconnect if necessary to upgrade version
while (true)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/de72e7fc/src/java/org/apache/cassandra/net/MessagingService.java
--
diff --git a/src/java/org/apache/cassandra/net/MessagingService.java
b/src/java/org/apache/cassandra/net/MessagingService.java
index bfc3957..09fa272 100644
--- a/src/java/org/apache/cassandra/net/MessagingService.java
+++ b/src/java/org/apache/cassandra/net/MessagingService.java
@@ -800,10 +800,10 @@ public final class MessagingService implements
MessagingServiceMBean
/**
* @return the last version associated with address, or @param version if
this is the first such version
*/
-public int setVersion(InetAddress address, int version)
+public int setVersion(InetAddress endpoint, int version)
{
-logger.debug(Setting version {} for {}, version, address);
-Integer v = versions.put(address, version);
+logger.debug(Setting version {} for {}, version, endpoint);
+Integer v = versions.put(endpoint, version);
return v == null ? version : v;
}
@@ -813,27 +813,35 @@ public final class MessagingService implements
MessagingServiceMBean
versions.remove(endpoint);
}
-public Integer getVersion(InetAddress address)
+public int getVersion(InetAddress endpoint)
{
-Integer v = versions.get(address);
+Integer v = versions.get(endpoint);
if (v == null)
{
// we don't know the version. assume current. we'll know soon
enough if that was incorrect.
-logger.trace(Assuming current protocol version for {}, address);
+logger.trace(Assuming current protocol version for {}, endpoint);
return MessagingService.current_version;
}
else
-return v;
+return Math.min(v, MessagingService.current_version);
}
-public int getVersion(String address)
[3/3] git commit: Merge branch 'cassandra-2.0' into trunk
Merge branch 'cassandra-2.0' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/21de3328 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/21de3328 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/21de3328 Branch: refs/heads/trunk Commit: 21de3328aad87e10ad4301b1c198022e57fecaa8 Parents: 79c6ecc 78df8a3 Author: Aleksey Yeschenko alek...@apache.org Authored: Thu Feb 13 19:34:31 2014 +0300 Committer: Aleksey Yeschenko alek...@apache.org Committed: Thu Feb 13 19:34:31 2014 +0300 -- CHANGES.txt | 1 + .../cassandra/net/IncomingTcpConnection.java| 4 +-- .../apache/cassandra/net/MessagingService.java | 28 +--- .../cassandra/service/MigrationManager.java | 4 +-- 4 files changed, 23 insertions(+), 14 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/21de3328/CHANGES.txt -- diff --cc CHANGES.txt index 139eb06,7425625..0af --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -52,8 -20,8 +52,9 @@@ Merged from 1.2 * Compact hints after partial replay to clean out tombstones (CASSANDRA-) * Log USING TTL/TIMESTAMP in a counter update warning (CASSANDRA-6649) * Don't exchange schema between nodes with different versions (CASSANDRA-6695) + * Use real node messaging versions for schema exchange decisions (CASSANDRA-6700) + 2.0.5 * Reduce garbage generated by bloom filter lookups (CASSANDRA-6609) * Add ks.cf names to tombstone logging (CASSANDRA-6597) http://git-wip-us.apache.org/repos/asf/cassandra/blob/21de3328/src/java/org/apache/cassandra/net/IncomingTcpConnection.java -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/21de3328/src/java/org/apache/cassandra/net/MessagingService.java -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/21de3328/src/java/org/apache/cassandra/service/MigrationManager.java --
[jira] [Commented] (CASSANDRA-6691) Improvements and FIxes to Stress
[ https://issues.apache.org/jira/browse/CASSANDRA-6691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900486#comment-13900486 ] Benedict commented on CASSANDRA-6691: - Hi [~xedin], Unfortunately I screwed up this commit slightly (like most of those I submitted yesterday...) The new feature of checking the data returned was correct was simply no-op'ing. I've updated my repository with the simple fix (and merged with your changes to trunk). Improvements and FIxes to Stress Key: CASSANDRA-6691 URL: https://issues.apache.org/jira/browse/CASSANDRA-6691 Project: Cassandra Issue Type: Bug Components: Tools Reporter: Benedict Assignee: Benedict Priority: Minor Fix For: 2.1 There were a couple of minor issues with the new stress: 1) The warmup period did not scale up as the cluster size increased 2) The mixed workload did not work with CQL At the same time, I have introduced a change in behaviour in the way the default column values are generated so that they are deterministically based on the key. I have then modified read operations to verify that the data they fetch is the same as should have been inserted, so that stress does some degree of data quality checking at the same time. For the moment the values generated never vary for a given key, so this does nothing to test consistency, it only tests for corruption. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CASSANDRA-6701) IN on the last clustering columns + ORDER BY DESC yield no results
Sylvain Lebresne created CASSANDRA-6701:
---
Summary: IN on the last clustering columns + ORDER BY DESC yield
no results
Key: CASSANDRA-6701
URL: https://issues.apache.org/jira/browse/CASSANDRA-6701
Project: Cassandra
Issue Type: Bug
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 1.2.16
Attachments: 6701.txt
That's not a very common mix but well, the following return no results which is
obviously bogus:
{noformat}
CREATE TABLE test (k int, c1 int, c2 int, PRIMARY KEY (k, c1, c2));
INSERT INTO test(k, c1, c2) VALUES (0, 0, 0);
INSERT INTO test(k, c1, c2) VALUES (0, 0, 1);
INSERT INTO test(k, c1, c2) VALUES (0, 0, 2);
SELECT * FROM test WHERE k=0 AND c1 = 0 AND c2 IN (2, 0) ORDER BY c1 DESC
{noformat}
Note: it's pretty useless to order on a column which has an equal restriction,
and that's probably why nobody ran into this yet, but that's really just due to
a minor typo so there is no reason not to fix.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6701) IN on the last clustering columns + ORDER BY DESC yield no results
[
https://issues.apache.org/jira/browse/CASSANDRA-6701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-6701:
Attachment: 6701.txt
Attaching trivial patch. I've pushed the example above as a dtest too.
IN on the last clustering columns + ORDER BY DESC yield no results
--
Key: CASSANDRA-6701
URL: https://issues.apache.org/jira/browse/CASSANDRA-6701
Project: Cassandra
Issue Type: Bug
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 1.2.16
Attachments: 6701.txt
That's not a very common mix but well, the following return no results which
is obviously bogus:
{noformat}
CREATE TABLE test (k int, c1 int, c2 int, PRIMARY KEY (k, c1, c2));
INSERT INTO test(k, c1, c2) VALUES (0, 0, 0);
INSERT INTO test(k, c1, c2) VALUES (0, 0, 1);
INSERT INTO test(k, c1, c2) VALUES (0, 0, 2);
SELECT * FROM test WHERE k=0 AND c1 = 0 AND c2 IN (2, 0) ORDER BY c1 DESC
{noformat}
Note: it's pretty useless to order on a column which has an equal
restriction, and that's probably why nobody ran into this yet, but that's
really just due to a minor typo so there is no reason not to fix.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6685) Nodes never bootstrap if schema is empty
[
https://issues.apache.org/jira/browse/CASSANDRA-6685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900491#comment-13900491
]
Richard Low commented on CASSANDRA-6685:
Here's the git commit:
https://github.com/apache/cassandra/commit/c5627008a2c87ab960da98f4d5b8ca4aca6eebdd
Nodes never bootstrap if schema is empty
Key: CASSANDRA-6685
URL: https://issues.apache.org/jira/browse/CASSANDRA-6685
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Richard Low
Assignee: Brandon Williams
Fix For: 1.2.16
Since 1.2.15, bootstrap never completes if the schema is empty. The
bootstrapping node endlessly prints:
bq. {{INFO 12:37:44,863 JOINING: waiting for schema information to complete}}
until you add something to the schema (i.e. create a keyspace).
The problem looks to be caused by CASSANDRA-6648, where
MigrationManager.isReadForBootstrap() was changed to:
bq. {{return Schema.instance.getVersion() != null
!Schema.emptyVersion.equals(Schema.instance.getVersion());}}
This is wrong since
{{Schema.emptyVersion.equals(Schema.instance.getVersion())}} is always true
if there is no schema.
We need some different logic for determining when the schema is propagated.
I haven't tested, but I expect this issue appears in 2.0.5 too.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CASSANDRA-4911) Lift limitation that order by columns must be selected for IN queries
[ https://issues.apache.org/jira/browse/CASSANDRA-4911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-4911: Attachment: 6701_rebased.txt That last bit is actually not really related to this ticket/patch but is rather an old (relatively harmless) bug and I've opened CASSANDRA-6701 for that. I'm attaching a rebase of the CASSANDRA-6701 patch to 2.1 here for testing purposes but that issue should really be handled in it's own ticket. Lift limitation that order by columns must be selected for IN queries - Key: CASSANDRA-4911 URL: https://issues.apache.org/jira/browse/CASSANDRA-4911 Project: Cassandra Issue Type: Improvement Components: API Affects Versions: 1.2.0 beta 1 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 2.1 Attachments: 4911-v2.txt, 4911.txt, 6701_rebased.txt This is the followup of CASSANDRA-4645. We should remove the limitation that for IN queries, you must have columns on which you have an ORDER BY in the select clause. For that, we'll need to automatically add the columns on which we have an ORDER BY to the one queried internally, and remove it afterwards (once the sorting is done) from the resultSet. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (CASSANDRA-6701) IN on the last clustering columns + ORDER BY DESC yield no results
[
https://issues.apache.org/jira/browse/CASSANDRA-6701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900489#comment-13900489
]
Sylvain Lebresne edited comment on CASSANDRA-6701 at 2/13/14 4:43 PM:
--
Attaching trivial patch. I've pushed the example above as a dtest too.
Btw, the patch kind of fix another small issue in that in the example above,
results ended-up not ordered following the IN order, which we do it otherwise
(since there is no ORDER BY on c1, only on c2).
was (Author: slebresne):
Attaching trivial patch. I've pushed the example above as a dtest too.
IN on the last clustering columns + ORDER BY DESC yield no results
--
Key: CASSANDRA-6701
URL: https://issues.apache.org/jira/browse/CASSANDRA-6701
Project: Cassandra
Issue Type: Bug
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 1.2.16
Attachments: 6701.txt
That's not a very common mix but well, the following return no results which
is obviously bogus:
{noformat}
CREATE TABLE test (k int, c1 int, c2 int, PRIMARY KEY (k, c1, c2));
INSERT INTO test(k, c1, c2) VALUES (0, 0, 0);
INSERT INTO test(k, c1, c2) VALUES (0, 0, 1);
INSERT INTO test(k, c1, c2) VALUES (0, 0, 2);
SELECT * FROM test WHERE k=0 AND c1 = 0 AND c2 IN (2, 0) ORDER BY c1 DESC
{noformat}
Note: it's pretty useless to order on a column which has an equal
restriction, and that's probably why nobody ran into this yet, but that's
really just due to a minor typo so there is no reason not to fix.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CASSANDRA-4911) Lift limitation that order by columns must be selected for IN queries
[ https://issues.apache.org/jira/browse/CASSANDRA-4911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900543#comment-13900543 ] Tyler Hobbs commented on CASSANDRA-4911: +1 Lift limitation that order by columns must be selected for IN queries - Key: CASSANDRA-4911 URL: https://issues.apache.org/jira/browse/CASSANDRA-4911 Project: Cassandra Issue Type: Improvement Components: API Affects Versions: 1.2.0 beta 1 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 2.1 Attachments: 4911-v2.txt, 4911.txt, 6701_rebased.txt This is the followup of CASSANDRA-4645. We should remove the limitation that for IN queries, you must have columns on which you have an ORDER BY in the select clause. For that, we'll need to automatically add the columns on which we have an ORDER BY to the one queried internally, and remove it afterwards (once the sorting is done) from the resultSet. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6701) IN on the last clustering columns + ORDER BY DESC yield no results
[
https://issues.apache.org/jira/browse/CASSANDRA-6701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900554#comment-13900554
]
Tyler Hobbs commented on CASSANDRA-6701:
+1 on 6701.txt and your rebased version on CASSANDRA-4911
IN on the last clustering columns + ORDER BY DESC yield no results
--
Key: CASSANDRA-6701
URL: https://issues.apache.org/jira/browse/CASSANDRA-6701
Project: Cassandra
Issue Type: Bug
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 1.2.16
Attachments: 6701.txt
That's not a very common mix but well, the following return no results which
is obviously bogus:
{noformat}
CREATE TABLE test (k int, c1 int, c2 int, PRIMARY KEY (k, c1, c2));
INSERT INTO test(k, c1, c2) VALUES (0, 0, 0);
INSERT INTO test(k, c1, c2) VALUES (0, 0, 1);
INSERT INTO test(k, c1, c2) VALUES (0, 0, 2);
SELECT * FROM test WHERE k=0 AND c1 = 0 AND c2 IN (2, 0) ORDER BY c1 DESC
{noformat}
Note: it's pretty useless to order on a column which has an equal
restriction, and that's probably why nobody ran into this yet, but that's
really just due to a minor typo so there is no reason not to fix.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6379) Replace index_interval with min/max_index_interval
[
https://issues.apache.org/jira/browse/CASSANDRA-6379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tyler Hobbs updated CASSANDRA-6379:
---
Attachment: 6379-v2.txt
bq. Should add max/min index intervals to CFMetaData equals/toString/hashCode.
These all have min/max_index_interval, unless I'm missing something.
bq. CFMetaData import in IndexSummary is in the wrong spot.
Looks like it's unused. 6379-v2.txt removes the import.
Thanks!
Replace index_interval with min/max_index_interval
--
Key: CASSANDRA-6379
URL: https://issues.apache.org/jira/browse/CASSANDRA-6379
Project: Cassandra
Issue Type: New Feature
Components: Core
Reporter: Tyler Hobbs
Assignee: Tyler Hobbs
Fix For: 2.1
Attachments: 6379-thrift-gen.txt, 6379-v2.txt, 6379.txt
As a continuation of the work in CASSANDRA-5519, we want to replace the
{{index_interval}} attribute of tables with {{min_index_interval}} and
{{max_index_interval}}.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Assigned] (CASSANDRA-6683) BADNESS_THRESHOLD does not working correctly with DynamicEndpointSnitch
[
https://issues.apache.org/jira/browse/CASSANDRA-6683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tyler Hobbs reassigned CASSANDRA-6683:
--
Assignee: Tyler Hobbs
BADNESS_THRESHOLD does not working correctly with DynamicEndpointSnitch
---
Key: CASSANDRA-6683
URL: https://issues.apache.org/jira/browse/CASSANDRA-6683
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: Linux 3.8.0-33-generic
Reporter: Kirill Bogdanov
Assignee: Tyler Hobbs
Labels: snitch
Fix For: 2.0.6
There is a problem in *DynamicEndpointSnitch.java* in
sortByProximityWithBadness()
Before calling sortByProximityWithScore we comparing each nodes score ratios
to the badness threshold.
{code}
if ((first - next) / first BADNESS_THRESHOLD)
{
sortByProximityWithScore(address, addresses);
return;
}
{code}
This is not always the correct comparison because *first* score can be less
than *next* score and in that case we will compare a negative number with
positive.
The solution is to compute absolute value of the ratio:
{code}
if (Math.abs((first - next) / first) BADNESS_THRESHOLD)
{code}
This issue causing an incorrect sorting of DCs based on their performance and
affects performance of the snitch.
Thanks.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Reopened] (CASSANDRA-6683) BADNESS_THRESHOLD does not working correctly with DynamicEndpointSnitch
[
https://issues.apache.org/jira/browse/CASSANDRA-6683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tyler Hobbs reopened CASSANDRA-6683:
BADNESS_THRESHOLD does not working correctly with DynamicEndpointSnitch
---
Key: CASSANDRA-6683
URL: https://issues.apache.org/jira/browse/CASSANDRA-6683
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: Linux 3.8.0-33-generic
Reporter: Kirill Bogdanov
Assignee: Tyler Hobbs
Labels: snitch
Fix For: 2.0.6
There is a problem in *DynamicEndpointSnitch.java* in
sortByProximityWithBadness()
Before calling sortByProximityWithScore we comparing each nodes score ratios
to the badness threshold.
{code}
if ((first - next) / first BADNESS_THRESHOLD)
{
sortByProximityWithScore(address, addresses);
return;
}
{code}
This is not always the correct comparison because *first* score can be less
than *next* score and in that case we will compare a negative number with
positive.
The solution is to compute absolute value of the ratio:
{code}
if (Math.abs((first - next) / first) BADNESS_THRESHOLD)
{code}
This issue causing an incorrect sorting of DCs based on their performance and
affects performance of the snitch.
Thanks.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6575) By default, Cassandra should refuse to start if JNA can't be initialized properly
[ https://issues.apache.org/jira/browse/CASSANDRA-6575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900574#comment-13900574 ] Joshua McKenzie commented on CASSANDRA-6575: v3 has a refactor using static imports from SystemUtils that is causing dependency errors at runtime. Reverted that portion of the change as functionality should be identical - attaching v4. Otherwise looks good and tests fine on OSX and linux. By default, Cassandra should refuse to start if JNA can't be initialized properly - Key: CASSANDRA-6575 URL: https://issues.apache.org/jira/browse/CASSANDRA-6575 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Tupshin Harper Assignee: Clément Lardeur Priority: Minor Labels: lhf Fix For: 2.1 Attachments: trunk-6575-v2.patch, trunk-6575-v3.patch, trunk-6575.patch Failure to have JNA working properly is such a common undetected problem that it would be far preferable to have Cassandra refuse to startup unless JNA is initialized. In theory, this should be much less of a problem with Cassandra 2.1 due to CASSANDRA-5872, but even there, it might fail due to native lib problems, or might otherwise be misconfigured. A yaml override, such as boot_without_jna would allow the deliberate overriding of this policy. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6575) By default, Cassandra should refuse to start if JNA can't be initialized properly
[ https://issues.apache.org/jira/browse/CASSANDRA-6575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joshua McKenzie updated CASSANDRA-6575: --- Attachment: trunk-6575-v4.patch By default, Cassandra should refuse to start if JNA can't be initialized properly - Key: CASSANDRA-6575 URL: https://issues.apache.org/jira/browse/CASSANDRA-6575 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Tupshin Harper Assignee: Clément Lardeur Priority: Minor Labels: lhf Fix For: 2.1 Attachments: trunk-6575-v2.patch, trunk-6575-v3.patch, trunk-6575-v4.patch, trunk-6575.patch Failure to have JNA working properly is such a common undetected problem that it would be far preferable to have Cassandra refuse to startup unless JNA is initialized. In theory, this should be much less of a problem with Cassandra 2.1 due to CASSANDRA-5872, but even there, it might fail due to native lib problems, or might otherwise be misconfigured. A yaml override, such as boot_without_jna would allow the deliberate overriding of this policy. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[1/3] git commit: iss-6691
Updated Branches:
refs/heads/trunk 21de3328a - de01d07a0
iss-6691
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/84f2b890
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/84f2b890
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/84f2b890
Branch: refs/heads/trunk
Commit: 84f2b8908e9cdc418a03322db41c9db1ac4f6d6f
Parents: 67101c2
Author: belliottsmith git...@sub.laerad.com
Authored: Wed Feb 12 11:36:35 2014 +
Committer: belliottsmith git...@sub.laerad.com
Committed: Wed Feb 12 11:36:35 2014 +
--
.../org/apache/cassandra/stress/Operation.java | 74 +---
.../apache/cassandra/stress/StressAction.java | 7 +-
.../cassandra/stress/generatedata/DataGen.java | 6 +-
.../stress/generatedata/DataGenBytesRandom.java | 2 +-
.../stress/generatedata/DataGenHex.java | 2 +-
.../generatedata/DataGenStringDictionary.java | 6 +-
.../generatedata/DataGenStringRepeats.java | 16 +--
.../cassandra/stress/generatedata/KeyGen.java | 2 +-
.../cassandra/stress/generatedata/RowGen.java | 4 +-
.../operations/CqlIndexedRangeSlicer.java | 2 +-
.../stress/operations/CqlInserter.java | 2 +-
.../stress/operations/CqlOperation.java | 112 +++
.../cassandra/stress/operations/CqlReader.java | 8 +-
.../stress/operations/ThriftCounterAdder.java | 2 +-
.../operations/ThriftIndexedRangeSlicer.java| 2 +-
.../stress/operations/ThriftInserter.java | 6 +-
.../stress/operations/ThriftReader.java | 30 -
17 files changed, 239 insertions(+), 44 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/84f2b890/tools/stress/src/org/apache/cassandra/stress/Operation.java
--
diff --git a/tools/stress/src/org/apache/cassandra/stress/Operation.java
b/tools/stress/src/org/apache/cassandra/stress/Operation.java
index fa7a453..4519b19 100644
--- a/tools/stress/src/org/apache/cassandra/stress/Operation.java
+++ b/tools/stress/src/org/apache/cassandra/stress/Operation.java
@@ -21,10 +21,25 @@ import java.io.IOException;
import java.nio.ByteBuffer;
import java.util.Arrays;
import java.util.Collections;
+import java.util.EnumMap;
import java.util.List;
import org.apache.cassandra.stress.generatedata.KeyGen;
import org.apache.cassandra.stress.generatedata.RowGen;
+import org.apache.cassandra.stress.operations.CqlCounterAdder;
+import org.apache.cassandra.stress.operations.CqlCounterGetter;
+import org.apache.cassandra.stress.operations.CqlIndexedRangeSlicer;
+import org.apache.cassandra.stress.operations.CqlInserter;
+import org.apache.cassandra.stress.operations.CqlMultiGetter;
+import org.apache.cassandra.stress.operations.CqlRangeSlicer;
+import org.apache.cassandra.stress.operations.CqlReader;
+import org.apache.cassandra.stress.operations.ThriftCounterAdder;
+import org.apache.cassandra.stress.operations.ThriftCounterGetter;
+import org.apache.cassandra.stress.operations.ThriftIndexedRangeSlicer;
+import org.apache.cassandra.stress.operations.ThriftInserter;
+import org.apache.cassandra.stress.operations.ThriftMultiGetter;
+import org.apache.cassandra.stress.operations.ThriftRangeSlicer;
+import org.apache.cassandra.stress.operations.ThriftReader;
import org.apache.cassandra.stress.settings.Command;
import org.apache.cassandra.stress.settings.CqlVersion;
import org.apache.cassandra.stress.settings.SettingsCommandMixed;
@@ -66,7 +81,8 @@ public abstract class Operation
public final RowGen rowGen;
public final ListColumnParent columnParents;
public final StressMetrics metrics;
-public final SettingsCommandMixed.CommandSelector readWriteSelector;
+public final SettingsCommandMixed.CommandSelector commandSelector;
+private final EnumMapCommand, State substates;
private Object cqlCache;
public State(Command type, StressSettings settings, StressMetrics
metrics)
@@ -74,9 +90,15 @@ public abstract class Operation
this.type = type;
this.timer = metrics.getTiming().newTimer();
if (type == Command.MIXED)
-readWriteSelector = ((SettingsCommandMixed)
settings.command).selector();
+{
+commandSelector = ((SettingsCommandMixed)
settings.command).selector();
+substates = new EnumMap(Command.class);
+}
else
-readWriteSelector = null;
+{
+commandSelector = null;
+substates = null;
+}
this.settings = settings;
this.keyGen = settings.keys.newKeyGen();
this.rowGen = settings.columns.newRowGen();
@@ -91,6
[2/3] git commit: fix isDeterministic + CqlReader
fix isDeterministic + CqlReader
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/c8690872
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/c8690872
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/c8690872
Branch: refs/heads/trunk
Commit: c8690872674cc18de35efeca7ac6da280c6647f0
Parents: 84f2b89 79c6ecc
Author: belliottsmith git...@sub.laerad.com
Authored: Thu Feb 13 16:39:16 2014 +
Committer: belliottsmith git...@sub.laerad.com
Committed: Thu Feb 13 16:39:16 2014 +
--
CHANGES.txt | 9 +-
.../db/AbstractThreadUnsafeSortedColumns.java | 70
.../cassandra/db/ArrayBackedSortedColumns.java | 50 -
.../org/apache/cassandra/db/ColumnFamily.java | 8 --
.../org/apache/cassandra/db/EmptyColumns.java | 112 ---
src/java/org/apache/cassandra/db/Mutation.java | 2 +-
.../org/apache/cassandra/db/SystemKeyspace.java | 2 +-
.../db/columniterator/IndexedSliceReader.java | 2 +-
.../db/columniterator/SimpleSliceReader.java| 2 +-
.../db/compaction/LazilyCompactedRow.java | 2 +-
.../db/compaction/LeveledManifest.java | 23 +---
.../apache/cassandra/db/filter/ColumnSlice.java | 49
.../db/index/composites/CompositesSearcher.java | 2 +-
.../io/sstable/SSTableIdentityIterator.java | 2 +-
.../cassandra/service/CassandraDaemon.java | 7 +-
.../cassandra/service/MigrationManager.java | 18 ++-
.../apache/cassandra/service/ReadCallback.java | 4 +-
.../apache/cassandra/service/StorageProxy.java | 4 +-
.../cassandra/service/StorageService.java | 1 -
.../cassandra/service/pager/QueryPagers.java| 2 +-
.../apache/cassandra/service/paxos/Commit.java | 4 +-
.../cassandra/db/RangeTombstoneListTest.java| 6 -
test/unit/org/apache/cassandra/db/RowTest.java | 2 +-
.../locator/OldNetworkTopologyStrategyTest.java | 12 +-
...2.0.0-rc2-SNAPSHOT-jar-with-dependencies.jar | Bin 5869229 - 0 bytes
...cassandra-driver-core-2.0.0-rc2-SNAPSHOT.jar | Bin 490145 - 0 bytes
...cassandra-driver-core-2.0.0-rc3-SNAPSHOT.jar | Bin 0 - 515357 bytes
.../apache/cassandra/stress/StressAction.java | 6 +-
.../generatedata/DataGenStringDictionary.java | 6 +-
.../generatedata/DataGenStringRepeats.java | 2 +-
.../generatedata/RowGenDistributedSize.java | 6 +-
.../stress/operations/CqlOperation.java | 29 ++---
.../cassandra/stress/settings/SettingsKey.java | 7 +-
.../cassandra/stress/util/JavaDriverClient.java | 9 +-
34 files changed, 122 insertions(+), 338 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/c8690872/tools/stress/src/org/apache/cassandra/stress/generatedata/RowGenDistributedSize.java
--
diff --cc
tools/stress/src/org/apache/cassandra/stress/generatedata/RowGenDistributedSize.java
index b68ab3c,b68ab3c..6749eae
---
a/tools/stress/src/org/apache/cassandra/stress/generatedata/RowGenDistributedSize.java
+++
b/tools/stress/src/org/apache/cassandra/stress/generatedata/RowGenDistributedSize.java
@@@ -21,6 -21,6 +21,8 @@@ public class RowGenDistributedSize exte
final ByteBuffer[] ret;
final int[] sizes;
++final boolean isDeterministic;
++
public RowGenDistributedSize(DataGen dataGenerator, Distribution
countDistribution, Distribution sizeDistribution)
{
super(dataGenerator);
@@@ -28,6 -28,6 +30,8 @@@
this.sizeDistribution = sizeDistribution;
ret = new ByteBuffer[(int) countDistribution.maxValue()];
sizes = new int[ret.length];
++this.isDeterministic = dataGen.isDeterministic()
countDistribution.maxValue() == countDistribution.minValue()
++ sizeDistribution.minValue() == sizeDistribution.maxValue();
}
ByteBuffer getBuffer(int size)
@@@ -78,7 -78,7 +82,7 @@@
@Override
public boolean isDeterministic()
{
--return false;
++return isDeterministic;
}
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/c8690872/tools/stress/src/org/apache/cassandra/stress/operations/CqlOperation.java
--
diff --cc
tools/stress/src/org/apache/cassandra/stress/operations/CqlOperation.java
index bd2f131,78dd461..b17f520
--- a/tools/stress/src/org/apache/cassandra/stress/operations/CqlOperation.java
+++ b/tools/stress/src/org/apache/cassandra/stress/operations/CqlOperation.java
@@@ -192,8 -192,8 +192,12 @@@ public abstract class CqlOperationV e
if (result.length != expect.size())
return false;
for (int i = 0 ; i result.length ; i++)
--
[3/3] git commit: Merge fix to CASSANDRA-6691 to enable value verification in tools/stress
Merge fix to CASSANDRA-6691 to enable value verification in tools/stress Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/de01d07a Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/de01d07a Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/de01d07a Branch: refs/heads/trunk Commit: de01d07a0ca9339d2c57173132e52dc7a147c0c8 Parents: 21de332 c869087 Author: Pavel Yaskevich xe...@apache.org Authored: Thu Feb 13 11:11:00 2014 -0800 Committer: Pavel Yaskevich xe...@apache.org Committed: Thu Feb 13 11:11:00 2014 -0800 -- .../cassandra/stress/generatedata/RowGenDistributedSize.java | 6 +- .../org/apache/cassandra/stress/operations/CqlOperation.java | 6 +- 2 files changed, 10 insertions(+), 2 deletions(-) --
[jira] [Commented] (CASSANDRA-6691) Improvements and FIxes to Stress
[ https://issues.apache.org/jira/browse/CASSANDRA-6691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900624#comment-13900624 ] Pavel Yaskevich commented on CASSANDRA-6691: Ok, [~benedict] I have merged your changed, so everything is in trunk now. Improvements and FIxes to Stress Key: CASSANDRA-6691 URL: https://issues.apache.org/jira/browse/CASSANDRA-6691 Project: Cassandra Issue Type: Bug Components: Tools Reporter: Benedict Assignee: Benedict Priority: Minor Fix For: 2.1 There were a couple of minor issues with the new stress: 1) The warmup period did not scale up as the cluster size increased 2) The mixed workload did not work with CQL At the same time, I have introduced a change in behaviour in the way the default column values are generated so that they are deterministically based on the key. I have then modified read operations to verify that the data they fetch is the same as should have been inserted, so that stress does some degree of data quality checking at the same time. For the moment the values generated never vary for a given key, so this does nothing to test consistency, it only tests for corruption. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6691) Improvements and FIxes to Stress
[ https://issues.apache.org/jira/browse/CASSANDRA-6691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900657#comment-13900657 ] Benedict commented on CASSANDRA-6691: - Awesome - thanks! Improvements and FIxes to Stress Key: CASSANDRA-6691 URL: https://issues.apache.org/jira/browse/CASSANDRA-6691 Project: Cassandra Issue Type: Bug Components: Tools Reporter: Benedict Assignee: Benedict Priority: Minor Fix For: 2.1 There were a couple of minor issues with the new stress: 1) The warmup period did not scale up as the cluster size increased 2) The mixed workload did not work with CQL At the same time, I have introduced a change in behaviour in the way the default column values are generated so that they are deterministically based on the key. I have then modified read operations to verify that the data they fetch is the same as should have been inserted, so that stress does some degree of data quality checking at the same time. For the moment the values generated never vary for a given key, so this does nothing to test consistency, it only tests for corruption. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
git commit: Require JNA by default patch by Clément Lardeur; reviewed by dbrosius and Josh McKenzie for CASSANDRA-6575
Updated Branches:
refs/heads/trunk de01d07a0 - e9f8fc716
Require JNA by default
patch by Clément Lardeur; reviewed by dbrosius and Josh McKenzie for
CASSANDRA-6575
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e9f8fc71
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e9f8fc71
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e9f8fc71
Branch: refs/heads/trunk
Commit: e9f8fc7164aac0c7a746b74911afda9e0f02dbd8
Parents: de01d07
Author: Jonathan Ellis jbel...@apache.org
Authored: Thu Feb 13 15:56:55 2014 -0600
Committer: Jonathan Ellis jbel...@apache.org
Committed: Thu Feb 13 15:56:55 2014 -0600
--
CHANGES.txt | 2 +
.../cassandra/service/CassandraDaemon.java | 14
.../org/apache/cassandra/utils/CLibrary.java| 68
3 files changed, 58 insertions(+), 26 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/e9f8fc71/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 0af..dc9cff5 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.1
+ * Require JNA by default (CASSANDRA-6575)
* add listsnapshots command to nodetool (CASSANDRA-5742)
* Introduce AtomicBTreeColumns (CASSANDRA-6271)
* Multithreaded commitlog (CASSANDRA-3578)
@@ -31,6 +32,7 @@
* Avoid repairing already repaired data (CASSANDRA-5351)
* Reject counter updates with USING TTL/TIMESTAMP (CASSANDRA-6649)
+
2.0.6
* Add compatibility for Hadoop 0.2.x (CASSANDRA-5201)
* Fix EstimatedHistogram races (CASSANDRA-6682)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/e9f8fc71/src/java/org/apache/cassandra/service/CassandraDaemon.java
--
diff --git a/src/java/org/apache/cassandra/service/CassandraDaemon.java
b/src/java/org/apache/cassandra/service/CassandraDaemon.java
index b69ac10..732f962 100644
--- a/src/java/org/apache/cassandra/service/CassandraDaemon.java
+++ b/src/java/org/apache/cassandra/service/CassandraDaemon.java
@@ -141,6 +141,20 @@ public class CassandraDaemon
for(MemoryPoolMXBean pool: ManagementFactory.getMemoryPoolMXBeans())
logger.info({} {}: {}, pool.getName(), pool.getType(),
pool.getPeakUsage());
logger.info(Classpath: {}, System.getProperty(java.class.path));
+
+// Fail-fast if JNA is not available or failing to initialize properly
+// except with -Dcassandra.boot_without_jna=true. See CASSANDRA-6575.
+if (!CLibrary.jnaAvailable())
+{
+boolean jnaRequired =
!Boolean.getBoolean(cassandra.boot_without_jna);
+
+if (jnaRequired)
+{
+logger.error(JNA failing to initialize properly. Use
-Dcassandra.boot_without_jna=true to bootstrap even so.);
+System.exit(3);
+}
+}
+
CLibrary.tryMlockall();
Thread.setDefaultUncaughtExceptionHandler(new
Thread.UncaughtExceptionHandler()
http://git-wip-us.apache.org/repos/asf/cassandra/blob/e9f8fc71/src/java/org/apache/cassandra/utils/CLibrary.java
--
diff --git a/src/java/org/apache/cassandra/utils/CLibrary.java
b/src/java/org/apache/cassandra/utils/CLibrary.java
index a7ff815..ac9f863 100644
--- a/src/java/org/apache/cassandra/utils/CLibrary.java
+++ b/src/java/org/apache/cassandra/utils/CLibrary.java
@@ -47,8 +47,8 @@ public final class CLibrary
private static final int POSIX_FADV_WILLNEED = 3; /* fadvise.h */
private static final int POSIX_FADV_DONTNEED = 4; /* fadvise.h */
private static final int POSIX_FADV_NOREUSE= 5; /* fadvise.h */
-
-static boolean jnaAvailable = false;
+
+static boolean jnaAvailable = true;
static boolean jnaLockable = false;
static
@@ -56,35 +56,31 @@ public final class CLibrary
try
{
Native.register(c);
-jnaAvailable = true;
}
catch (NoClassDefFoundError e)
{
-logger.info(JNA not found. Native methods will be disabled.);
+logger.warn(JNA not found. Native methods will be disabled.);
+jnaAvailable = false;
}
catch (UnsatisfiedLinkError e)
{
-logger.info(JNA link failure, one or more native method will be
unavailable.);
+logger.warn(JNA link failure, one or more native method will be
unavailable.);
logger.debug(JNA link failure details: {}, e.getMessage());
}
catch (NoSuchMethodError e)
{
logger.warn(Obsolete version of JNA present; unable to register C
library. Upgrade to JNA 3.2.7
[jira] [Commented] (CASSANDRA-6451) Allow Cassandra-Stress to Set Compaction Strategy Options
[ https://issues.apache.org/jira/browse/CASSANDRA-6451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900784#comment-13900784 ] Jonathan Ellis commented on CASSANDRA-6451: --- [~benedict] is stress-ng a strict superset of old stress? should we get rid of old in 2.1 and start adding features in ng instead? Allow Cassandra-Stress to Set Compaction Strategy Options - Key: CASSANDRA-6451 URL: https://issues.apache.org/jira/browse/CASSANDRA-6451 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Russell Alexander Spitzer Assignee: Russell Alexander Spitzer Priority: Minor Attachments: trunk-6451.txt I was just running some tests with Cassandra-Stress and discovered that I was unable to set the compaction_strategy_options I needed. I've made a small patch to add yet another parameter to stress allowing the user to set strategy_options. Usage like so: ./cassandra-stress -Z MyStrat -z option1=10,option2=5 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-5839) Save repair data to system table
[ https://issues.apache.org/jira/browse/CASSANDRA-5839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900798#comment-13900798 ] sankalp kohli commented on CASSANDRA-5839: -- I eyeballed the diff and have following suggestions. 1) As mentioned by [~jbellis], this CF is used to store the end state of repair. Why are we updating this CF as the repair is progressing? I think tracing should be used for that. 2) Each RepairJob creates multiple Differencer objects. From each object, we are updating the state of the same repair to streaming multiple times. You can keep the present state in RepairProgressPersister and not update the CF if it is the same. 3) You can add a new field to determine failed/in-progress/success repairs in the CF. The most used query here will be to show all failed/success repairs in the past. This will make the query simple as you will not need to know all the states. Also you might want to convert your states into enums rather than plain strings. 4) While storing validation/syn failed state, it will be useful to also add which host caused this failure. This will help in finding repeated repair failures. Like sometimes, a bad sstable on a single node causes repairs to fail. 5) Since this CF is replicated and will be used to analyze results of past repairs, storing IP addresses of nodes involved might not help after host replacement. We might not be able to use token here due to v-nodes. So I don't have a better alternative :) 6) CASSANDRA-5483 will introduce tracing. If it make sense, we can add trace sessionId here. 7) All the CF names of system keyspace are in SystemKeyspace class. You have put it in RepairProgressPersister. Don't know whether it make sense to move this into SystemKeyspace since this is a CF of system_distributed!! 8) You might want to change the CF name to repair_history from repair. Save repair data to system table Key: CASSANDRA-5839 URL: https://issues.apache.org/jira/browse/CASSANDRA-5839 Project: Cassandra Issue Type: New Feature Components: Core, Tools Reporter: Jonathan Ellis Assignee: Jimmy Mårdell Priority: Minor Fix For: 2.0.6 Attachments: 2.0.4-5839-draft.patch, 2.0.6-5839-v2.patch As noted in CASSANDRA-2405, it would be useful to store repair results, particularly with sub-range repair available (CASSANDRA-5280). -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CASSANDRA-5839) Save repair data to system table
[ https://issues.apache.org/jira/browse/CASSANDRA-5839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-5839: -- Reviewer: sankalp kohli (was: Marcus Eriksson) Thank you for volunteering to review, [~kohlisankalp]. :) Save repair data to system table Key: CASSANDRA-5839 URL: https://issues.apache.org/jira/browse/CASSANDRA-5839 Project: Cassandra Issue Type: New Feature Components: Core, Tools Reporter: Jonathan Ellis Assignee: Jimmy Mårdell Priority: Minor Fix For: 2.0.6 Attachments: 2.0.4-5839-draft.patch, 2.0.6-5839-v2.patch As noted in CASSANDRA-2405, it would be useful to store repair results, particularly with sub-range repair available (CASSANDRA-5280). -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-5839) Save repair data to system table
[ https://issues.apache.org/jira/browse/CASSANDRA-5839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900817#comment-13900817 ] sankalp kohli commented on CASSANDRA-5839: -- Also why is the replication of this new keyspace 1? Is that intentional? Save repair data to system table Key: CASSANDRA-5839 URL: https://issues.apache.org/jira/browse/CASSANDRA-5839 Project: Cassandra Issue Type: New Feature Components: Core, Tools Reporter: Jonathan Ellis Assignee: Jimmy Mårdell Priority: Minor Fix For: 2.0.6 Attachments: 2.0.4-5839-draft.patch, 2.0.6-5839-v2.patch As noted in CASSANDRA-2405, it would be useful to store repair results, particularly with sub-range repair available (CASSANDRA-5280). -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6379) Replace index_interval with min/max_index_interval
[
https://issues.apache.org/jira/browse/CASSANDRA-6379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900818#comment-13900818
]
Aleksey Yeschenko commented on CASSANDRA-6379:
--
bq. These all have min/max_index_interval, unless I'm missing something.
Huh, indeed. Sorry. Committed w/ a simple NEWS.txt entry.
Replace index_interval with min/max_index_interval
--
Key: CASSANDRA-6379
URL: https://issues.apache.org/jira/browse/CASSANDRA-6379
Project: Cassandra
Issue Type: New Feature
Components: Core
Reporter: Tyler Hobbs
Assignee: Tyler Hobbs
Fix For: 2.1
Attachments: 6379-thrift-gen.txt, 6379-v2.txt, 6379.txt
As a continuation of the work in CASSANDRA-5519, we want to replace the
{{index_interval}} attribute of tables with {{min_index_interval}} and
{{max_index_interval}}.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CASSANDRA-5872) Bundle JNA
[ https://issues.apache.org/jira/browse/CASSANDRA-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900825#comment-13900825 ] Ryan McGuire commented on CASSANDRA-5872: - This change bumps the initial ram usage of C* to over 2GB for a single node. This makes it pretty hard for me to test a four node ccm cluster on my 8G laptop. Bundle JNA -- Key: CASSANDRA-5872 URL: https://issues.apache.org/jira/browse/CASSANDRA-5872 Project: Cassandra Issue Type: Task Components: Core Reporter: Jonathan Ellis Assignee: Lyuben Todorov Priority: Minor Fix For: 2.1 Attachments: 5872-trunk.patch, 5872_debian.patch JNA 4.0 is reported to be dual-licensed LGPL/APL. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Reopened] (CASSANDRA-5872) Bundle JNA
[ https://issues.apache.org/jira/browse/CASSANDRA-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McGuire reopened CASSANDRA-5872: - Bundle JNA -- Key: CASSANDRA-5872 URL: https://issues.apache.org/jira/browse/CASSANDRA-5872 Project: Cassandra Issue Type: Task Components: Core Reporter: Jonathan Ellis Assignee: Lyuben Todorov Priority: Minor Fix For: 2.1 Attachments: 5872-trunk.patch, 5872_debian.patch JNA 4.0 is reported to be dual-licensed LGPL/APL. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CASSANDRA-6702) Upgrading node uses the wrong port in gossiping
Minh Do created CASSANDRA-6702: -- Summary: Upgrading node uses the wrong port in gossiping Key: CASSANDRA-6702 URL: https://issues.apache.org/jira/browse/CASSANDRA-6702 Project: Cassandra Issue Type: Bug Components: Core Environment: 1.1.7, AWS, Ec2MultiRegionSnitch Reporter: Minh Do Priority: Minor Fix For: 1.2.15 When upgrading a node in 1.1.7 (or 1.1.11) cluster to 1.2.15 and inspecting the gossip information on port/Ip, I could see that the upgrading node (1.2 version) communicates to one other node in the same region using Public IP and non-encrypted port. For the rest, the upgrading node uses the correct ports and IPs to communicate in this manner: Same region: private IP and non-encrypted port and Different region: public IP and encrypted port Because there is one node like this (or probably 2 max), we have to modify Security Group to allow the new traffics. Without modifying the SG, the 95th and 99th latencies for both reads and writes in the cluster are very bad (due to RPC timeout). Inspecting closer, that upgraded node (1.2 node) is contributing to all of the high latencies whenever it acts as a coordinator node. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-3668) Parallel streaming for sstableloader
[ https://issues.apache.org/jira/browse/CASSANDRA-3668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900880#comment-13900880 ] Jonathan Ellis commented on CASSANDRA-3668: --- [~yukim] can you outline for Josh what is needed here and let him take it from there? Parallel streaming for sstableloader Key: CASSANDRA-3668 URL: https://issues.apache.org/jira/browse/CASSANDRA-3668 Project: Cassandra Issue Type: Improvement Components: API Reporter: Manish Zope Assignee: Joshua McKenzie Priority: Minor Labels: streaming Fix For: 2.1 Attachments: 3668-1.1-v2.txt, 3668-1.1.txt, 3688-reply_before_closing_writer.txt, sstable-loader performance.txt Original Estimate: 48h Remaining Estimate: 48h One of my colleague had reported the bug regarding the degraded performance of the sstable generator and sstable loader. ISSUE :- https://issues.apache.org/jira/browse/CASSANDRA-3589 As stated in above issue generator performance is rectified but performance of the sstableloader is still an issue. 3589 is marked as duplicate of 3618.Both issues shows resolved status.But the problem with sstableloader still exists. So opening other issue so that sstbleloader problem should not go unnoticed. FYI : We have tested the generator part with the patch given in 3589.Its Working fine. Please let us know if you guys require further inputs from our side. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CASSANDRA-3668) Parallel streaming for sstableloader
[ https://issues.apache.org/jira/browse/CASSANDRA-3668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-3668: -- Assignee: Joshua McKenzie (was: Yuki Morishita) Parallel streaming for sstableloader Key: CASSANDRA-3668 URL: https://issues.apache.org/jira/browse/CASSANDRA-3668 Project: Cassandra Issue Type: Improvement Components: API Reporter: Manish Zope Assignee: Joshua McKenzie Priority: Minor Labels: streaming Fix For: 2.1 Attachments: 3668-1.1-v2.txt, 3668-1.1.txt, 3688-reply_before_closing_writer.txt, sstable-loader performance.txt Original Estimate: 48h Remaining Estimate: 48h One of my colleague had reported the bug regarding the degraded performance of the sstable generator and sstable loader. ISSUE :- https://issues.apache.org/jira/browse/CASSANDRA-3589 As stated in above issue generator performance is rectified but performance of the sstableloader is still an issue. 3589 is marked as duplicate of 3618.Both issues shows resolved status.But the problem with sstableloader still exists. So opening other issue so that sstbleloader problem should not go unnoticed. FYI : We have tested the generator part with the patch given in 3589.Its Working fine. Please let us know if you guys require further inputs from our side. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6229) transfers never occur after enabling a shuffle
[ https://issues.apache.org/jira/browse/CASSANDRA-6229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-6229: -- Assignee: Joshua McKenzie (was: Yuki Morishita) transfers never occur after enabling a shuffle -- Key: CASSANDRA-6229 URL: https://issues.apache.org/jira/browse/CASSANDRA-6229 Project: Cassandra Issue Type: Bug Components: Tools Reporter: Daniel Meyer Assignee: Joshua McKenzie Using the following documentation as reference: http://www.datastax.com/documentation/cassandra/2.0/webhelp/cassandra/tools/toolsCassandraShuffle.html After running the 'shuffle en' step, the command does not block giving the indication that a transfer has occurred. However, running 'shuffle ls' at an arbitrary time after enabling the shuffle results in a large list of pending transfers. From the users perspective it is unclear what is happening; however, it looks like the transfer does not actually occur. repro steps: 1) cd to latest cassandra-2.0 branch 2) ccm create shuffle_test 3 ccm populate -n 3 4) delete the 'num_tokens' line from each cassandra.yaml file for all three nodes. 5) ccm start 6) run 'ccm node1 ring' and verify the vnodes are not enabled. 7) ccm node1 stress -o insert 8) for each node set 'num_tokens: 256' in the cassandra.yaml 9) restart the nodes 10) run 'ccm node1 ring' to verify vnodes is enabled 11) ccm node1 shuffle create 12) ccm node1 shuffle en 13) wait arbitrary amount of time and run 'ccm node1 shuffle ls'. Expected: transfers should eventually happen and not be observed with 'shuffle ls' Actual: transfers never seem to occur. If in fact they do occur it is not obvious. If transfers do in fact occur it is very difficult to tell. This was initially discovered on a real cluster and the cluster sat overnight without any transfers happening. As a user I would also expect 'shuffle en' to block. The non blocking behavior does not seem ideal from a user perspective. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6261) Repair should display number of rows that mismatched.
[ https://issues.apache.org/jira/browse/CASSANDRA-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900885#comment-13900885 ] Jonathan Ellis commented on CASSANDRA-6261: --- This should be part of either CASSANDRA-5483 or CASSANDRA-5839 right? Repair should display number of rows that mismatched. -- Key: CASSANDRA-6261 URL: https://issues.apache.org/jira/browse/CASSANDRA-6261 Project: Cassandra Issue Type: Bug Components: Core Reporter: sankalp kohli Assignee: Yuki Morishita Priority: Minor Repair currently displays number of ranges which are out of sync. It would be helpful to display how many rows that did not match. We can do this by sending number of rows with each hash in the Merkle tree. Also we can put the size of rows which contributed to that hash. So each leaf node in the tree will have a hash and also the number of rows and its size. We can also emit the avg rows per hash range and also the min and max. All this will help in tuning the repair -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6577) ConcurrentModificationException during nodetool netstats
[
https://issues.apache.org/jira/browse/CASSANDRA-6577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-6577:
--
Assignee: Joshua McKenzie (was: Yuki Morishita)
ConcurrentModificationException during nodetool netstats
Key: CASSANDRA-6577
URL: https://issues.apache.org/jira/browse/CASSANDRA-6577
Project: Cassandra
Issue Type: Bug
Components: Tools
Environment: AWS EC2 machines,
java version 1.7.0_45
Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
Each node has 32 vnodes.
Reporter: Shao-Chuan Wang
Assignee: Joshua McKenzie
Priority: Minor
Labels: decommission, nodetool
Fix For: 2.0.6
The node is leaving and I wanted to check its netstats, but it raises
ConcurrentModificationException.
{code}
[ubuntu@ip-10-4-202-48 :~]# /mnt/cassandra_latest/bin/nodetool netstats
Mode: LEAVING
Exception in thread main java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:926)
at java.util.HashMap$ValueIterator.next(HashMap.java:954)
at
com.google.common.collect.TransformedIterator.next(TransformedIterator.java:48)
at com.google.common.collect.Iterators.addAll(Iterators.java:357)
at com.google.common.collect.Lists.newArrayList(Lists.java:146)
at com.google.common.collect.Lists.newArrayList(Lists.java:128)
at
org.apache.cassandra.streaming.management.SessionInfoCompositeData.toArrayOfCompositeData(SessionInfoCompositeData.java:161)
at
org.apache.cassandra.streaming.management.SessionInfoCompositeData.toCompositeData(SessionInfoCompositeData.java:98)
at
org.apache.cassandra.streaming.management.StreamStateCompositeData$1.apply(StreamStateCompositeData.java:82)
at
org.apache.cassandra.streaming.management.StreamStateCompositeData$1.apply(StreamStateCompositeData.java:79)
at com.google.common.collect.Iterators$8.transform(Iterators.java:794)
at
com.google.common.collect.TransformedIterator.next(TransformedIterator.java:48)
at com.google.common.collect.Iterators.addAll(Iterators.java:357)
at com.google.common.collect.Lists.newArrayList(Lists.java:146)
at com.google.common.collect.Lists.newArrayList(Lists.java:128)
at
org.apache.cassandra.streaming.management.StreamStateCompositeData.toCompositeData(StreamStateCompositeData.java:78)
at
org.apache.cassandra.streaming.StreamManager$1.apply(StreamManager.java:87)
at
org.apache.cassandra.streaming.StreamManager$1.apply(StreamManager.java:84)
at com.google.common.collect.Iterators$8.transform(Iterators.java:794)
at
com.google.common.collect.TransformedIterator.next(TransformedIterator.java:48)
at com.google.common.collect.Iterators.addAll(Iterators.java:357)
at com.google.common.collect.Sets.newHashSet(Sets.java:238)
at com.google.common.collect.Sets.newHashSet(Sets.java:218)
at
org.apache.cassandra.streaming.StreamManager.getCurrentStreams(StreamManager.java:83)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75)
at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279)
at
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
at
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
at
com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
at
com.sun.jmx.mbeanserver.PerInterface.getAttribute(PerInterface.java:83)
at
com.sun.jmx.mbeanserver.MBeanSupport.getAttribute(MBeanSupport.java:206)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:647)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)
at
javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1464)
at
javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97)
at
[jira] [Commented] (CASSANDRA-6589) Gossip AssertionError: Added cell does not sort as the last cell
[
https://issues.apache.org/jira/browse/CASSANDRA-6589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900887#comment-13900887
]
Jonathan Ellis commented on CASSANDRA-6589:
---
Your ABSC changes make this obsolete right [~benedict] [~iamaleksey]?
Gossip AssertionError: Added cell does not sort as the last cell
Key: CASSANDRA-6589
URL: https://issues.apache.org/jira/browse/CASSANDRA-6589
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: Debian Wheezy amd64
Oracle JDK 1.7_45
Branch: trunk
Reporter: Michael Shuler
Assignee: Yuki Morishita
The super_counter_test.py dtest sometimes, but not always, hangs until killed
(^C) when running with vnodes. Reproduction (again, sometimes this is
successful - keep trying until it hangs for a few minutes, which is about
1/3-1/2 of the time for me):
{noformat}
$ ENABLE_VNODES=true nosetests -v super_counter_test.py
{noformat}
If it does hang up on you, in another shell:
{noformat}
$ tail -F /tmp/dtest-*/test/node*/logs/system.log
{noformat}
Scrolling errors similar to:
{noformat}
ERROR [GossipStage:54] 2014-01-15 10:39:30,229 CassandraDaemon.java:139 -
Exception in thread Thread[GossipStage:54,5,main]
java.lang.AssertionError: Added cell does not sort as the last cell
at
org.apache.cassandra.db.ArrayBackedSortedColumns.addColumn(ArrayBackedSortedColumns.java:116)
~[main/:na]
at
org.apache.cassandra.db.ColumnFamily.addColumn(ColumnFamily.java:118)
~[main/:na]
at
org.apache.cassandra.db.ColumnFamily.addIfRelevant(ColumnFamily.java:112)
~[main/:na]
at
org.apache.cassandra.db.filter.SliceQueryFilter.collectReducedColumns(SliceQueryFilter.java:214)
~[main/:na]
at
org.apache.cassandra.db.filter.QueryFilter.collateColumns(QueryFilter.java:123)
~[main/:na]
at
org.apache.cassandra.db.filter.QueryFilter.collateOnDiskAtom(QueryFilter.java:81)
~[main/:na]
at
org.apache.cassandra.db.filter.QueryFilter.collateOnDiskAtom(QueryFilter.java:73)
~[main/:na]
at
org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:296)
~[main/:na]
at
org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:52)
~[main/:na]
at
org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1522)
~[main/:na]
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1341)
~[main/:na]
at org.apache.cassandra.db.Keyspace.getRow(Keyspace.java:327)
~[main/:na]
at
org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:59)
~[main/:na]
at
org.apache.cassandra.cql3.statements.SelectStatement.readLocally(SelectStatement.java:223)
~[main/:na]
at
org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:241)
~[main/:na]
at
org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:57)
~[main/:na]
at
org.apache.cassandra.cql3.QueryProcessor.processInternal(QueryProcessor.java:261)
~[main/:na]
at
org.apache.cassandra.db.SystemKeyspace.getPreferredIP(SystemKeyspace.java:457)
~[main/:na]
at
org.apache.cassandra.net.OutboundTcpConnectionPool.init(OutboundTcpConnectionPool.java:48)
~[main/:na]
at
org.apache.cassandra.net.MessagingService.getConnectionPool(MessagingService.java:491)
~[main/:na]
at
org.apache.cassandra.net.MessagingService.getConnection(MessagingService.java:505)
~[main/:na]
at
org.apache.cassandra.net.MessagingService.sendOneWay(MessagingService.java:637)
~[main/:na]
at
org.apache.cassandra.net.MessagingService.sendReply(MessagingService.java:611)
~[main/:na]
at
org.apache.cassandra.service.EchoVerbHandler.doVerb(EchoVerbHandler.java:40)
~[main/:na]
at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:60)
~[main/:na]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
~[na:1.7.0_45]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
~[na:1.7.0_45]
at java.lang.Thread.run(Thread.java:744) ~[na:1.7.0_45]
{noformat}
along with node1 repeatedly marking node3 up and down.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6636) sstableloader fails when attempting to load data from a single node into a multi-node cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-6636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900888#comment-13900888
]
Jonathan Ellis commented on CASSANDRA-6636:
---
How involved would fixing this be?
sstableloader fails when attempting to load data from a single node into a
multi-node cluster
-
Key: CASSANDRA-6636
URL: https://issues.apache.org/jira/browse/CASSANDRA-6636
Project: Cassandra
Issue Type: Bug
Environment: java version 1.7.0_51
cassandra from cassandra-2.0 branch (0be424...)
Reporter: Russ Hatch
Assignee: Yuki Morishita
Priority: Minor
I'm running into this exception when trying to use sstableloader to bring in
data from another cluster:
{noformat}
rhatch@whatup:~/.ccm/test_cluster_1391031988/node1$ bin/sstableloader -d
127.0.0.1 ~/tmp/Keyspace1/Standard1
Established connection to initial hosts
Opening sstables and calculating sections to stream
Streaming relevant part of
/home/rhatch/tmp/Keyspace1/Standard1/Keyspace1-Standard1-jb-5-Data.db
/home/rhatch/tmp/Keyspace1/Standard1/Keyspace1-Standard1-jb-6-Data.db to
[/127.0.0.1, /127.0.0.2, /127.0.0.3]
Exception in thread STREAM-OUT-/127.0.0.1 java.lang.NullPointerException
at
org.apache.cassandra.streaming.ConnectionHandler$MessageHandler.signalCloseDone(ConnectionHandler.java:249)
at
org.apache.cassandra.streaming.ConnectionHandler$OutgoingMessageHandler.run(ConnectionHandler.java:375)
at java.lang.Thread.run(Thread.java:744)
{noformat}
This is what I see in the node system.log:
{noformat}
== ./test_cluster_1391031988/node1/logs/system.log ==
INFO [STREAM-INIT-/127.0.0.1:60971] 2014-01-29 14:57:25,375
StreamResultFuture.java (line 116) [Stream
#564ded70-8930-11e3-84e9-2766c3cc4197] Received streaming plan for Bulk Load
INFO [STREAM-IN-/127.0.1.1] 2014-01-29 14:57:25,375 StreamResultFuture.java
(line 168) [Stream #564ded70-8930-11e3-84e9-2766c3cc4197] Prepare completed.
Receiving 2 files(91047224 bytes), sending 0 files(0 bytes)
{noformat}
steps to reproduce:
create a 3 node cluster with ccm
run stress on one node with 'ccm node1 stress'
copy the node's data from the data/Keyspace1/Standard1 directory to save it
for re-loading (preserve the directory structure for sstableloader)
remove the cluster, and create a new 3 node cluster
pick a node and run bin/nodetool -d localhost
~/saved_data_location/Keyspace1/Standard1
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CASSANDRA-1983) Make sstable filenames contain a UUID instead of increasing integer
[ https://issues.apache.org/jira/browse/CASSANDRA-1983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900892#comment-13900892 ] Jonathan Ellis commented on CASSANDRA-1983: --- Yes. Make sstable filenames contain a UUID instead of increasing integer --- Key: CASSANDRA-1983 URL: https://issues.apache.org/jira/browse/CASSANDRA-1983 Project: Cassandra Issue Type: Improvement Reporter: David King Priority: Minor sstable filenames look like CFName-1569-Index.db, containing an integer for uniqueness. This makes it possible (however unlikely) that the integer could overflow, which could be a problem. It also makes it difficult to collapse multiple nodes into a single one with rsync. I do this occasionally for testing: I'll copy our 20 node cluster into only 3 nodes by copying all of the data files and running cleanup; at present this requires a manual step of uniqifying the overlapping sstable names. If instead of an incrementing integer, it would be handy if these contained a UUID or somesuch that guarantees uniqueness across the cluster. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6589) Gossip AssertionError: Added cell does not sort as the last cell
[
https://issues.apache.org/jira/browse/CASSANDRA-6589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900890#comment-13900890
]
Aleksey Yeschenko commented on CASSANDRA-6589:
--
Yes, and also, no. The exception will no longer be there, but, still, in this
case it's a sign of something gone wrong.
Gossip AssertionError: Added cell does not sort as the last cell
Key: CASSANDRA-6589
URL: https://issues.apache.org/jira/browse/CASSANDRA-6589
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: Debian Wheezy amd64
Oracle JDK 1.7_45
Branch: trunk
Reporter: Michael Shuler
Assignee: Yuki Morishita
The super_counter_test.py dtest sometimes, but not always, hangs until killed
(^C) when running with vnodes. Reproduction (again, sometimes this is
successful - keep trying until it hangs for a few minutes, which is about
1/3-1/2 of the time for me):
{noformat}
$ ENABLE_VNODES=true nosetests -v super_counter_test.py
{noformat}
If it does hang up on you, in another shell:
{noformat}
$ tail -F /tmp/dtest-*/test/node*/logs/system.log
{noformat}
Scrolling errors similar to:
{noformat}
ERROR [GossipStage:54] 2014-01-15 10:39:30,229 CassandraDaemon.java:139 -
Exception in thread Thread[GossipStage:54,5,main]
java.lang.AssertionError: Added cell does not sort as the last cell
at
org.apache.cassandra.db.ArrayBackedSortedColumns.addColumn(ArrayBackedSortedColumns.java:116)
~[main/:na]
at
org.apache.cassandra.db.ColumnFamily.addColumn(ColumnFamily.java:118)
~[main/:na]
at
org.apache.cassandra.db.ColumnFamily.addIfRelevant(ColumnFamily.java:112)
~[main/:na]
at
org.apache.cassandra.db.filter.SliceQueryFilter.collectReducedColumns(SliceQueryFilter.java:214)
~[main/:na]
at
org.apache.cassandra.db.filter.QueryFilter.collateColumns(QueryFilter.java:123)
~[main/:na]
at
org.apache.cassandra.db.filter.QueryFilter.collateOnDiskAtom(QueryFilter.java:81)
~[main/:na]
at
org.apache.cassandra.db.filter.QueryFilter.collateOnDiskAtom(QueryFilter.java:73)
~[main/:na]
at
org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:296)
~[main/:na]
at
org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:52)
~[main/:na]
at
org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1522)
~[main/:na]
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1341)
~[main/:na]
at org.apache.cassandra.db.Keyspace.getRow(Keyspace.java:327)
~[main/:na]
at
org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:59)
~[main/:na]
at
org.apache.cassandra.cql3.statements.SelectStatement.readLocally(SelectStatement.java:223)
~[main/:na]
at
org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:241)
~[main/:na]
at
org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:57)
~[main/:na]
at
org.apache.cassandra.cql3.QueryProcessor.processInternal(QueryProcessor.java:261)
~[main/:na]
at
org.apache.cassandra.db.SystemKeyspace.getPreferredIP(SystemKeyspace.java:457)
~[main/:na]
at
org.apache.cassandra.net.OutboundTcpConnectionPool.init(OutboundTcpConnectionPool.java:48)
~[main/:na]
at
org.apache.cassandra.net.MessagingService.getConnectionPool(MessagingService.java:491)
~[main/:na]
at
org.apache.cassandra.net.MessagingService.getConnection(MessagingService.java:505)
~[main/:na]
at
org.apache.cassandra.net.MessagingService.sendOneWay(MessagingService.java:637)
~[main/:na]
at
org.apache.cassandra.net.MessagingService.sendReply(MessagingService.java:611)
~[main/:na]
at
org.apache.cassandra.service.EchoVerbHandler.doVerb(EchoVerbHandler.java:40)
~[main/:na]
at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:60)
~[main/:na]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
~[na:1.7.0_45]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
~[na:1.7.0_45]
at java.lang.Thread.run(Thread.java:744) ~[na:1.7.0_45]
{noformat}
along with node1 repeatedly marking node3 up and down.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CASSANDRA-2527) Add ability to snapshot data as input to hadoop jobs
[ https://issues.apache.org/jira/browse/CASSANDRA-2527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2527: -- Assignee: Joshua McKenzie (was: Tyler Hobbs) Add ability to snapshot data as input to hadoop jobs Key: CASSANDRA-2527 URL: https://issues.apache.org/jira/browse/CASSANDRA-2527 Project: Cassandra Issue Type: New Feature Reporter: Jeremy Hanna Assignee: Joshua McKenzie Priority: Minor Labels: hadoop Fix For: 2.1 It is desirable to have immutable inputs to hadoop jobs for the duration of the job. That way re-execution of individual tasks do not alter the output. One way to accomplish this would be to snapshot the data that is used as input to a job. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (CASSANDRA-5872) Bundle JNA
[ https://issues.apache.org/jira/browse/CASSANDRA-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900825#comment-13900825 ] Ryan McGuire edited comment on CASSANDRA-5872 at 2/13/14 11:39 PM: --- This change bumps the initial ram usage of C* to over 2GB for a single node. This makes it pretty hard for me to test a four node ccm cluster on my 8G laptop. EDIT: It appears that it's not because of the version bump, but the requirement of JNA. was (Author: enigmacurry): This change bumps the initial ram usage of C* to over 2GB for a single node. This makes it pretty hard for me to test a four node ccm cluster on my 8G laptop. Bundle JNA -- Key: CASSANDRA-5872 URL: https://issues.apache.org/jira/browse/CASSANDRA-5872 Project: Cassandra Issue Type: Task Components: Core Reporter: Jonathan Ellis Assignee: Lyuben Todorov Priority: Minor Fix For: 2.1 Attachments: 5872-trunk.patch, 5872_debian.patch JNA 4.0 is reported to be dual-licensed LGPL/APL. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-5872) Bundle JNA
[ https://issues.apache.org/jira/browse/CASSANDRA-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900901#comment-13900901 ] Jonathan Ellis commented on CASSANDRA-5872: --- Sounds like mlockall is putting a stop to your reckless overcommit. :) Bundle JNA -- Key: CASSANDRA-5872 URL: https://issues.apache.org/jira/browse/CASSANDRA-5872 Project: Cassandra Issue Type: Task Components: Core Reporter: Jonathan Ellis Assignee: Lyuben Todorov Priority: Minor Fix For: 2.1 Attachments: 5872-trunk.patch, 5872_debian.patch JNA 4.0 is reported to be dual-licensed LGPL/APL. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6702) Upgrading node uses the wrong port in gossiping
[ https://issues.apache.org/jira/browse/CASSANDRA-6702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-6702: - Fix Version/s: (was: 1.2.15) 1.2.16 Upgrading node uses the wrong port in gossiping --- Key: CASSANDRA-6702 URL: https://issues.apache.org/jira/browse/CASSANDRA-6702 Project: Cassandra Issue Type: Bug Components: Core Environment: 1.1.7, AWS, Ec2MultiRegionSnitch Reporter: Minh Do Priority: Minor Fix For: 1.2.16 When upgrading a node in 1.1.7 (or 1.1.11) cluster to 1.2.15 and inspecting the gossip information on port/Ip, I could see that the upgrading node (1.2 version) communicates to one other node in the same region using Public IP and non-encrypted port. For the rest, the upgrading node uses the correct ports and IPs to communicate in this manner: Same region: private IP and non-encrypted port and Different region: public IP and encrypted port Because there is one node like this (or probably 2 max), we have to modify Security Group to allow the new traffics. Without modifying the SG, the 95th and 99th latencies for both reads and writes in the cluster are very bad (due to RPC timeout). Inspecting closer, that upgraded node (1.2 node) is contributing to all of the high latencies whenever it acts as a coordinator node. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CASSANDRA-5872) Bundle JNA
[ https://issues.apache.org/jira/browse/CASSANDRA-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-5872. - Resolution: Fixed Bundle JNA -- Key: CASSANDRA-5872 URL: https://issues.apache.org/jira/browse/CASSANDRA-5872 Project: Cassandra Issue Type: Task Components: Core Reporter: Jonathan Ellis Assignee: Lyuben Todorov Priority: Minor Fix For: 2.1 Attachments: 5872-trunk.patch, 5872_debian.patch JNA 4.0 is reported to be dual-licensed LGPL/APL. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6261) Repair should display number of rows that mismatched.
[ https://issues.apache.org/jira/browse/CASSANDRA-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900909#comment-13900909 ] Yuki Morishita commented on CASSANDRA-6261: --- Absolutely. Repair should display number of rows that mismatched. -- Key: CASSANDRA-6261 URL: https://issues.apache.org/jira/browse/CASSANDRA-6261 Project: Cassandra Issue Type: Bug Components: Core Reporter: sankalp kohli Assignee: Yuki Morishita Priority: Minor Repair currently displays number of ranges which are out of sync. It would be helpful to display how many rows that did not match. We can do this by sending number of rows with each hash in the Merkle tree. Also we can put the size of rows which contributed to that hash. So each leaf node in the tree will have a hash and also the number of rows and its size. We can also emit the avg rows per hash range and also the min and max. All this will help in tuning the repair -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-5872) Bundle JNA
[ https://issues.apache.org/jira/browse/CASSANDRA-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900913#comment-13900913 ] Jonathan Ellis commented on CASSANDRA-5872: --- Should we add a -Dcassandra.mlockall=false? You'd need to run a custom cassandra.env. Bundle JNA -- Key: CASSANDRA-5872 URL: https://issues.apache.org/jira/browse/CASSANDRA-5872 Project: Cassandra Issue Type: Task Components: Core Reporter: Jonathan Ellis Assignee: Lyuben Todorov Priority: Minor Fix For: 2.1 Attachments: 5872-trunk.patch, 5872_debian.patch JNA 4.0 is reported to be dual-licensed LGPL/APL. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (CASSANDRA-5872) Bundle JNA
[ https://issues.apache.org/jira/browse/CASSANDRA-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900913#comment-13900913 ] Jonathan Ellis edited comment on CASSANDRA-5872 at 2/13/14 11:53 PM: - Should we add a -Dcassandra.mlockall=false? You'd need to run a custom cassandra-env. was (Author: jbellis): Should we add a -Dcassandra.mlockall=false? You'd need to run a custom cassandra.env. Bundle JNA -- Key: CASSANDRA-5872 URL: https://issues.apache.org/jira/browse/CASSANDRA-5872 Project: Cassandra Issue Type: Task Components: Core Reporter: Jonathan Ellis Assignee: Lyuben Todorov Priority: Minor Fix For: 2.1 Attachments: 5872-trunk.patch, 5872_debian.patch JNA 4.0 is reported to be dual-licensed LGPL/APL. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CASSANDRA-6261) Repair should display number of rows that mismatched.
[ https://issues.apache.org/jira/browse/CASSANDRA-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-6261. --- Resolution: Duplicate Assignee: (was: Yuki Morishita) Repair should display number of rows that mismatched. -- Key: CASSANDRA-6261 URL: https://issues.apache.org/jira/browse/CASSANDRA-6261 Project: Cassandra Issue Type: Bug Components: Core Reporter: sankalp kohli Priority: Minor Repair currently displays number of ranges which are out of sync. It would be helpful to display how many rows that did not match. We can do this by sending number of rows with each hash in the Merkle tree. Also we can put the size of rows which contributed to that hash. So each leaf node in the tree will have a hash and also the number of rows and its size. We can also emit the avg rows per hash range and also the min and max. All this will help in tuning the repair -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6261) Repair should display number of rows that mismatched.
[ https://issues.apache.org/jira/browse/CASSANDRA-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900920#comment-13900920 ] sankalp kohli commented on CASSANDRA-6261: -- I think it should be part of both. Repair should display number of rows that mismatched. -- Key: CASSANDRA-6261 URL: https://issues.apache.org/jira/browse/CASSANDRA-6261 Project: Cassandra Issue Type: Bug Components: Core Reporter: sankalp kohli Priority: Minor Repair currently displays number of ranges which are out of sync. It would be helpful to display how many rows that did not match. We can do this by sending number of rows with each hash in the Merkle tree. Also we can put the size of rows which contributed to that hash. So each leaf node in the tree will have a hash and also the number of rows and its size. We can also emit the avg rows per hash range and also the min and max. All this will help in tuning the repair -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-5872) Bundle JNA
[ https://issues.apache.org/jira/browse/CASSANDRA-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900930#comment-13900930 ] Ryan McGuire commented on CASSANDRA-5872: - For my needs, I can just install more RAM, but I thought I would bring it up because it seems that it's a big change in the default setting. So, maybe? Bundle JNA -- Key: CASSANDRA-5872 URL: https://issues.apache.org/jira/browse/CASSANDRA-5872 Project: Cassandra Issue Type: Task Components: Core Reporter: Jonathan Ellis Assignee: Lyuben Todorov Priority: Minor Fix For: 2.1 Attachments: 5872-trunk.patch, 5872_debian.patch JNA 4.0 is reported to be dual-licensed LGPL/APL. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6305) cqlsh support for User Types
[
https://issues.apache.org/jira/browse/CASSANDRA-6305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Stepura updated CASSANDRA-6305:
---
Attachment: trunk-6305-3.patch
[~iamaleksey] I've reworked the changes based on your comments in IRC
* UserType is now based on CompositeType.
* Moved Usertypes' meta logic into cql3handling
* Removed {{private}} modifiers from Shell's methods
The changes are also available at
https://github.com/Mishail/cassandra/commits/CASSANDRA-6305-take2-for-review
cqlsh support for User Types
Key: CASSANDRA-6305
URL: https://issues.apache.org/jira/browse/CASSANDRA-6305
Project: Cassandra
Issue Type: New Feature
Reporter: Aleksey Yeschenko
Assignee: Mikhail Stepura
Labels: cqlsh
Fix For: 2.1
Attachments: trunk-6305-1.patch, trunk-6305-2.patch,
trunk-6305-3.patch
We need cqlsh support for several things:
1. Autocomplete for UPDATE/INSERT/SELECT
2. Autocomplete for ALTER TYPE/CREATE TYPE/DROP TYPE
3. Proper decoding of UserType values (currently showing the encoded blob)
4. Support UserTypes in DESCRIBE
5. Separate DESCRIBE TYPES|TYPE name cmds
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CASSANDRA-5872) Bundle JNA
[ https://issues.apache.org/jira/browse/CASSANDRA-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900948#comment-13900948 ] Brandon Williams commented on CASSANDRA-5872: - Couldn't you just reduce the heap size? Overcommitting is a recipe for trouble at some point, JNA is just exposing it up front. Bundle JNA -- Key: CASSANDRA-5872 URL: https://issues.apache.org/jira/browse/CASSANDRA-5872 Project: Cassandra Issue Type: Task Components: Core Reporter: Jonathan Ellis Assignee: Lyuben Todorov Priority: Minor Fix For: 2.1 Attachments: 5872-trunk.patch, 5872_debian.patch JNA 4.0 is reported to be dual-licensed LGPL/APL. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6305) cqlsh support for User Types
[ https://issues.apache.org/jira/browse/CASSANDRA-6305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900951#comment-13900951 ] Aleksey Yeschenko commented on CASSANDRA-6305: -- LGTM, +1 cqlsh support for User Types Key: CASSANDRA-6305 URL: https://issues.apache.org/jira/browse/CASSANDRA-6305 Project: Cassandra Issue Type: New Feature Reporter: Aleksey Yeschenko Assignee: Mikhail Stepura Labels: cqlsh Fix For: 2.1 Attachments: trunk-6305-1.patch, trunk-6305-2.patch, trunk-6305-3.patch We need cqlsh support for several things: 1. Autocomplete for UPDATE/INSERT/SELECT 2. Autocomplete for ALTER TYPE/CREATE TYPE/DROP TYPE 3. Proper decoding of UserType values (currently showing the encoded blob) 4. Support UserTypes in DESCRIBE 5. Separate DESCRIBE TYPES|TYPE name cmds -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CASSANDRA-6703) cqlsh support for static CQL3 columns
Mikhail Stepura created CASSANDRA-6703: -- Summary: cqlsh support for static CQL3 columns Key: CASSANDRA-6703 URL: https://issues.apache.org/jira/browse/CASSANDRA-6703 Project: Cassandra Issue Type: Sub-task Reporter: Mikhail Stepura Assignee: Mikhail Stepura Fix For: 2.0.6 * Show static columns in DESCRIBE * CREATE/ALTER TABLE autocompletions -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CASSANDRA-6704) Create wide row scanners
Edward Capriolo created CASSANDRA-6704:
--
Summary: Create wide row scanners
Key: CASSANDRA-6704
URL: https://issues.apache.org/jira/browse/CASSANDRA-6704
Project: Cassandra
Issue Type: New Feature
Reporter: Edward Capriolo
Assignee: Edward Capriolo
The BigTable white paper demonstrates the use of scanners to iterate over rows
and columns.
http://static.googleusercontent.com/media/research.google.com/en/us/archive/bigtable-osdi06.pdf
Because Cassandra does not have a primary sorting on row keys scanning over
ranges of row keys is less useful.
However we can use the scanner concept to operate on wide rows. For example
many times a user wishes to do some custom processing inside a row and does not
wish to carry the data across the network to do this processing.
I have already implemented thrift methods to compile dynamic groovy code into
Filters as well as some code that uses a Filter to page through and process
data on the server side.
https://github.com/edwardcapriolo/cassandra/compare/apache:trunk...trunk
The following is a working code snippet.
{code}
@Test
public void test_scanner() throws Exception
{
ColumnParent cp = new ColumnParent();
cp.setColumn_family(Standard1);
ByteBuffer key = ByteBuffer.wrap(rscannerkey.getBytes());
for (char a='a'; a 'g'; a++){
Column c1 = new Column();
c1.setName((a+).getBytes());
c1.setValue(new byte [0]);
c1.setTimestamp(System.nanoTime());
server.insert(key, cp, c1, ConsistencyLevel.ONE);
}
FilterDesc d = new FilterDesc();
d.setSpec(GROOVY_CLASS_LOADER);
d.setName(limit3);
d.setCode(import org.apache.cassandra.dht.* \n +
import org.apache.cassandra.thrift.* \n +
public class Limit3 implements SFilter { \n +
public FilterReturn filter(ColumnOrSuperColumn col,
ListColumnOrSuperColumn filtered) {\n+
filtered.add(col);\n+
return filtered.size() 3 ? FilterReturn.FILTER_MORE :
FilterReturn.FILTER_DONE;\n+
} \n +
}\n);
server.create_filter(d);
ScannerResult res = server.create_scanner(Standard1, limit3, key,
ByteBuffer.wrap(a.getBytes()));
Assert.assertEquals(3, res.results.size());
}
{code}
I am going to be working on this code over the next few weeks but I wanted to
get the concept our early so the design can see some criticism.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6704) Create wide row scanners
[
https://issues.apache.org/jira/browse/CASSANDRA-6704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13901012#comment-13901012
]
Brandon Williams commented on CASSANDRA-6704:
-
Seems similar to CASSANDRA-4914
Create wide row scanners
Key: CASSANDRA-6704
URL: https://issues.apache.org/jira/browse/CASSANDRA-6704
Project: Cassandra
Issue Type: New Feature
Reporter: Edward Capriolo
Assignee: Edward Capriolo
The BigTable white paper demonstrates the use of scanners to iterate over
rows and columns.
http://static.googleusercontent.com/media/research.google.com/en/us/archive/bigtable-osdi06.pdf
Because Cassandra does not have a primary sorting on row keys scanning over
ranges of row keys is less useful.
However we can use the scanner concept to operate on wide rows. For example
many times a user wishes to do some custom processing inside a row and does
not wish to carry the data across the network to do this processing.
I have already implemented thrift methods to compile dynamic groovy code into
Filters as well as some code that uses a Filter to page through and process
data on the server side.
https://github.com/edwardcapriolo/cassandra/compare/apache:trunk...trunk
The following is a working code snippet.
{code}
@Test
public void test_scanner() throws Exception
{
ColumnParent cp = new ColumnParent();
cp.setColumn_family(Standard1);
ByteBuffer key = ByteBuffer.wrap(rscannerkey.getBytes());
for (char a='a'; a 'g'; a++){
Column c1 = new Column();
c1.setName((a+).getBytes());
c1.setValue(new byte [0]);
c1.setTimestamp(System.nanoTime());
server.insert(key, cp, c1, ConsistencyLevel.ONE);
}
FilterDesc d = new FilterDesc();
d.setSpec(GROOVY_CLASS_LOADER);
d.setName(limit3);
d.setCode(import org.apache.cassandra.dht.* \n +
import org.apache.cassandra.thrift.* \n +
public class Limit3 implements SFilter { \n +
public FilterReturn filter(ColumnOrSuperColumn col,
ListColumnOrSuperColumn filtered) {\n+
filtered.add(col);\n+
return filtered.size() 3 ? FilterReturn.FILTER_MORE :
FilterReturn.FILTER_DONE;\n+
} \n +
}\n);
server.create_filter(d);
ScannerResult res = server.create_scanner(Standard1, limit3, key,
ByteBuffer.wrap(a.getBytes()));
Assert.assertEquals(3, res.results.size());
}
{code}
I am going to be working on this code over the next few weeks but I wanted to
get the concept our early so the design can see some criticism.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6704) Create wide row scanners
[
https://issues.apache.org/jira/browse/CASSANDRA-6704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13901016#comment-13901016
]
Aleksey Yeschenko commented on CASSANDRA-6704:
--
+ CASSANDRA-6167
Create wide row scanners
Key: CASSANDRA-6704
URL: https://issues.apache.org/jira/browse/CASSANDRA-6704
Project: Cassandra
Issue Type: New Feature
Reporter: Edward Capriolo
Assignee: Edward Capriolo
The BigTable white paper demonstrates the use of scanners to iterate over
rows and columns.
http://static.googleusercontent.com/media/research.google.com/en/us/archive/bigtable-osdi06.pdf
Because Cassandra does not have a primary sorting on row keys scanning over
ranges of row keys is less useful.
However we can use the scanner concept to operate on wide rows. For example
many times a user wishes to do some custom processing inside a row and does
not wish to carry the data across the network to do this processing.
I have already implemented thrift methods to compile dynamic groovy code into
Filters as well as some code that uses a Filter to page through and process
data on the server side.
https://github.com/edwardcapriolo/cassandra/compare/apache:trunk...trunk
The following is a working code snippet.
{code}
@Test
public void test_scanner() throws Exception
{
ColumnParent cp = new ColumnParent();
cp.setColumn_family(Standard1);
ByteBuffer key = ByteBuffer.wrap(rscannerkey.getBytes());
for (char a='a'; a 'g'; a++){
Column c1 = new Column();
c1.setName((a+).getBytes());
c1.setValue(new byte [0]);
c1.setTimestamp(System.nanoTime());
server.insert(key, cp, c1, ConsistencyLevel.ONE);
}
FilterDesc d = new FilterDesc();
d.setSpec(GROOVY_CLASS_LOADER);
d.setName(limit3);
d.setCode(import org.apache.cassandra.dht.* \n +
import org.apache.cassandra.thrift.* \n +
public class Limit3 implements SFilter { \n +
public FilterReturn filter(ColumnOrSuperColumn col,
ListColumnOrSuperColumn filtered) {\n+
filtered.add(col);\n+
return filtered.size() 3 ? FilterReturn.FILTER_MORE :
FilterReturn.FILTER_DONE;\n+
} \n +
}\n);
server.create_filter(d);
ScannerResult res = server.create_scanner(Standard1, limit3, key,
ByteBuffer.wrap(a.getBytes()));
Assert.assertEquals(3, res.results.size());
}
{code}
I am going to be working on this code over the next few weeks but I wanted to
get the concept our early so the design can see some criticism.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6704) Create wide row scanners
[
https://issues.apache.org/jira/browse/CASSANDRA-6704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13901022#comment-13901022
]
Edward Capriolo commented on CASSANDRA-6704:
This example is basically accomplishing CASSANDRA-6167. CASSANDRA-4914 is more
then this is trying to accomplish (general aggregation). A scanner is a really
nice medium between complete blocking queries and map reduce. You could
build an aggregation, or even a rolling aggregation but flow control comes from
the client.
Create wide row scanners
Key: CASSANDRA-6704
URL: https://issues.apache.org/jira/browse/CASSANDRA-6704
Project: Cassandra
Issue Type: New Feature
Reporter: Edward Capriolo
Assignee: Edward Capriolo
The BigTable white paper demonstrates the use of scanners to iterate over
rows and columns.
http://static.googleusercontent.com/media/research.google.com/en/us/archive/bigtable-osdi06.pdf
Because Cassandra does not have a primary sorting on row keys scanning over
ranges of row keys is less useful.
However we can use the scanner concept to operate on wide rows. For example
many times a user wishes to do some custom processing inside a row and does
not wish to carry the data across the network to do this processing.
I have already implemented thrift methods to compile dynamic groovy code into
Filters as well as some code that uses a Filter to page through and process
data on the server side.
https://github.com/edwardcapriolo/cassandra/compare/apache:trunk...trunk
The following is a working code snippet.
{code}
@Test
public void test_scanner() throws Exception
{
ColumnParent cp = new ColumnParent();
cp.setColumn_family(Standard1);
ByteBuffer key = ByteBuffer.wrap(rscannerkey.getBytes());
for (char a='a'; a 'g'; a++){
Column c1 = new Column();
c1.setName((a+).getBytes());
c1.setValue(new byte [0]);
c1.setTimestamp(System.nanoTime());
server.insert(key, cp, c1, ConsistencyLevel.ONE);
}
FilterDesc d = new FilterDesc();
d.setSpec(GROOVY_CLASS_LOADER);
d.setName(limit3);
d.setCode(import org.apache.cassandra.dht.* \n +
import org.apache.cassandra.thrift.* \n +
public class Limit3 implements SFilter { \n +
public FilterReturn filter(ColumnOrSuperColumn col,
ListColumnOrSuperColumn filtered) {\n+
filtered.add(col);\n+
return filtered.size() 3 ? FilterReturn.FILTER_MORE :
FilterReturn.FILTER_DONE;\n+
} \n +
}\n);
server.create_filter(d);
ScannerResult res = server.create_scanner(Standard1, limit3, key,
ByteBuffer.wrap(a.getBytes()));
Assert.assertEquals(3, res.results.size());
}
{code}
I am going to be working on this code over the next few weeks but I wanted to
get the concept our early so the design can see some criticism.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6704) Create wide row scanners
[
https://issues.apache.org/jira/browse/CASSANDRA-6704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13901044#comment-13901044
]
Aleksey Yeschenko commented on CASSANDRA-6704:
--
Which is why I linked to it. With 4914 and 6167 combined (all mapping neatly to
CQL), what are the use cases that would justify adding all this complexity (+
groovy), that we can't live without?
Create wide row scanners
Key: CASSANDRA-6704
URL: https://issues.apache.org/jira/browse/CASSANDRA-6704
Project: Cassandra
Issue Type: New Feature
Reporter: Edward Capriolo
Assignee: Edward Capriolo
The BigTable white paper demonstrates the use of scanners to iterate over
rows and columns.
http://static.googleusercontent.com/media/research.google.com/en/us/archive/bigtable-osdi06.pdf
Because Cassandra does not have a primary sorting on row keys scanning over
ranges of row keys is less useful.
However we can use the scanner concept to operate on wide rows. For example
many times a user wishes to do some custom processing inside a row and does
not wish to carry the data across the network to do this processing.
I have already implemented thrift methods to compile dynamic groovy code into
Filters as well as some code that uses a Filter to page through and process
data on the server side.
https://github.com/edwardcapriolo/cassandra/compare/apache:trunk...trunk
The following is a working code snippet.
{code}
@Test
public void test_scanner() throws Exception
{
ColumnParent cp = new ColumnParent();
cp.setColumn_family(Standard1);
ByteBuffer key = ByteBuffer.wrap(rscannerkey.getBytes());
for (char a='a'; a 'g'; a++){
Column c1 = new Column();
c1.setName((a+).getBytes());
c1.setValue(new byte [0]);
c1.setTimestamp(System.nanoTime());
server.insert(key, cp, c1, ConsistencyLevel.ONE);
}
FilterDesc d = new FilterDesc();
d.setSpec(GROOVY_CLASS_LOADER);
d.setName(limit3);
d.setCode(import org.apache.cassandra.dht.* \n +
import org.apache.cassandra.thrift.* \n +
public class Limit3 implements SFilter { \n +
public FilterReturn filter(ColumnOrSuperColumn col,
ListColumnOrSuperColumn filtered) {\n+
filtered.add(col);\n+
return filtered.size() 3 ? FilterReturn.FILTER_MORE :
FilterReturn.FILTER_DONE;\n+
} \n +
}\n);
server.create_filter(d);
ScannerResult res = server.create_scanner(Standard1, limit3, key,
ByteBuffer.wrap(a.getBytes()));
Assert.assertEquals(3, res.results.size());
}
{code}
I am going to be working on this code over the next few weeks but I wanted to
get the concept our early so the design can see some criticism.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6566) Differencer should not run in AntiEntropy Stage
[ https://issues.apache.org/jira/browse/CASSANDRA-6566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-6566: -- Attachment: 6566-2.0.txt (also: https://github.com/yukim/cassandra/tree/6566-1) Two improvements in the patch: * Remove snapshot latch so that snapshotting does not block ANTI_ENTROPY stage. * Move differencers from ANTI_ENTROPY stage to different executor. Differencer should not run in AntiEntropy Stage --- Key: CASSANDRA-6566 URL: https://issues.apache.org/jira/browse/CASSANDRA-6566 Project: Cassandra Issue Type: Improvement Components: Core Reporter: sankalp kohli Priority: Minor Attachments: 6566-2.0.txt The Differencing currently runs in AntiEntropy stage. When there are lot of ranges which do not match, it takes sometime to compute the diff in ranges. Also with increase in Merkle tree height it will take even more time in case of large diffs. This causes other things to get blocked behind this. Also no other repair messages can be processed. Example: If a node is doing differencing for a repair, and Validation compaction is done for another repair, it needs to block to send the tree over till Differencing is done. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6566) Differencer should not run in AntiEntropy Stage
[ https://issues.apache.org/jira/browse/CASSANDRA-6566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-6566: -- Fix Version/s: 2.0.6 Assignee: Yuki Morishita Differencer should not run in AntiEntropy Stage --- Key: CASSANDRA-6566 URL: https://issues.apache.org/jira/browse/CASSANDRA-6566 Project: Cassandra Issue Type: Improvement Components: Core Reporter: sankalp kohli Assignee: Yuki Morishita Priority: Minor Fix For: 2.0.6 Attachments: 6566-2.0.txt The Differencing currently runs in AntiEntropy stage. When there are lot of ranges which do not match, it takes sometime to compute the diff in ranges. Also with increase in Merkle tree height it will take even more time in case of large diffs. This causes other things to get blocked behind this. Also no other repair messages can be processed. Example: If a node is doing differencing for a repair, and Validation compaction is done for another repair, it needs to block to send the tree over till Differencing is done. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6167) Add end-slice termination predicate
[
https://issues.apache.org/jira/browse/CASSANDRA-6167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13901052#comment-13901052
]
Tupshin Harper commented on CASSANDRA-6167:
---
Adding an example for how this could be used for efficient client-side
implemented aggregation.
Assume a CQL table with the following structure:
CREATE TABLE t6167 (
uid text,
evtts int,
evtval text,
PRIMARY KEY (uid, evtts)
) WITH CLUSTERING ORDER BY (evtts DESC)
(In a real system, evtts would probably be a timeuuid to avoid risk of
collisions)
Assume data in that table for a single partition looks like
uid | evtts | evtval
-+---+
1 | 7 |0.5
1 | 6 | -1.4
1 | 5 |0.3
1 | 4 | s5.1
1 | 3 |1.7
1 | 2 |1.3
1 | 1 |2.1
(Ignore the monotonically increasing timestamps. Here only for simplicity.
Timeuuids, there would not do this, of course)
So this structure is used to write new floats (only used as an example of
arbitrary aggregation)
Source events will write values such as 2.1 and 1.3
At read time, the logic would be as follows:
you would get a slice of the partition from most recent (hence the DESC
ordering) back to either beginning of the partition or the most recently
written summation value (e.g. s5.1 and s4.5).
With the syntax from option 2 above (and using % as a wildcard), you would get
SELECT uid,evtts,evtval from t6167 where uid=1 and evtts NOW() UNTIL
PARTITION evtval='s%'
Asuming NOW() = 8, and the above data, this would return :
uid | evtts | evtval
-+---+
1 | 7 |0.5
1 | 6 | -1.4
1 | 5 |0.3
1 | 4 | s5.1
At that point, the client would return evtval 4.5 by doing client-side
agregation of those 4 rows.
Then optionally, if enough time had elapsed since the last aggregation column
to ensure no out of order delivery (business rule), then that same reader
thread would write back a new aggregation value at an appropriate timestamp
lagging behing the current time by the potential out-of-order delivery window.
These writes would be inherently idemptotent, and hence race-condition free and
could be easily tuned for delivery window and aggregation frequency to various
workloads
Add end-slice termination predicate
---
Key: CASSANDRA-6167
URL: https://issues.apache.org/jira/browse/CASSANDRA-6167
Project: Cassandra
Issue Type: Improvement
Components: API, Core
Reporter: Tupshin Harper
Priority: Minor
Labels: ponies
When doing performing storage-engine slices, it would sometimes be beneficial
to have the slice terminate for other reasons other than number of columns or
min/max cell name.
Since we are able to look at the contents of each cell as we read it, this is
potentially doable with very little overhead.
Probably more challenging than the storage-engine implementation itself, is
to come up with appropriate CQL syntax (Thrift, should we decide to support
it, would be trivial).
Two possibilities ar
1) special where function:
SELECT pk,event from cf WHERE pk IN (1,5,10,11) AND
partition_predicate({predicate})
or a bigger language change, but i think one I prefer. more like:
2) SELECT pk,event from cf where pk IN (1,5,10,11) UNTIL PARTITION event
{predicate}
Neither feels perfect, but I do like the fact that the second one at least
clearly states what it is intended to do.
By using UNTIL PARTITION, we could re-use the UNTIL keyword to handle other
kinds of early-termination of selects that the coordinator might be able to
do, such as stop retrieving additional rows from shards after a particular
criterion was met.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6704) Create wide row scanners
[
https://issues.apache.org/jira/browse/CASSANDRA-6704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13901053#comment-13901053
]
Tupshin Harper commented on CASSANDRA-6704:
---
I added a comment to CASSANDRA-6167 explaining how that would be used for read
aggregation. Ed is right that there is tremendous overlap in the goals of the
two tickets.
Create wide row scanners
Key: CASSANDRA-6704
URL: https://issues.apache.org/jira/browse/CASSANDRA-6704
Project: Cassandra
Issue Type: New Feature
Reporter: Edward Capriolo
Assignee: Edward Capriolo
The BigTable white paper demonstrates the use of scanners to iterate over
rows and columns.
http://static.googleusercontent.com/media/research.google.com/en/us/archive/bigtable-osdi06.pdf
Because Cassandra does not have a primary sorting on row keys scanning over
ranges of row keys is less useful.
However we can use the scanner concept to operate on wide rows. For example
many times a user wishes to do some custom processing inside a row and does
not wish to carry the data across the network to do this processing.
I have already implemented thrift methods to compile dynamic groovy code into
Filters as well as some code that uses a Filter to page through and process
data on the server side.
https://github.com/edwardcapriolo/cassandra/compare/apache:trunk...trunk
The following is a working code snippet.
{code}
@Test
public void test_scanner() throws Exception
{
ColumnParent cp = new ColumnParent();
cp.setColumn_family(Standard1);
ByteBuffer key = ByteBuffer.wrap(rscannerkey.getBytes());
for (char a='a'; a 'g'; a++){
Column c1 = new Column();
c1.setName((a+).getBytes());
c1.setValue(new byte [0]);
c1.setTimestamp(System.nanoTime());
server.insert(key, cp, c1, ConsistencyLevel.ONE);
}
FilterDesc d = new FilterDesc();
d.setSpec(GROOVY_CLASS_LOADER);
d.setName(limit3);
d.setCode(import org.apache.cassandra.dht.* \n +
import org.apache.cassandra.thrift.* \n +
public class Limit3 implements SFilter { \n +
public FilterReturn filter(ColumnOrSuperColumn col,
ListColumnOrSuperColumn filtered) {\n+
filtered.add(col);\n+
return filtered.size() 3 ? FilterReturn.FILTER_MORE :
FilterReturn.FILTER_DONE;\n+
} \n +
}\n);
server.create_filter(d);
ScannerResult res = server.create_scanner(Standard1, limit3, key,
ByteBuffer.wrap(a.getBytes()));
Assert.assertEquals(3, res.results.size());
}
{code}
I am going to be working on this code over the next few weeks but I wanted to
get the concept our early so the design can see some criticism.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6704) Create wide row scanners
[
https://issues.apache.org/jira/browse/CASSANDRA-6704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13901054#comment-13901054
]
Edward Capriolo commented on CASSANDRA-6704:
You could argue that groovy is complex, but anyone that can write java can
write groovy. I can argue CQL is complex, not everyone can write antlr or query
parsers. It took me 1 day to write this interface.
About 1 year ago I was working on intravert
(https://github.com/zznate/intravert-ug). You say that all maps really neatly
into CQL but in reality its been a year, and most of these tickets are still
just talk.
Create wide row scanners
Key: CASSANDRA-6704
URL: https://issues.apache.org/jira/browse/CASSANDRA-6704
Project: Cassandra
Issue Type: New Feature
Reporter: Edward Capriolo
Assignee: Edward Capriolo
The BigTable white paper demonstrates the use of scanners to iterate over
rows and columns.
http://static.googleusercontent.com/media/research.google.com/en/us/archive/bigtable-osdi06.pdf
Because Cassandra does not have a primary sorting on row keys scanning over
ranges of row keys is less useful.
However we can use the scanner concept to operate on wide rows. For example
many times a user wishes to do some custom processing inside a row and does
not wish to carry the data across the network to do this processing.
I have already implemented thrift methods to compile dynamic groovy code into
Filters as well as some code that uses a Filter to page through and process
data on the server side.
https://github.com/edwardcapriolo/cassandra/compare/apache:trunk...trunk
The following is a working code snippet.
{code}
@Test
public void test_scanner() throws Exception
{
ColumnParent cp = new ColumnParent();
cp.setColumn_family(Standard1);
ByteBuffer key = ByteBuffer.wrap(rscannerkey.getBytes());
for (char a='a'; a 'g'; a++){
Column c1 = new Column();
c1.setName((a+).getBytes());
c1.setValue(new byte [0]);
c1.setTimestamp(System.nanoTime());
server.insert(key, cp, c1, ConsistencyLevel.ONE);
}
FilterDesc d = new FilterDesc();
d.setSpec(GROOVY_CLASS_LOADER);
d.setName(limit3);
d.setCode(import org.apache.cassandra.dht.* \n +
import org.apache.cassandra.thrift.* \n +
public class Limit3 implements SFilter { \n +
public FilterReturn filter(ColumnOrSuperColumn col,
ListColumnOrSuperColumn filtered) {\n+
filtered.add(col);\n+
return filtered.size() 3 ? FilterReturn.FILTER_MORE :
FilterReturn.FILTER_DONE;\n+
} \n +
}\n);
server.create_filter(d);
ScannerResult res = server.create_scanner(Standard1, limit3, key,
ByteBuffer.wrap(a.getBytes()));
Assert.assertEquals(3, res.results.size());
}
{code}
I am going to be working on this code over the next few weeks but I wanted to
get the concept our early so the design can see some criticism.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Comment Edited] (CASSANDRA-6704) Create wide row scanners
[
https://issues.apache.org/jira/browse/CASSANDRA-6704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13901054#comment-13901054
]
Edward Capriolo edited comment on CASSANDRA-6704 at 2/14/14 2:43 AM:
-
You could argue that groovy is complex, but anyone that can write java can
write groovy. I can argue CQL is complex, not everyone can write antlr or query
parsers. It took me 1 day to write this interface.
About 1 year ago I was working on intravert
(https://github.com/zznate/intravert-ug). You say that all maps really neatly
into CQL but in reality its been a year, and most of these tickets are still
just talk, so what approach is actually easy to accomplish?
was (Author: appodictic):
You could argue that groovy is complex, but anyone that can write java can
write groovy. I can argue CQL is complex, not everyone can write antlr or query
parsers. It took me 1 day to write this interface.
About 1 year ago I was working on intravert
(https://github.com/zznate/intravert-ug). You say that all maps really neatly
into CQL but in reality its been a year, and most of these tickets are still
just talk.
Create wide row scanners
Key: CASSANDRA-6704
URL: https://issues.apache.org/jira/browse/CASSANDRA-6704
Project: Cassandra
Issue Type: New Feature
Reporter: Edward Capriolo
Assignee: Edward Capriolo
The BigTable white paper demonstrates the use of scanners to iterate over
rows and columns.
http://static.googleusercontent.com/media/research.google.com/en/us/archive/bigtable-osdi06.pdf
Because Cassandra does not have a primary sorting on row keys scanning over
ranges of row keys is less useful.
However we can use the scanner concept to operate on wide rows. For example
many times a user wishes to do some custom processing inside a row and does
not wish to carry the data across the network to do this processing.
I have already implemented thrift methods to compile dynamic groovy code into
Filters as well as some code that uses a Filter to page through and process
data on the server side.
https://github.com/edwardcapriolo/cassandra/compare/apache:trunk...trunk
The following is a working code snippet.
{code}
@Test
public void test_scanner() throws Exception
{
ColumnParent cp = new ColumnParent();
cp.setColumn_family(Standard1);
ByteBuffer key = ByteBuffer.wrap(rscannerkey.getBytes());
for (char a='a'; a 'g'; a++){
Column c1 = new Column();
c1.setName((a+).getBytes());
c1.setValue(new byte [0]);
c1.setTimestamp(System.nanoTime());
server.insert(key, cp, c1, ConsistencyLevel.ONE);
}
FilterDesc d = new FilterDesc();
d.setSpec(GROOVY_CLASS_LOADER);
d.setName(limit3);
d.setCode(import org.apache.cassandra.dht.* \n +
import org.apache.cassandra.thrift.* \n +
public class Limit3 implements SFilter { \n +
public FilterReturn filter(ColumnOrSuperColumn col,
ListColumnOrSuperColumn filtered) {\n+
filtered.add(col);\n+
return filtered.size() 3 ? FilterReturn.FILTER_MORE :
FilterReturn.FILTER_DONE;\n+
} \n +
}\n);
server.create_filter(d);
ScannerResult res = server.create_scanner(Standard1, limit3, key,
ByteBuffer.wrap(a.getBytes()));
Assert.assertEquals(3, res.results.size());
}
{code}
I am going to be working on this code over the next few weeks but I wanted to
get the concept our early so the design can see some criticism.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6566) Differencer should not run in AntiEntropy Stage
[ https://issues.apache.org/jira/browse/CASSANDRA-6566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-6566: -- Reviewer: sankalp kohli Can you review, [~kohlisankalp]? Differencer should not run in AntiEntropy Stage --- Key: CASSANDRA-6566 URL: https://issues.apache.org/jira/browse/CASSANDRA-6566 Project: Cassandra Issue Type: Improvement Components: Core Reporter: sankalp kohli Assignee: Yuki Morishita Priority: Minor Fix For: 2.0.6 Attachments: 6566-2.0.txt The Differencing currently runs in AntiEntropy stage. When there are lot of ranges which do not match, it takes sometime to compute the diff in ranges. Also with increase in Merkle tree height it will take even more time in case of large diffs. This causes other things to get blocked behind this. Also no other repair messages can be processed. Example: If a node is doing differencing for a repair, and Validation compaction is done for another repair, it needs to block to send the tree over till Differencing is done. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6704) Create wide row scanners
[
https://issues.apache.org/jira/browse/CASSANDRA-6704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13901064#comment-13901064
]
Edward Capriolo commented on CASSANDRA-6704:
IE should users wait for months/years until a statement like this SELECT
pk,event from cf where pk IN (1,5,10,11) UNTIL PARTITION event {predicate} is
implemented? Agile says iterate fast and don't plan forever. I am a little
tired of waiting for scanners and other cool stuff that hbase (and other nosql
systems) do out of the box.
Create wide row scanners
Key: CASSANDRA-6704
URL: https://issues.apache.org/jira/browse/CASSANDRA-6704
Project: Cassandra
Issue Type: New Feature
Reporter: Edward Capriolo
Assignee: Edward Capriolo
The BigTable white paper demonstrates the use of scanners to iterate over
rows and columns.
http://static.googleusercontent.com/media/research.google.com/en/us/archive/bigtable-osdi06.pdf
Because Cassandra does not have a primary sorting on row keys scanning over
ranges of row keys is less useful.
However we can use the scanner concept to operate on wide rows. For example
many times a user wishes to do some custom processing inside a row and does
not wish to carry the data across the network to do this processing.
I have already implemented thrift methods to compile dynamic groovy code into
Filters as well as some code that uses a Filter to page through and process
data on the server side.
https://github.com/edwardcapriolo/cassandra/compare/apache:trunk...trunk
The following is a working code snippet.
{code}
@Test
public void test_scanner() throws Exception
{
ColumnParent cp = new ColumnParent();
cp.setColumn_family(Standard1);
ByteBuffer key = ByteBuffer.wrap(rscannerkey.getBytes());
for (char a='a'; a 'g'; a++){
Column c1 = new Column();
c1.setName((a+).getBytes());
c1.setValue(new byte [0]);
c1.setTimestamp(System.nanoTime());
server.insert(key, cp, c1, ConsistencyLevel.ONE);
}
FilterDesc d = new FilterDesc();
d.setSpec(GROOVY_CLASS_LOADER);
d.setName(limit3);
d.setCode(import org.apache.cassandra.dht.* \n +
import org.apache.cassandra.thrift.* \n +
public class Limit3 implements SFilter { \n +
public FilterReturn filter(ColumnOrSuperColumn col,
ListColumnOrSuperColumn filtered) {\n+
filtered.add(col);\n+
return filtered.size() 3 ? FilterReturn.FILTER_MORE :
FilterReturn.FILTER_DONE;\n+
} \n +
}\n);
server.create_filter(d);
ScannerResult res = server.create_scanner(Standard1, limit3, key,
ByteBuffer.wrap(a.getBytes()));
Assert.assertEquals(3, res.results.size());
}
{code}
I am going to be working on this code over the next few weeks but I wanted to
get the concept our early so the design can see some criticism.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6704) Create wide row scanners
[
https://issues.apache.org/jira/browse/CASSANDRA-6704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13901067#comment-13901067
]
Brandon Williams commented on CASSANDRA-6704:
-
bq. You could argue that groovy is complex, but anyone that can write java can
write groovy. I can argue CQL is complex, not everyone can write antlr or query
parsers.
This isn't exactly a fair analogy, you should be comparing the complexity of
groovy the language against CQL the language, or the complexity of antlr
against writing a language for the JVM, but not mixing the two and effectively
comparing syntactic complexity on one hand and the machinery necessary to parse
it on the other.
Create wide row scanners
Key: CASSANDRA-6704
URL: https://issues.apache.org/jira/browse/CASSANDRA-6704
Project: Cassandra
Issue Type: New Feature
Reporter: Edward Capriolo
Assignee: Edward Capriolo
The BigTable white paper demonstrates the use of scanners to iterate over
rows and columns.
http://static.googleusercontent.com/media/research.google.com/en/us/archive/bigtable-osdi06.pdf
Because Cassandra does not have a primary sorting on row keys scanning over
ranges of row keys is less useful.
However we can use the scanner concept to operate on wide rows. For example
many times a user wishes to do some custom processing inside a row and does
not wish to carry the data across the network to do this processing.
I have already implemented thrift methods to compile dynamic groovy code into
Filters as well as some code that uses a Filter to page through and process
data on the server side.
https://github.com/edwardcapriolo/cassandra/compare/apache:trunk...trunk
The following is a working code snippet.
{code}
@Test
public void test_scanner() throws Exception
{
ColumnParent cp = new ColumnParent();
cp.setColumn_family(Standard1);
ByteBuffer key = ByteBuffer.wrap(rscannerkey.getBytes());
for (char a='a'; a 'g'; a++){
Column c1 = new Column();
c1.setName((a+).getBytes());
c1.setValue(new byte [0]);
c1.setTimestamp(System.nanoTime());
server.insert(key, cp, c1, ConsistencyLevel.ONE);
}
FilterDesc d = new FilterDesc();
d.setSpec(GROOVY_CLASS_LOADER);
d.setName(limit3);
d.setCode(import org.apache.cassandra.dht.* \n +
import org.apache.cassandra.thrift.* \n +
public class Limit3 implements SFilter { \n +
public FilterReturn filter(ColumnOrSuperColumn col,
ListColumnOrSuperColumn filtered) {\n+
filtered.add(col);\n+
return filtered.size() 3 ? FilterReturn.FILTER_MORE :
FilterReturn.FILTER_DONE;\n+
} \n +
}\n);
server.create_filter(d);
ScannerResult res = server.create_scanner(Standard1, limit3, key,
ByteBuffer.wrap(a.getBytes()));
Assert.assertEquals(3, res.results.size());
}
{code}
I am going to be working on this code over the next few weeks but I wanted to
get the concept our early so the design can see some criticism.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
git commit: Move prepareLatch to local scope
Updated Branches:
refs/heads/trunk ee477cc4d - 5b0eb01c9
Move prepareLatch to local scope
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/5b0eb01c
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/5b0eb01c
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/5b0eb01c
Branch: refs/heads/trunk
Commit: 5b0eb01c9da6a2c27e419e19210f0bfebf5ac216
Parents: ee477cc
Author: Yuki Morishita yu...@apache.org
Authored: Thu Feb 13 21:01:40 2014 -0600
Committer: Yuki Morishita yu...@apache.org
Committed: Thu Feb 13 21:01:40 2014 -0600
--
src/java/org/apache/cassandra/service/ActiveRepairService.java | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/5b0eb01c/src/java/org/apache/cassandra/service/ActiveRepairService.java
--
diff --git a/src/java/org/apache/cassandra/service/ActiveRepairService.java
b/src/java/org/apache/cassandra/service/ActiveRepairService.java
index dc4c66a..232974d 100644
--- a/src/java/org/apache/cassandra/service/ActiveRepairService.java
+++ b/src/java/org/apache/cassandra/service/ActiveRepairService.java
@@ -100,7 +100,6 @@ public class ActiveRepairService
private final ConcurrentMapUUID, ParentRepairSession
parentRepairSessions;
-private CountDownLatch prepareLatch = null;
/**
* Protected constructor. Use ActiveRepairService.instance.
*/
@@ -217,13 +216,13 @@ public class ActiveRepairService
{
UUID parentRepairSession = UUIDGen.getTimeUUID();
registerParentRepairSession(parentRepairSession, columnFamilyStores,
ranges);
-prepareLatch = new CountDownLatch(endpoints.size());
+final CountDownLatch prepareLatch = new
CountDownLatch(endpoints.size());
IAsyncCallback callback = new IAsyncCallback()
{
@Override
public void response(MessageIn msg)
{
-ActiveRepairService.this.prepareLatch.countDown();
+prepareLatch.countDown();
}
@Override
[jira] [Commented] (CASSANDRA-6704) Create wide row scanners
[
https://issues.apache.org/jira/browse/CASSANDRA-6704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13901068#comment-13901068
]
Aleksey Yeschenko commented on CASSANDRA-6704:
--
You are welcome to help with those open tickets (:
Create wide row scanners
Key: CASSANDRA-6704
URL: https://issues.apache.org/jira/browse/CASSANDRA-6704
Project: Cassandra
Issue Type: New Feature
Reporter: Edward Capriolo
Assignee: Edward Capriolo
The BigTable white paper demonstrates the use of scanners to iterate over
rows and columns.
http://static.googleusercontent.com/media/research.google.com/en/us/archive/bigtable-osdi06.pdf
Because Cassandra does not have a primary sorting on row keys scanning over
ranges of row keys is less useful.
However we can use the scanner concept to operate on wide rows. For example
many times a user wishes to do some custom processing inside a row and does
not wish to carry the data across the network to do this processing.
I have already implemented thrift methods to compile dynamic groovy code into
Filters as well as some code that uses a Filter to page through and process
data on the server side.
https://github.com/edwardcapriolo/cassandra/compare/apache:trunk...trunk
The following is a working code snippet.
{code}
@Test
public void test_scanner() throws Exception
{
ColumnParent cp = new ColumnParent();
cp.setColumn_family(Standard1);
ByteBuffer key = ByteBuffer.wrap(rscannerkey.getBytes());
for (char a='a'; a 'g'; a++){
Column c1 = new Column();
c1.setName((a+).getBytes());
c1.setValue(new byte [0]);
c1.setTimestamp(System.nanoTime());
server.insert(key, cp, c1, ConsistencyLevel.ONE);
}
FilterDesc d = new FilterDesc();
d.setSpec(GROOVY_CLASS_LOADER);
d.setName(limit3);
d.setCode(import org.apache.cassandra.dht.* \n +
import org.apache.cassandra.thrift.* \n +
public class Limit3 implements SFilter { \n +
public FilterReturn filter(ColumnOrSuperColumn col,
ListColumnOrSuperColumn filtered) {\n+
filtered.add(col);\n+
return filtered.size() 3 ? FilterReturn.FILTER_MORE :
FilterReturn.FILTER_DONE;\n+
} \n +
}\n);
server.create_filter(d);
ScannerResult res = server.create_scanner(Standard1, limit3, key,
ByteBuffer.wrap(a.getBytes()));
Assert.assertEquals(3, res.results.size());
}
{code}
I am going to be working on this code over the next few weeks but I wanted to
get the concept our early so the design can see some criticism.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6561) Static columns in CQL3
[
https://issues.apache.org/jira/browse/CASSANDRA-6561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13901087#comment-13901087
]
Aleksey Yeschenko commented on CASSANDRA-6561:
--
All right.
Issues:
- ALTER TABLE RENAME allows renaming static columns (should not)
- DELETE static_col FROM table WHERE partition_key = X and clustering_col = Y
should? probably throw an error, and not delete the static_col? (not sure about
this one)
- continuing with the DELETEs, DELETE static_col, regular_col FROM table WHERE
partition_key = X will throw Missing mandatory PRIMARY KEY part ck since
static_col specified, which is minor, of course, but should pick first
non-static column instead (DeleteStatement)
Nit: CFMetaData.SchemaColumnsCf still has 'is_static' in it
Typo: 'buildt' in 'Note that we know that only the first group buildt can be
static' in ColumnGroupMap
Wishes:
- I'd prefer BEGIN CAS BATCH, b/c currently you can use either BEGIN UNLOGGED
BATCH or BEGIN [LOGGED] BATCH with conditions, and it confuses things. I prefer
explicit here.
- I'd prefer maybeUpdatePrefix() to updatePrefix()
Static columns in CQL3
--
Key: CASSANDRA-6561
URL: https://issues.apache.org/jira/browse/CASSANDRA-6561
Project: Cassandra
Issue Type: New Feature
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Fix For: 2.0.6
I'd like to suggest the following idea for adding static columns to CQL3.
I'll note that the basic idea has been suggested by jhalliday on irc but the
rest of the details are mine and I should be blamed for anything stupid in
what follows.
Let me start with a rational: there is 2 main family of CF that have been
historically used in Thrift: static ones and dynamic ones. CQL3 handles both
family through the presence or not of clustering columns. There is however
some cases where mixing both behavior has its use. I like to think of those
use cases as 3 broad category:
# to denormalize small amounts of not-entirely-static data in otherwise
static entities. It's say tags for a product or custom properties in a
user profile. This is why we've added CQL3 collections. Importantly, this is
the *only* use case for which collections are meant (which doesn't diminishes
their usefulness imo, and I wouldn't disagree that we've maybe not
communicated this too well).
# to optimize fetching both a static entity and related dynamic ones. Say you
have blog posts, and each post has associated comments (chronologically
ordered). *And* say that a very common query is fetch a post and its 50 last
comments. In that case, it *might* be beneficial to store a blog post
(static entity) in the same underlying CF than it's comments for performance
reason. So that fetch a post and it's 50 last comments is just one slice
internally.
# you want to CAS rows of a dynamic partition based on some partition
condition. This is the same use case than why CASSANDRA-5633 exists for.
As said above, 1) is already covered by collections, but 2) and 3) are not
(and
I strongly believe collections are not the right fit, API wise, for those).
Also, note that I don't want to underestimate the usefulness of 2). In most
cases, using a separate table for the blog posts and the comments is The
Right Solution, and trying to do 2) is premature optimisation. Yet, when used
properly, that kind of optimisation can make a difference, so I think having
a relatively native solution for it in CQL3 could make sense.
Regarding 3), though CASSANDRA-5633 would provide one solution for it, I have
the feeling that static columns actually are a more natural approach (in term
of API). That's arguably more of a personal opinion/feeling though.
So long story short, CQL3 lacks a way to mix both some static and dynamic
rows in the same partition of the same CQL3 table, and I think such a tool
could have it's use.
The proposal is thus to allow static columns. Static columns would only
make sense in table with clustering columns (the dynamic ones). A static
column value would be static to the partition (all rows of the partition
would share the value for such column). The syntax would just be:
{noformat}
CREATE TABLE t (
k text,
s text static,
i int,
v text,
PRIMARY KEY (k, i)
)
{noformat}
then you'd get:
{noformat}
INSERT INTO t(k, s, i, v) VALUES (k0, I'm shared, 0, foo);
INSERT INTO t(k, s, i, v) VALUES (k0, I'm still shared, 1, bar);
SELECT * FROM t;
k | s | i |v
k0 | I'm still shared | 0 | bar
k0 | I'm still shared | 1 | foo
{noformat}
There would be a few semantic details to decide on regarding deletions, ttl,
etc. but let's see if we agree it's a good idea first before ironing those
out.
One last
[jira] [Commented] (CASSANDRA-6704) Create wide row scanners
[
https://issues.apache.org/jira/browse/CASSANDRA-6704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13901089#comment-13901089
]
Edward Capriolo commented on CASSANDRA-6704:
{qutote}
This isn't exactly a fair analogy, you should be comparing the complexity of
groovy the language against CQL the language, or the complexity of antlr
against writing a language for the JVM, but not mixing the two and effectively
comparing syntactic complexity on one hand and the machinery necessary to parse
it on the other.
{quote}
As for this issue, the google clearly saw a rational for making scanners in
BigTable when they produced their white paper. CQL is declarative language and
Scanners and Filters (written in groovy) are imperative programming.
CASSANDRA-6167 is just one tiny case of what you can do with Scanners and
Filters and it is a 4 month old ticket. I'm not against anyone adding whatever
to CQL. Go ahead have fun, trying to make a DSL for everything :). Should that
stop everyone in the world from adding any cool feature to thrift though? I
think no.
Create wide row scanners
Key: CASSANDRA-6704
URL: https://issues.apache.org/jira/browse/CASSANDRA-6704
Project: Cassandra
Issue Type: New Feature
Reporter: Edward Capriolo
Assignee: Edward Capriolo
The BigTable white paper demonstrates the use of scanners to iterate over
rows and columns.
http://static.googleusercontent.com/media/research.google.com/en/us/archive/bigtable-osdi06.pdf
Because Cassandra does not have a primary sorting on row keys scanning over
ranges of row keys is less useful.
However we can use the scanner concept to operate on wide rows. For example
many times a user wishes to do some custom processing inside a row and does
not wish to carry the data across the network to do this processing.
I have already implemented thrift methods to compile dynamic groovy code into
Filters as well as some code that uses a Filter to page through and process
data on the server side.
https://github.com/edwardcapriolo/cassandra/compare/apache:trunk...trunk
The following is a working code snippet.
{code}
@Test
public void test_scanner() throws Exception
{
ColumnParent cp = new ColumnParent();
cp.setColumn_family(Standard1);
ByteBuffer key = ByteBuffer.wrap(rscannerkey.getBytes());
for (char a='a'; a 'g'; a++){
Column c1 = new Column();
c1.setName((a+).getBytes());
c1.setValue(new byte [0]);
c1.setTimestamp(System.nanoTime());
server.insert(key, cp, c1, ConsistencyLevel.ONE);
}
FilterDesc d = new FilterDesc();
d.setSpec(GROOVY_CLASS_LOADER);
d.setName(limit3);
d.setCode(import org.apache.cassandra.dht.* \n +
import org.apache.cassandra.thrift.* \n +
public class Limit3 implements SFilter { \n +
public FilterReturn filter(ColumnOrSuperColumn col,
ListColumnOrSuperColumn filtered) {\n+
filtered.add(col);\n+
return filtered.size() 3 ? FilterReturn.FILTER_MORE :
FilterReturn.FILTER_DONE;\n+
} \n +
}\n);
server.create_filter(d);
ScannerResult res = server.create_scanner(Standard1, limit3, key,
ByteBuffer.wrap(a.getBytes()));
Assert.assertEquals(3, res.results.size());
}
{code}
I am going to be working on this code over the next few weeks but I wanted to
get the concept our early so the design can see some criticism.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CASSANDRA-6704) Create wide row scanners
[
https://issues.apache.org/jira/browse/CASSANDRA-6704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13901094#comment-13901094
]
Jonathan Ellis commented on CASSANDRA-6704:
---
I hear your frustration that 6167 is four months old with little progress, but
I think Aleksey is right that a more productive response is let me help figure
out how to do this right, not let's implement something quick and dirty
because that's faster.
Actually, 6167 may be a bit of a red herring because I think CASSANDRA-5970 is
even closer to what you want, and I've offered a pretty clear path forward
there. (The obvious next step after build-in filtering functions would be
user-defined filtering functions.)
Create wide row scanners
Key: CASSANDRA-6704
URL: https://issues.apache.org/jira/browse/CASSANDRA-6704
Project: Cassandra
Issue Type: New Feature
Reporter: Edward Capriolo
Assignee: Edward Capriolo
The BigTable white paper demonstrates the use of scanners to iterate over
rows and columns.
http://static.googleusercontent.com/media/research.google.com/en/us/archive/bigtable-osdi06.pdf
Because Cassandra does not have a primary sorting on row keys scanning over
ranges of row keys is less useful.
However we can use the scanner concept to operate on wide rows. For example
many times a user wishes to do some custom processing inside a row and does
not wish to carry the data across the network to do this processing.
I have already implemented thrift methods to compile dynamic groovy code into
Filters as well as some code that uses a Filter to page through and process
data on the server side.
https://github.com/edwardcapriolo/cassandra/compare/apache:trunk...trunk
The following is a working code snippet.
{code}
@Test
public void test_scanner() throws Exception
{
ColumnParent cp = new ColumnParent();
cp.setColumn_family(Standard1);
ByteBuffer key = ByteBuffer.wrap(rscannerkey.getBytes());
for (char a='a'; a 'g'; a++){
Column c1 = new Column();
c1.setName((a+).getBytes());
c1.setValue(new byte [0]);
c1.setTimestamp(System.nanoTime());
server.insert(key, cp, c1, ConsistencyLevel.ONE);
}
FilterDesc d = new FilterDesc();
d.setSpec(GROOVY_CLASS_LOADER);
d.setName(limit3);
d.setCode(import org.apache.cassandra.dht.* \n +
import org.apache.cassandra.thrift.* \n +
public class Limit3 implements SFilter { \n +
public FilterReturn filter(ColumnOrSuperColumn col,
ListColumnOrSuperColumn filtered) {\n+
filtered.add(col);\n+
return filtered.size() 3 ? FilterReturn.FILTER_MORE :
FilterReturn.FILTER_DONE;\n+
} \n +
}\n);
server.create_filter(d);
ScannerResult res = server.create_scanner(Standard1, limit3, key,
ByteBuffer.wrap(a.getBytes()));
Assert.assertEquals(3, res.results.size());
}
{code}
I am going to be working on this code over the next few weeks but I wanted to
get the concept our early so the design can see some criticism.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (CASSANDRA-6705) ALTER TYPE type RENAME field fails sometime with java.lang.AssertionError: null
Mikhail Stepura created CASSANDRA-6705:
--
Summary: ALTER TYPE type RENAME field fails sometime with
java.lang.AssertionError: null
Key: CASSANDRA-6705
URL: https://issues.apache.org/jira/browse/CASSANDRA-6705
Project: Cassandra
Issue Type: Bug
Environment: trunk
Reporter: Mikhail Stepura
Priority: Minor
Fix For: 2.1
Here are the steps w
{code}
cqlsh create KEYSPACE bug WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 1};
cqlsh
cqlsh
cqlsh use bug;
cqlsh:bug create type first_type (first_field int);
cqlsh:bug create type second_type (second_field listfirst_type );
cqlsh:bug alter type first_type RENAME first_field TO first_fieldd;
TSocket read 0 bytes
{code}
And here is from the C* side:
{code}
NFO 05:11:54 Loading
org.apache.cassandra.db.marshal.UserType(bug,7365636f6e645f74797065,7365636f6e645f6669656c64:org.apache.cassandra.db.marshal.ListType(org.apache.cassandra.db.marshal.UserType(bug,66697273745f74797065,66697273745f6669656c6464:org.apache.cassandra.db.marshal.Int32Type)))
INFO 05:11:54 Compacted 4 sstables to
[/var/lib/cassandra/data/system/schema_usertypes-3aa752254f82350b8d5c430fa221fa0a/system-schema_usertypes-ka-5,].
908 bytes to 425 (~46% of original) in 12ms = 0.033776MB/s. 4 total
partitions merged to 1. Partition merge counts were {4:1, }
ERROR 05:11:54 Exception in thread Thread[MigrationStage:1,5,main]
java.lang.AssertionError: null
at org.apache.cassandra.config.UTMetaData.addType(UTMetaData.java:145)
~[main/:na]
at org.apache.cassandra.db.DefsTables.addType(DefsTables.java:412)
~[main/:na]
at org.apache.cassandra.db.DefsTables.mergeTypes(DefsTables.java:365)
~[main/:na]
at org.apache.cassandra.db.DefsTables.mergeSchema(DefsTables.java:182)
~[main/:na]
at
org.apache.cassandra.service.MigrationManager$2.runMayThrow(MigrationManager.java:299)
~[main/:na]
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
~[main/:na]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
~[na:1.7.0_51]
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
~[na:1.7.0_51]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
~[na:1.7.0_51]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[na:1.7.0_51]
at java.lang.Thread.run(Thread.java:744) [na:1.7.0_51]
ERROR 05:11:54 Error occurred during processing of message.
java.lang.RuntimeException: java.util.concurrent.ExecutionException:
java.lang.AssertionError
at
org.apache.cassandra.utils.FBUtilities.waitOnFuture(FBUtilities.java:411)
~[main/:na]
at
org.apache.cassandra.service.MigrationManager.announce(MigrationManager.java:281)
~[main/:na]
at
org.apache.cassandra.service.MigrationManager.announceNewType(MigrationManager.java:216)
~[main/:na]
at
org.apache.cassandra.service.MigrationManager.announceTypeUpdate(MigrationManager.java:247)
~[main/:na]
at
org.apache.cassandra.cql3.statements.AlterTypeStatement.announceMigration(AlterTypeStatement.java:139)
~[main/:na]
at
org.apache.cassandra.cql3.statements.SchemaAlteringStatement.execute(SchemaAlteringStatement.java:71)
~[main/:na]
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:180)
~[main/:na]
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:214)
~[main/:na]
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:204)
~[main/:na]
at
org.apache.cassandra.thrift.CassandraServer.execute_cql3_query(CassandraServer.java:1973)
~[main/:na]
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(Cassandra.java:4486)
~[thrift/:na]
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(Cassandra.java:4470)
~[thrift/:na]
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
~[libthrift-0.9.1.jar:0.9.1]
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
~[libthrift-0.9.1.jar:0.9.1]
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:194)
~[main/:na]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[na:1.7.0_51]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[na:1.7.0_51]
at java.lang.Thread.run(Thread.java:744) [na:1.7.0_51]
Caused by: java.util.concurrent.ExecutionException: java.lang.AssertionError
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
~[na:1.7.0_51]
at java.util.concurrent.FutureTask.get(FutureTask.java:188)
~[na:1.7.0_51]
at
[jira] [Commented] (CASSANDRA-6702) Upgrading node uses the wrong port in gossiping
[ https://issues.apache.org/jira/browse/CASSANDRA-6702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13901129#comment-13901129 ] Jeremiah Jordan commented on CASSANDRA-6702: [~jasobrown] is this expected? you mention that scenario here https://issues.apache.org/jira/browse/CASSANDRA-5669?focusedCommentId=13703209page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13703209 (publicIP on non-SSL port) Upgrading node uses the wrong port in gossiping --- Key: CASSANDRA-6702 URL: https://issues.apache.org/jira/browse/CASSANDRA-6702 Project: Cassandra Issue Type: Bug Components: Core Environment: 1.1.7, AWS, Ec2MultiRegionSnitch Reporter: Minh Do Priority: Minor Fix For: 1.2.16 When upgrading a node in 1.1.7 (or 1.1.11) cluster to 1.2.15 and inspecting the gossip information on port/Ip, I could see that the upgrading node (1.2 version) communicates to one other node in the same region using Public IP and non-encrypted port. For the rest, the upgrading node uses the correct ports and IPs to communicate in this manner: Same region: private IP and non-encrypted port and Different region: public IP and encrypted port Because there is one node like this (or probably 2 max), we have to modify Security Group to allow the new traffics. Without modifying the SG, the 95th and 99th latencies for both reads and writes in the cluster are very bad (due to RPC timeout). Inspecting closer, that upgraded node (1.2 node) is contributing to all of the high latencies whenever it acts as a coordinator node. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6703) cqlsh support for static CQL3 columns
[ https://issues.apache.org/jira/browse/CASSANDRA-6703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Stepura updated CASSANDRA-6703: --- Issue Type: New Feature (was: Sub-task) Parent: (was: CASSANDRA-6561) cqlsh support for static CQL3 columns --- Key: CASSANDRA-6703 URL: https://issues.apache.org/jira/browse/CASSANDRA-6703 Project: Cassandra Issue Type: New Feature Reporter: Mikhail Stepura Assignee: Mikhail Stepura Labels: cqlsh Fix For: 2.0.6 * Show static columns in DESCRIBE * CREATE/ALTER TABLE autocompletions -- This message was sent by Atlassian JIRA (v6.1.5#6160)
