[jira] [Created] (CASSANDRA-4575) configurable snapshot directory
Zenek Kraweznik created CASSANDRA-4575: -- Summary: configurable snapshot directory Key: CASSANDRA-4575 URL: https://issues.apache.org/jira/browse/CASSANDRA-4575 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Zenek Kraweznik It would be very usefull to create snapshot into ex. /var/lib/cassandra/snapshots. Filestructure could be the same as is in /var/lib/cassandra/data This will help with remobe backups via rsync, tivoli etc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4567) Error in log related to Murmur3Partitioner
[
https://issues.apache.org/jira/browse/CASSANDRA-4567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13440978#comment-13440978
]
Vijay commented on CASSANDRA-4567:
--
Not sure if i understand it right.
Do you want to remove the check for partitioner? We should always check because
the distributions are different between OPP vs RP even M3P (Will cause data
loss), right?
> Error in log related to Murmur3Partitioner
> --
>
> Key: CASSANDRA-4567
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4567
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.2.0
> Environment: Using ccm on ubuntu
>Reporter: Tyler Patterson
>Assignee: Pavel Yaskevich
> Fix For: 1.2.0
>
>
> Start a 2-node cluster on cassandra-1.1. Bring down one node, upgrade it to
> trunk, start it back up. The following error shows up in the log:
> {code}
> ...
> INFO [main] 2012-08-22 10:44:40,012 CacheService.java (line 170) Scheduling
> row cache save to each 0 seconds (going to save all keys).
> INFO [SSTableBatchOpen:1] 2012-08-22 10:44:40,106 SSTableReader.java (line
> 164) Opening
> /tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-2
> (148 bytes)
> INFO [SSTableBatchOpen:2] 2012-08-22 10:44:40,106 SSTableReader.java (line
> 164) Opening
> /tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-1
> (226 bytes)
> INFO [SSTableBatchOpen:3] 2012-08-22 10:44:40,106 SSTableReader.java (line
> 164) Opening
> /tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-3
> (89 bytes)
> ERROR [SSTableBatchOpen:3] 2012-08-22 10:44:40,114 CassandraDaemon.java (line
> 131) Exception in thread Thread[SSTableBatchOpen:3,5,main]
> java.lang.RuntimeException: Cannot open
> /tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-3
> because partitioner does not match
> org.apache.cassandra.dht.Murmur3Partitioner
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:175)
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:149)
> at
> org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:236)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> ERROR [SSTableBatchOpen:2] 2012-08-22 10:44:40,114 CassandraDaemon.java (line
> 131) Exception in thread Thread[SSTableBatchOpen:2,5,main]
> java.lang.RuntimeException: Cannot open
> /tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-1
> because partitioner does not match
> org.apache.cassandra.dht.Murmur3Partitioner
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:175)
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:149)
> at
> org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:236)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> ERROR [SSTableBatchOpen:1] 2012-08-22 10:44:40,114 CassandraDaemon.java (line
> 131) Exception in thread Thread[SSTableBatchOpen:1,5,main]
> java.lang.RuntimeException: Cannot open
> /tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-2
> because partitioner does not match
> org.apache.cassandra.dht.Murmur3Partitioner
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:175)
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:149)
> at
> org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:236)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecuto
[jira] [Commented] (CASSANDRA-4573) HSHA doesn't handle large messages gracefully
[
https://issues.apache.org/jira/browse/CASSANDRA-4573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13440941#comment-13440941
]
Vijay commented on CASSANDRA-4573:
--
but Frame size is set for both HSHA and Sync
{code}
TNonblockingServer.Args serverArgs = new
TNonblockingServer.Args(serverTransport).inputTransportFactory(inTransportFactory)
.outputTransportFactory(outTransportFactory)
{code}
> HSHA doesn't handle large messages gracefully
> -
>
> Key: CASSANDRA-4573
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4573
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Tyler Hobbs
>Assignee: Vijay
> Attachments: repro.py
>
>
> HSHA doesn't seem to enforce any kind of max message length, and when
> messages are too large, it doesn't fail gracefully.
> With debug logs enabled, you'll see this:
> {{DEBUG 13:13:31,805 Unexpected state 16}}
> Which seems to mean that there's a SelectionKey that's valid, but isn't ready
> for reading, writing, or accepting.
> Client-side, you'll get this thrift error (while trying to read a frame as
> part of {{recv_batch_mutate}}):
> {{TTransportException: TSocket read 0 bytes}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4540) nodetool clearsnapshot broken: gives java.io.IOException when trying to delete snapshot folder
[ https://issues.apache.org/jira/browse/CASSANDRA-4540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13440932#comment-13440932 ] Dave Brosius commented on CASSANDRA-4540: - seems to work in the standard case here (mint). Do you have a huge number of snapshot directories? > nodetool clearsnapshot broken: gives java.io.IOException when trying to > delete snapshot folder > -- > > Key: CASSANDRA-4540 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4540 > Project: Cassandra > Issue Type: Bug > Components: Tools >Affects Versions: 1.1.2 > Environment: Debian 6 >Reporter: Christopher Lörken >Priority: Trivial > Labels: lhf > Fix For: 1.1.5 > > > nodetool clearsnapshots failes to delete snapshot directories and exits > prematurely causing the exception at the bottom. > The actual snapshot files _within_ the directory are correctly deleted but > the folder itself is not deleted. > I've chmodded all files and folders in the snapshots directory to 777 and > rund the command as root to exclude file permissions as a cause. I also > restarted cassandra which has no effect on the command. > --- > root@server:/var/lib/cassandra/data/MyKeyspace/MyCf/snapshots# nodetool > clearsnapshot MyKeyspace > Requested snapshot for: MyKeyspace > Exception in thread "main" java.io.IOException: Failed to delete > /var/lib/cassandra/data/MyKeyspace/MyCf/snapshots/1344875270796 > at > org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:54) > at > org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:220) > at > org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:216) > at > org.apache.cassandra.db.Directories.clearSnapshot(Directories.java:371) > at > org.apache.cassandra.db.ColumnFamilyStore.clearSnapshot(ColumnFamilyStore.java:1560) > at org.apache.cassandra.db.Table.clearSnapshot(Table.java:268) > at > org.apache.cassandra.service.StorageService.clearSnapshot(StorageService.java:1866) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(Unknown > Source) > at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(Unknown > Source) > at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(Unknown Source) > at com.sun.jmx.mbeanserver.PerInterface.invoke(Unknown Source) > at com.sun.jmx.mbeanserver.MBeanSupport.invoke(Unknown Source) > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(Unknown Source) > at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(Unknown Source) > at javax.management.remote.rmi.RMIConnectionImpl.doOperation(Unknown > Source) > at javax.management.remote.rmi.RMIConnectionImpl.access$200(Unknown > Source) > at > javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(Unknown > Source) > at > javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(Unknown > Source) > at javax.management.remote.rmi.RMIConnectionImpl.invoke(Unknown > Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source) > at sun.rmi.transport.Transport$1.run(Unknown Source) > at sun.rmi.transport.Transport$1.run(Unknown Source) > at java.security.AccessController.doPrivileged(Native Method) > at sun.rmi.transport.Transport.serviceCall(Unknown Source) > at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source) > at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown > Source) > at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown > Source) > at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) > at java.lang.Thread.run(Unknown Source) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on
git commit: merge from 1.1
Updated Branches:
refs/heads/trunk a89ef1ffd -> 58c5533e9
merge from 1.1
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/58c5533e
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/58c5533e
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/58c5533e
Branch: refs/heads/trunk
Commit: 58c5533e956cab461a4122e63212cee1f8275713
Parents: a89ef1f
Author: Dave Brosius
Authored: Fri Aug 24 00:09:25 2012 -0400
Committer: Dave Brosius
Committed: Fri Aug 24 00:09:25 2012 -0400
--
.../cassandra/service/AntiEntropyService.java |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/58c5533e/src/java/org/apache/cassandra/service/AntiEntropyService.java
--
diff --git a/src/java/org/apache/cassandra/service/AntiEntropyService.java
b/src/java/org/apache/cassandra/service/AntiEntropyService.java
index b26574e..474566e 100644
--- a/src/java/org/apache/cassandra/service/AntiEntropyService.java
+++ b/src/java/org/apache/cassandra/service/AntiEntropyService.java
@@ -622,7 +622,7 @@ public class AntiEntropyService
if (endpoints.isEmpty())
{
differencingDone.signalAll();
-logger.info("[repair #%s] No neighbors to repair with on range
%s: session completed", getName(), range);
+logger.info(String.format("[repair #%s] No neighbors to repair
with on range %s: session completed", getName(), range));
return;
}
[2/2] git commit: Add missing String.format call to log string contents patch by Julien Lambert reviewed by dbrosius for CASSANDRA-4574
Add missing String.format call to log string contents
patch by Julien Lambert reviewed by dbrosius for CASSANDRA-4574
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ec76baf0
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ec76baf0
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ec76baf0
Branch: refs/heads/cassandra-1.1
Commit: ec76baf0dd2a976542106cd5e58652c3d36ffd23
Parents: 197511f
Author: Dave Brosius
Authored: Thu Aug 23 23:51:41 2012 -0400
Committer: Dave Brosius
Committed: Thu Aug 23 23:51:41 2012 -0400
--
.../cassandra/service/AntiEntropyService.java | 22 +++---
1 files changed, 11 insertions(+), 11 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/ec76baf0/src/java/org/apache/cassandra/service/AntiEntropyService.java
--
diff --git a/src/java/org/apache/cassandra/service/AntiEntropyService.java
b/src/java/org/apache/cassandra/service/AntiEntropyService.java
index 0ded3cd..7bdeb20 100644
--- a/src/java/org/apache/cassandra/service/AntiEntropyService.java
+++ b/src/java/org/apache/cassandra/service/AntiEntropyService.java
@@ -259,7 +259,7 @@ public class AntiEntropyService
private transient DecoratedKey lastKey;
public final static MerkleTree.RowHash EMPTY_ROW = new
MerkleTree.RowHash(null, new byte[0]);
-
+
Validator(TreeRequest request)
{
this(request,
@@ -451,9 +451,9 @@ public class AntiEntropyService
* Trigger a validation compaction which will return the tree upon
completion.
*/
public void doVerb(Message message, String id)
-{
+{
byte[] bytes = message.getMessageBody();
-
+
DataInputStream buffer = new DataInputStream(new
FastByteArrayInputStream(bytes));
try
{
@@ -468,7 +468,7 @@ public class AntiEntropyService
}
catch (IOException e)
{
-throw new IOError(e);
+throw new IOError(e);
}
}
}
@@ -487,9 +487,9 @@ public class AntiEntropyService
FastByteArrayOutputStream bos = new FastByteArrayOutputStream();
DataOutputStream dos = new DataOutputStream(bos);
SERIALIZER.serialize(validator, dos,
Gossiper.instance.getVersion(validator.request.endpoint));
-return new Message(local,
- StorageService.Verb.TREE_RESPONSE,
- bos.toByteArray(),
+return new Message(local,
+ StorageService.Verb.TREE_RESPONSE,
+ bos.toByteArray(),
Gossiper.instance.getVersion(validator.request.endpoint));
}
catch(IOException e)
@@ -519,7 +519,7 @@ public class AntiEntropyService
}
public void doVerb(Message message, String id)
-{
+{
byte[] bytes = message.getMessageBody();
DataInputStream buffer = new DataInputStream(new
FastByteArrayInputStream(bytes));
@@ -572,7 +572,7 @@ public class AntiEntropyService
{
return Objects.hashCode(sessionid, endpoint, cf, range);
}
-
+
@Override
public final boolean equals(Object o)
{
@@ -582,7 +582,7 @@ public class AntiEntropyService
// handles nulls properly
return Objects.equal(sessionid, that.sessionid) &&
Objects.equal(endpoint, that.endpoint) && Objects.equal(cf, that.cf) &&
Objects.equal(range, that.range);
}
-
+
@Override
public String toString()
{
@@ -660,7 +660,7 @@ public class AntiEntropyService
if (endpoints.isEmpty())
{
differencingDone.signalAll();
-logger.info("[repair #%s] No neighbors to repair with on range
%s: session completed", getName(), range);
+logger.info(String.format("[repair #%s] No neighbors to repair
with on range %s: session completed", getName(), range));
return;
}
[1/2] git commit: merge from 1.0
Updated Branches:
refs/heads/cassandra-1.1 dbf99d674 -> fa8fc22fc
merge from 1.0
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/fa8fc22f
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/fa8fc22f
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/fa8fc22f
Branch: refs/heads/cassandra-1.1
Commit: fa8fc22fca240e1f016bbfd5ff9c54b57c0bb777
Parents: dbf99d6 ec76baf
Author: Dave Brosius
Authored: Fri Aug 24 00:00:59 2012 -0400
Committer: Dave Brosius
Committed: Fri Aug 24 00:00:59 2012 -0400
--
.../cassandra/service/AntiEntropyService.java |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/fa8fc22f/src/java/org/apache/cassandra/service/AntiEntropyService.java
--
diff --cc src/java/org/apache/cassandra/service/AntiEntropyService.java
index d76d26f,7bdeb20..0d7c1b4
--- a/src/java/org/apache/cassandra/service/AntiEntropyService.java
+++ b/src/java/org/apache/cassandra/service/AntiEntropyService.java
@@@ -418,7 -412,7 +418,7 @@@ public class AntiEntropyServic
{
try
{
-- FastByteArrayOutputStream bos = new FastByteArrayOutputStream();
++FastByteArrayOutputStream bos = new
FastByteArrayOutputStream();
DataOutputStream dos = new DataOutputStream(bos);
SERIALIZER.serialize(request, dos, version);
return new Message(FBUtilities.getBroadcastAddress(),
StorageService.Verb.TREE_REQUEST, bos.toByteArray(), version);
@@@ -490,7 -484,7 +490,7 @@@
{
try
{
-- FastByteArrayOutputStream bos = new FastByteArrayOutputStream();
++FastByteArrayOutputStream bos = new
FastByteArrayOutputStream();
DataOutputStream dos = new DataOutputStream(bos);
SERIALIZER.serialize(validator, dos,
Gossiper.instance.getVersion(validator.request.endpoint));
return new Message(local,
[jira] [Commented] (CASSANDRA-4574) Missing String.format() in AntiEntropyService.java logs
[ https://issues.apache.org/jira/browse/CASSANDRA-4574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13440923#comment-13440923 ] Dave Brosius commented on CASSANDRA-4574: - thanks committed to cassandra-1.0 as ec76baf0dd2a976542106cd5e58652c3d36ffd23 > Missing String.format() in AntiEntropyService.java logs > --- > > Key: CASSANDRA-4574 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4574 > Project: Cassandra > Issue Type: Bug >Affects Versions: 1.0.8, 1.1.3, 1.2.0 >Reporter: Julien Lambert >Priority: Minor > > A String.format() is missing in AntiEntropyService.java (line 625 in 1.2). > This is what is written to the logs: AntiEntropyService.java (line 625) > \[repair #%s] No neighbors to repair with on range %s: session completed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-4574) Missing String.format() in AntiEntropyService.java logs
[ https://issues.apache.org/jira/browse/CASSANDRA-4574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Brosius resolved CASSANDRA-4574. - Resolution: Fixed Assignee: Dave Brosius > Missing String.format() in AntiEntropyService.java logs > --- > > Key: CASSANDRA-4574 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4574 > Project: Cassandra > Issue Type: Bug >Affects Versions: 1.0.8, 1.1.3, 1.2.0 >Reporter: Julien Lambert >Assignee: Dave Brosius >Priority: Minor > > A String.format() is missing in AntiEntropyService.java (line 625 in 1.2). > This is what is written to the logs: AntiEntropyService.java (line 625) > \[repair #%s] No neighbors to repair with on range %s: session completed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: Add missing String.format call to log string contents patch by Julien Lambert reviewed by dbrosius for CASSANDRA-4574
Updated Branches:
refs/heads/cassandra-1.0 197511f0b -> ec76baf0d
Add missing String.format call to log string contents
patch by Julien Lambert reviewed by dbrosius for CASSANDRA-4574
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ec76baf0
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ec76baf0
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ec76baf0
Branch: refs/heads/cassandra-1.0
Commit: ec76baf0dd2a976542106cd5e58652c3d36ffd23
Parents: 197511f
Author: Dave Brosius
Authored: Thu Aug 23 23:51:41 2012 -0400
Committer: Dave Brosius
Committed: Thu Aug 23 23:51:41 2012 -0400
--
.../cassandra/service/AntiEntropyService.java | 22 +++---
1 files changed, 11 insertions(+), 11 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/ec76baf0/src/java/org/apache/cassandra/service/AntiEntropyService.java
--
diff --git a/src/java/org/apache/cassandra/service/AntiEntropyService.java
b/src/java/org/apache/cassandra/service/AntiEntropyService.java
index 0ded3cd..7bdeb20 100644
--- a/src/java/org/apache/cassandra/service/AntiEntropyService.java
+++ b/src/java/org/apache/cassandra/service/AntiEntropyService.java
@@ -259,7 +259,7 @@ public class AntiEntropyService
private transient DecoratedKey lastKey;
public final static MerkleTree.RowHash EMPTY_ROW = new
MerkleTree.RowHash(null, new byte[0]);
-
+
Validator(TreeRequest request)
{
this(request,
@@ -451,9 +451,9 @@ public class AntiEntropyService
* Trigger a validation compaction which will return the tree upon
completion.
*/
public void doVerb(Message message, String id)
-{
+{
byte[] bytes = message.getMessageBody();
-
+
DataInputStream buffer = new DataInputStream(new
FastByteArrayInputStream(bytes));
try
{
@@ -468,7 +468,7 @@ public class AntiEntropyService
}
catch (IOException e)
{
-throw new IOError(e);
+throw new IOError(e);
}
}
}
@@ -487,9 +487,9 @@ public class AntiEntropyService
FastByteArrayOutputStream bos = new FastByteArrayOutputStream();
DataOutputStream dos = new DataOutputStream(bos);
SERIALIZER.serialize(validator, dos,
Gossiper.instance.getVersion(validator.request.endpoint));
-return new Message(local,
- StorageService.Verb.TREE_RESPONSE,
- bos.toByteArray(),
+return new Message(local,
+ StorageService.Verb.TREE_RESPONSE,
+ bos.toByteArray(),
Gossiper.instance.getVersion(validator.request.endpoint));
}
catch(IOException e)
@@ -519,7 +519,7 @@ public class AntiEntropyService
}
public void doVerb(Message message, String id)
-{
+{
byte[] bytes = message.getMessageBody();
DataInputStream buffer = new DataInputStream(new
FastByteArrayInputStream(bytes));
@@ -572,7 +572,7 @@ public class AntiEntropyService
{
return Objects.hashCode(sessionid, endpoint, cf, range);
}
-
+
@Override
public final boolean equals(Object o)
{
@@ -582,7 +582,7 @@ public class AntiEntropyService
// handles nulls properly
return Objects.equal(sessionid, that.sessionid) &&
Objects.equal(endpoint, that.endpoint) && Objects.equal(cf, that.cf) &&
Objects.equal(range, that.range);
}
-
+
@Override
public String toString()
{
@@ -660,7 +660,7 @@ public class AntiEntropyService
if (endpoints.isEmpty())
{
differencingDone.signalAll();
-logger.info("[repair #%s] No neighbors to repair with on range
%s: session completed", getName(), range);
+logger.info(String.format("[repair #%s] No neighbors to repair
with on range %s: session completed", getName(), range));
return;
}
[jira] [Commented] (CASSANDRA-4573) HSHA doesn't handle large messages gracefully
[
https://issues.apache.org/jira/browse/CASSANDRA-4573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13440908#comment-13440908
]
Jonathan Ellis commented on CASSANDRA-4573:
---
bq. neither does sync
sync does enforce frame size
> HSHA doesn't handle large messages gracefully
> -
>
> Key: CASSANDRA-4573
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4573
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Tyler Hobbs
>Assignee: Vijay
> Attachments: repro.py
>
>
> HSHA doesn't seem to enforce any kind of max message length, and when
> messages are too large, it doesn't fail gracefully.
> With debug logs enabled, you'll see this:
> {{DEBUG 13:13:31,805 Unexpected state 16}}
> Which seems to mean that there's a SelectionKey that's valid, but isn't ready
> for reading, writing, or accepting.
> Client-side, you'll get this thrift error (while trying to read a frame as
> part of {{recv_batch_mutate}}):
> {{TTransportException: TSocket read 0 bytes}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4567) Error in log related to Murmur3Partitioner
[
https://issues.apache.org/jira/browse/CASSANDRA-4567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13440907#comment-13440907
]
Jonathan Ellis commented on CASSANDRA-4567:
---
Should we just ignore the partitioner after first startup, the way we do with
initial_token?
> Error in log related to Murmur3Partitioner
> --
>
> Key: CASSANDRA-4567
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4567
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.2.0
> Environment: Using ccm on ubuntu
>Reporter: Tyler Patterson
>Assignee: Pavel Yaskevich
> Fix For: 1.2.0
>
>
> Start a 2-node cluster on cassandra-1.1. Bring down one node, upgrade it to
> trunk, start it back up. The following error shows up in the log:
> {code}
> ...
> INFO [main] 2012-08-22 10:44:40,012 CacheService.java (line 170) Scheduling
> row cache save to each 0 seconds (going to save all keys).
> INFO [SSTableBatchOpen:1] 2012-08-22 10:44:40,106 SSTableReader.java (line
> 164) Opening
> /tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-2
> (148 bytes)
> INFO [SSTableBatchOpen:2] 2012-08-22 10:44:40,106 SSTableReader.java (line
> 164) Opening
> /tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-1
> (226 bytes)
> INFO [SSTableBatchOpen:3] 2012-08-22 10:44:40,106 SSTableReader.java (line
> 164) Opening
> /tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-3
> (89 bytes)
> ERROR [SSTableBatchOpen:3] 2012-08-22 10:44:40,114 CassandraDaemon.java (line
> 131) Exception in thread Thread[SSTableBatchOpen:3,5,main]
> java.lang.RuntimeException: Cannot open
> /tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-3
> because partitioner does not match
> org.apache.cassandra.dht.Murmur3Partitioner
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:175)
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:149)
> at
> org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:236)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> ERROR [SSTableBatchOpen:2] 2012-08-22 10:44:40,114 CassandraDaemon.java (line
> 131) Exception in thread Thread[SSTableBatchOpen:2,5,main]
> java.lang.RuntimeException: Cannot open
> /tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-1
> because partitioner does not match
> org.apache.cassandra.dht.Murmur3Partitioner
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:175)
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:149)
> at
> org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:236)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> ERROR [SSTableBatchOpen:1] 2012-08-22 10:44:40,114 CassandraDaemon.java (line
> 131) Exception in thread Thread[SSTableBatchOpen:1,5,main]
> java.lang.RuntimeException: Cannot open
> /tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-2
> because partitioner does not match
> org.apache.cassandra.dht.Murmur3Partitioner
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:175)
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:149)
> at
> org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:236)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
[jira] [Commented] (CASSANDRA-4573) HSHA doesn't handle large messages gracefully
[
https://issues.apache.org/jira/browse/CASSANDRA-4573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13440837#comment-13440837
]
Vijay commented on CASSANDRA-4573:
--
{quote}
With debug logs enabled, you'll see this:
DEBUG 13:13:31,805 Unexpected state 16
{quote}
Unexpected state 16 means the intrest operation is accept.
If you look at the code it is a while loop (the intrestOps can change between
the if conditions) and will be handled in the next iteration.
{quote}
HSHA doesn't seem to enforce any kind of max message length
{quote}
neither does sync :) i can reproduce this error both in Sync and hsha, still
trying to see where the timeout comes from though.
> HSHA doesn't handle large messages gracefully
> -
>
> Key: CASSANDRA-4573
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4573
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Tyler Hobbs
>Assignee: Vijay
> Attachments: repro.py
>
>
> HSHA doesn't seem to enforce any kind of max message length, and when
> messages are too large, it doesn't fail gracefully.
> With debug logs enabled, you'll see this:
> {{DEBUG 13:13:31,805 Unexpected state 16}}
> Which seems to mean that there's a SelectionKey that's valid, but isn't ready
> for reading, writing, or accepting.
> Client-side, you'll get this thrift error (while trying to read a frame as
> part of {{recv_batch_mutate}}):
> {{TTransportException: TSocket read 0 bytes}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4561) update column family fails
[
https://issues.apache.org/jira/browse/CASSANDRA-4561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13440776#comment-13440776
]
Arya Goudarzi commented on CASSANDRA-4561:
--
+1 I just ended up seeing this problem in our cluster which was upgraded from
1.1.2 to 1.1.3. Will probably have to find a workaround since I have to change
schema now.
> update column family fails
> --
>
> Key: CASSANDRA-4561
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4561
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.1.0, 1.1.1, 1.1.2, 1.1.3, 1.1.4
>Reporter: Zenek Kraweznik
>Assignee: Pavel Yaskevich
>
> [default@test] show schema;
> create column family Messages
> with column_type = 'Standard'
> and comparator = 'AsciiType'
> and default_validation_class = 'BytesType'
> and key_validation_class = 'AsciiType'
> and read_repair_chance = 0.1
> and dclocal_read_repair_chance = 0.0
> and gc_grace = 864000
> and min_compaction_threshold = 2
> and max_compaction_threshold = 4
> and replicate_on_write = true
> and compaction_strategy =
> 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
> and caching = 'KEYS_ONLY'
> and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
> and compression_options = {'chunk_length_kb' : '64', 'sstable_compression'
> : 'org.apache.cassandra.io.compress.DeflateCompressor'};
> [default@test] update column family Messages with min_compaction_threshold =
> 4 and max_compaction_threshold = 32;
> a5b7544e-1ef5-3bfd-8770-c09594e37ec2
> Waiting for schema agreement...
> ... schemas agree across the cluster
> [default@test] show schema;
> create column family Messages
> with column_type = 'Standard'
> and comparator = 'AsciiType'
> and default_validation_class = 'BytesType'
> and key_validation_class = 'AsciiType'
> and read_repair_chance = 0.1
> and dclocal_read_repair_chance = 0.0
> and gc_grace = 864000
> and min_compaction_threshold = 2
> and max_compaction_threshold = 4
> and replicate_on_write = true
> and compaction_strategy =
> 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
> and caching = 'KEYS_ONLY'
> and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
> and compression_options = {'chunk_length_kb' : '64', 'sstable_compression'
> : 'org.apache.cassandra.io.compress.DeflateCompressor'};
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2118) Provide failure modes if issues with the underlying filesystem of a node
[ https://issues.apache.org/jira/browse/CASSANDRA-2118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13440770#comment-13440770 ] Aleksey Yeschenko commented on CASSANDRA-2118: -- Removing unreadable sstables in DataTracker.get[Uncompacting]SSTables is not enough because many methods use view.sstables directly, so I had to rip the affected sstables from view.sstables. When reviewing v2 please look very carefully at DataTracker#maybeRemoveUnreadableSSTables method. > Provide failure modes if issues with the underlying filesystem of a node > > > Key: CASSANDRA-2118 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2118 > Project: Cassandra > Issue Type: Sub-task > Components: Core >Reporter: Chris Goffinet >Assignee: Aleksey Yeschenko > Fix For: 1.2.0 > > Attachments: > 0001-Provide-failure-modes-if-issues-with-the-underlying-.patch, > 0001-Provide-failure-modes-if-issues-with-the-underlying-v2.patch, > 0001-Provide-failure-modes-if-issues-with-the-underlying-v3.patch, > 2118-tweaked.txt, CASSANDRA-2118-part1.patch, CASSANDRA-2118-v1.patch, > CASSANDRA-2118-v2.patch > > > CASSANDRA-2116 introduces the ability to detect FS errors. Let's provide a > mode in cassandra.yaml so operators can decide that in the event of failure > what to do: > 1) standard - means continue on all errors (default) > 2) read - means only stop gossip/rpc server if 'reads' fail from drive, > writes can fail but not kill gossip/rpc server > 3) readwrite - means stop gossip/rpc server if any read or write errors. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2118) Provide failure modes if issues with the underlying filesystem of a node
[ https://issues.apache.org/jira/browse/CASSANDRA-2118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-2118: - Attachment: CASSANDRA-2118-v2.patch > Provide failure modes if issues with the underlying filesystem of a node > > > Key: CASSANDRA-2118 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2118 > Project: Cassandra > Issue Type: Sub-task > Components: Core >Reporter: Chris Goffinet >Assignee: Aleksey Yeschenko > Fix For: 1.2.0 > > Attachments: > 0001-Provide-failure-modes-if-issues-with-the-underlying-.patch, > 0001-Provide-failure-modes-if-issues-with-the-underlying-v2.patch, > 0001-Provide-failure-modes-if-issues-with-the-underlying-v3.patch, > 2118-tweaked.txt, CASSANDRA-2118-part1.patch, CASSANDRA-2118-v1.patch, > CASSANDRA-2118-v2.patch > > > CASSANDRA-2116 introduces the ability to detect FS errors. Let's provide a > mode in cassandra.yaml so operators can decide that in the event of failure > what to do: > 1) standard - means continue on all errors (default) > 2) read - means only stop gossip/rpc server if 'reads' fail from drive, > writes can fail but not kill gossip/rpc server > 3) readwrite - means stop gossip/rpc server if any read or write errors. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4574) Missing String.format() in AntiEntropyService.java logs
[ https://issues.apache.org/jira/browse/CASSANDRA-4574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julien Lambert updated CASSANDRA-4574: -- Description: A String.format() is missing in AntiEntropyService.java (line 625 in 1.2). This is what is written to the logs: AntiEntropyService.java (line 625) \[repair #%s] No neighbors to repair with on range %s: session completed. was: A String.format() is missing in AntiEntropyService.java (line 625). This is what is written to the logs: AntiEntropyService.java (line 625) \[repair #%s] No neighbors to repair with on range %s: session completed. Affects Version/s: 1.0.8 1.1.3 > Missing String.format() in AntiEntropyService.java logs > --- > > Key: CASSANDRA-4574 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4574 > Project: Cassandra > Issue Type: Bug >Affects Versions: 1.0.8, 1.1.3, 1.2.0 >Reporter: Julien Lambert >Priority: Minor > > A String.format() is missing in AntiEntropyService.java (line 625 in 1.2). > This is what is written to the logs: AntiEntropyService.java (line 625) > \[repair #%s] No neighbors to repair with on range %s: session completed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4574) Missing String.format() in AntiEntropyService.java logs
[ https://issues.apache.org/jira/browse/CASSANDRA-4574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julien Lambert updated CASSANDRA-4574: -- Description: A String.format() is missing in AntiEntropyService.java (line 625). This is what is written to the logs: AntiEntropyService.java (line 625) \[repair #%s] No neighbors to repair with on range %s: session completed. was: A String.format() is missing in AntiEntropyService.java (line 625). This is what is written to the logs: AntiEntropyService.java (line 625) [repair #%s] No neighbors to repair with on range %s: session completed. > Missing String.format() in AntiEntropyService.java logs > --- > > Key: CASSANDRA-4574 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4574 > Project: Cassandra > Issue Type: Bug >Affects Versions: 1.2.0 >Reporter: Julien Lambert >Priority: Minor > > A String.format() is missing in AntiEntropyService.java (line 625). > This is what is written to the logs: AntiEntropyService.java (line 625) > \[repair #%s] No neighbors to repair with on range %s: session completed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4574) Missing String.format() in AntiEntropyService.java logs
Julien Lambert created CASSANDRA-4574: - Summary: Missing String.format() in AntiEntropyService.java logs Key: CASSANDRA-4574 URL: https://issues.apache.org/jira/browse/CASSANDRA-4574 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.0 Reporter: Julien Lambert Priority: Minor A String.format() is missing in AntiEntropyService.java (line 625). This is what is written to the logs: AntiEntropyService.java (line 625) [repair #%s] No neighbors to repair with on range %s: session completed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4571) Strange permament socket descriptors increasing leads to "Too many open files"
[ https://issues.apache.org/jira/browse/CASSANDRA-4571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13440700#comment-13440700 ] Serg Shnerson commented on CASSANDRA-4571: -- Bug is not recreating with one node cluster > Strange permament socket descriptors increasing leads to "Too many open files" > -- > > Key: CASSANDRA-4571 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4571 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.1.2 > Environment: CentOS 5.8 Linux 2.6.18-308.13.1.el5 #1 SMP Tue Aug 21 > 17:10:18 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux. > java version "1.6.0_33" > Java(TM) SE Runtime Environment (build 1.6.0_33-b03) > Java HotSpot(TM) 64-Bit Server VM (build 20.8-b03, mixed mode) >Reporter: Serg Shnerson >Priority: Critical > > On the two-node cluster there was found strange socket descriptors > increasing. lsof -n | grep java shows many rows like" > java 8380 cassandra 113r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 114r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 115r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 116r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 117r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 118r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 119r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 120r unix 0x8101a374a080 > 938348482 socket > " And number of this rows constantly increasing. After about 24 hours this > situation leads to error. > We use PHPCassa client. Load is not so high (aroud ~50kb/s on write). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4567) Error in log related to Murmur3Partitioner
[
https://issues.apache.org/jira/browse/CASSANDRA-4567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-4567:
Summary: Error in log related to Murmur3Partitioner (was: Error in log
related to Murmer3Partitioner)
> Error in log related to Murmur3Partitioner
> --
>
> Key: CASSANDRA-4567
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4567
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.2.0
> Environment: Using ccm on ubuntu
>Reporter: Tyler Patterson
>Assignee: Pavel Yaskevich
> Fix For: 1.2.0
>
>
> Start a 2-node cluster on cassandra-1.1. Bring down one node, upgrade it to
> trunk, start it back up. The following error shows up in the log:
> {code}
> ...
> INFO [main] 2012-08-22 10:44:40,012 CacheService.java (line 170) Scheduling
> row cache save to each 0 seconds (going to save all keys).
> INFO [SSTableBatchOpen:1] 2012-08-22 10:44:40,106 SSTableReader.java (line
> 164) Opening
> /tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-2
> (148 bytes)
> INFO [SSTableBatchOpen:2] 2012-08-22 10:44:40,106 SSTableReader.java (line
> 164) Opening
> /tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-1
> (226 bytes)
> INFO [SSTableBatchOpen:3] 2012-08-22 10:44:40,106 SSTableReader.java (line
> 164) Opening
> /tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-3
> (89 bytes)
> ERROR [SSTableBatchOpen:3] 2012-08-22 10:44:40,114 CassandraDaemon.java (line
> 131) Exception in thread Thread[SSTableBatchOpen:3,5,main]
> java.lang.RuntimeException: Cannot open
> /tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-3
> because partitioner does not match
> org.apache.cassandra.dht.Murmur3Partitioner
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:175)
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:149)
> at
> org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:236)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> ERROR [SSTableBatchOpen:2] 2012-08-22 10:44:40,114 CassandraDaemon.java (line
> 131) Exception in thread Thread[SSTableBatchOpen:2,5,main]
> java.lang.RuntimeException: Cannot open
> /tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-1
> because partitioner does not match
> org.apache.cassandra.dht.Murmur3Partitioner
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:175)
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:149)
> at
> org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:236)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> ERROR [SSTableBatchOpen:1] 2012-08-22 10:44:40,114 CassandraDaemon.java (line
> 131) Exception in thread Thread[SSTableBatchOpen:1,5,main]
> java.lang.RuntimeException: Cannot open
> /tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-2
> because partitioner does not match
> org.apache.cassandra.dht.Murmur3Partitioner
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:175)
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:149)
> at
> org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:236)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread
[jira] [Commented] (CASSANDRA-4571) Strange permament socket descriptors increasing leads to "Too many open files"
[ https://issues.apache.org/jira/browse/CASSANDRA-4571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13440579#comment-13440579 ] Jeremy Hanna commented on CASSANDRA-4571: - Tobias: is it possible to get the test case and the server setup to try to reproduce? Heap dumps haven't proven very useful thus far. > Strange permament socket descriptors increasing leads to "Too many open files" > -- > > Key: CASSANDRA-4571 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4571 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.1.2 > Environment: CentOS 5.8 Linux 2.6.18-308.13.1.el5 #1 SMP Tue Aug 21 > 17:10:18 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux. > java version "1.6.0_33" > Java(TM) SE Runtime Environment (build 1.6.0_33-b03) > Java HotSpot(TM) 64-Bit Server VM (build 20.8-b03, mixed mode) >Reporter: Serg Shnerson >Priority: Critical > > On the two-node cluster there was found strange socket descriptors > increasing. lsof -n | grep java shows many rows like" > java 8380 cassandra 113r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 114r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 115r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 116r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 117r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 118r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 119r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 120r unix 0x8101a374a080 > 938348482 socket > " And number of this rows constantly increasing. After about 24 hours this > situation leads to error. > We use PHPCassa client. Load is not so high (aroud ~50kb/s on write). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4571) Strange permament socket descriptors increasing leads to "Too many open files"
[ https://issues.apache.org/jira/browse/CASSANDRA-4571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13440552#comment-13440552 ] Serg Shnerson commented on CASSANDRA-4571: -- It seems that bug is related to Java NIO internals (May be to Thrift framework). Please, read https://forums.oracle.com/forums/thread.jspa?threadID=1146235 for more details and give your thoughts about. >From topic: "I am submitting this post to highlight a possible NIO "gotcha" in >multithreaded applications and pose a couple of questions. We have observed >file descriptor resource leakage (eventually leading to server failure) in a >server process using NIO within the excellent framework written by Ronny >Standtke (http://nioframework.sourceforge.net). Platform is JDK1.6.0_05 on >RHEL4. I don't think that this is the same issue as that in connection with >TCP CLOSED sockets reported elsewhere - What leaks here are descriptors >connected to Unix domain sockets. In the framework, SelectableChannels registered in a selector are select()-ed in a single thread that handles data transfer to clients of the selector channels, executing in different threads. When a client shuts down its connection (invoking key.cancel() and key.channel.close()) eventually we get to JRE AbstractInterruptibleChannel::close() and SocketChannelImpl::implCloseSelectableChannel() which does the preClose() - via JNI this dup2()s a statically maintained descriptor (attached to a dummy Unix domain socket) onto the underlying file descriptor (as discussed by Alan Bateman (http://mail.openjdk.java.net/pipermail/core-libs-dev/2008-January/000219.html)). The problem occurs when the select() thread runs at the same time and the cancelled key is seen by SelectorImpl::processDeregisterQueue(). Eventually (in our case) EPollSelectorImpl::implDereg() tests the "channel closed" flag set by AbstractInterruptibleChannel::close() (this is not read-protected by a lock) and executes channel.kill() which closes the underlying file descriptor. If this happens before the preClose() in the other thread, the out-of-sequence dup2() leaks the file descriptor, attached to the UNIX domain socket. In the framework mentioned, we don't particularly want to add locking in the select() thread as this would impact other clients of the selector - alternatively a fix is to simply comment out the key.cancel(). channel.close() does the cancel() for us anyway, but after the close()/preClose() has completed, so the select() processing then occurs in the right sequence. (I am notifying Ronny Standtke of this issue independently)." See also following links for more information: http://stackoverflow.com/questions/7038688/java-nio-causes-file-descriptor-leak http://mail-archives.apache.org/mod_mbox/tomcat-users/201201.mbox/%3CCAJkSUv-DDKTCQ-pD7W=qovmph1dxexovcr+3mcgu05cqpt7...@mail.gmail.com%3E http://www.apacheserver.net/HBase-Thrift-for-CDH3U3-leaking-file-descriptors-socket-at1580921.htm > Strange permament socket descriptors increasing leads to "Too many open files" > -- > > Key: CASSANDRA-4571 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4571 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.1.2 > Environment: CentOS 5.8 Linux 2.6.18-308.13.1.el5 #1 SMP Tue Aug 21 > 17:10:18 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux. > java version "1.6.0_33" > Java(TM) SE Runtime Environment (build 1.6.0_33-b03) > Java HotSpot(TM) 64-Bit Server VM (build 20.8-b03, mixed mode) >Reporter: Serg Shnerson >Priority: Critical > > On the two-node cluster there was found strange socket descriptors > increasing. lsof -n | grep java shows many rows like" > java 8380 cassandra 113r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 114r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 115r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 116r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 117r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 118r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 119r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 120r unix 0x8101a374a080 > 938348482 socket > " And number of this rows constantly increasing. After about 24 hours this > situation leads to error. > We use PHPCassa client. Load is not so high (aroud ~50kb/s on write). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA adm
[jira] [Updated] (CASSANDRA-4573) HSHA doesn't handle large messages gracefully
[
https://issues.apache.org/jira/browse/CASSANDRA-4573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tyler Hobbs updated CASSANDRA-4573:
---
Attachment: repro.py
The attached repro.py reproduces the issue using pycassa, but I can also
reproduce with phpcassa. I'm testing against 1.1.4, with the only change to
cassandra.yaml being a switch to hsha.
> HSHA doesn't handle large messages gracefully
> -
>
> Key: CASSANDRA-4573
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4573
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Tyler Hobbs
>Assignee: Vijay
> Attachments: repro.py
>
>
> HSHA doesn't seem to enforce any kind of max message length, and when
> messages are too large, it doesn't fail gracefully.
> With debug logs enabled, you'll see this:
> {{DEBUG 13:13:31,805 Unexpected state 16}}
> Which seems to mean that there's a SelectionKey that's valid, but isn't ready
> for reading, writing, or accepting.
> Client-side, you'll get this thrift error (while trying to read a frame as
> part of {{recv_batch_mutate}}):
> {{TTransportException: TSocket read 0 bytes}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4573) HSHA doesn't handle large messages gracefully
Tyler Hobbs created CASSANDRA-4573:
--
Summary: HSHA doesn't handle large messages gracefully
Key: CASSANDRA-4573
URL: https://issues.apache.org/jira/browse/CASSANDRA-4573
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Tyler Hobbs
Assignee: Vijay
HSHA doesn't seem to enforce any kind of max message length, and when messages
are too large, it doesn't fail gracefully.
With debug logs enabled, you'll see this:
{{DEBUG 13:13:31,805 Unexpected state 16}}
Which seems to mean that there's a SelectionKey that's valid, but isn't ready
for reading, writing, or accepting.
Client-side, you'll get this thrift error (while trying to read a frame as part
of {{recv_batch_mutate}}):
{{TTransportException: TSocket read 0 bytes}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4559) implement token relocation
[
https://issues.apache.org/jira/browse/CASSANDRA-4559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13440530#comment-13440530
]
Eric Evans commented on CASSANDRA-4559:
---
bq. It seems like that would be handy, though now you need to be able to
communicate multiple tokens in the status... which almost brings us back around
to the status-appending game we want to avoid in CASSANDRA-4383
I agree, but propose we do it anyway (append to the status), if it's important
to support more than one range in an operation. Taking the approach being
worked on in CASSANDRA-4383 seems like overkill, and _relocate_ is limited
enough in scope that is seems less likely to matter. The impact of any future
changes would be more limited as well.
I've updated the patches accordingly; Let me know what you think!
> implement token relocation
> --
>
> Key: CASSANDRA-4559
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4559
> Project: Cassandra
> Issue Type: Sub-task
> Components: Core, Tools
>Reporter: Eric Evans
>Assignee: Eric Evans
> Labels: vnodes
>
> Whatever the specifics of a _shuffle_ (see CASSANDRA-4443), it will be
> necessary to relocate a range from one node to another.
> _Edit0: Linked in new patch containing tests._
>
> h3. Patches
> ||Compare||Raw diff||Description||
> |[010_refactor_range_move|https://github.com/acunu/cassandra/compare/top-bases/p/4443/010_refactor_range_move...p/4443/010_refactor_range_move]|[010_refactor_range_move.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/010_refactor_range_move...p/4443/010_refactor_range_move.diff]|No
> Description|
> |[020_calculate_pending|https://github.com/acunu/cassandra/compare/top-bases/p/4443/020_calculate_pending...p/4443/020_calculate_pending]|[020_calculate_pending.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/020_calculate_pending...p/4443/020_calculate_pending.diff]|No
> Description|
> |[030_relocate_token|https://github.com/acunu/cassandra/compare/top-bases/p/4443/030_relocate_token...p/4443/030_relocate_token]|[030_relocate_token.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/030_relocate_token...p/4443/030_relocate_token.diff]|No
> Description|
> |[040_tests|https://github.com/acunu/cassandra/compare/top-bases/p/4443/040_tests...p/4443/040_tests]|[040_tests.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/040_tests...p/4443/040_tests.diff]|No
> Description|
>
> _Note: These are branches managed with TopGit. If you are applying the patch
> output manually, you will either need to filter the TopGit metadata files
> (i.e. {{wget -O - | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}),
> or remove them afterward ({{rm .topmsg .topdeps}})._
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4571) Strange permament socket descriptors increasing leads to "Too many open files"
[ https://issues.apache.org/jira/browse/CASSANDRA-4571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13440521#comment-13440521 ] Tobias Grahn commented on CASSANDRA-4571: - I can reproduce it every time we simulate a specific test case with load using many reads. We have a new installation of cassandra 1.1.3. So if you want some trace or dump whatever I can give it to you. > Strange permament socket descriptors increasing leads to "Too many open files" > -- > > Key: CASSANDRA-4571 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4571 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.1.2 > Environment: CentOS 5.8 Linux 2.6.18-308.13.1.el5 #1 SMP Tue Aug 21 > 17:10:18 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux. > java version "1.6.0_33" > Java(TM) SE Runtime Environment (build 1.6.0_33-b03) > Java HotSpot(TM) 64-Bit Server VM (build 20.8-b03, mixed mode) >Reporter: Serg Shnerson >Priority: Critical > > On the two-node cluster there was found strange socket descriptors > increasing. lsof -n | grep java shows many rows like" > java 8380 cassandra 113r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 114r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 115r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 116r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 117r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 118r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 119r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 120r unix 0x8101a374a080 > 938348482 socket > " And number of this rows constantly increasing. After about 24 hours this > situation leads to error. > We use PHPCassa client. Load is not so high (aroud ~50kb/s on write). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4571) Strange permament socket descriptors increasing leads to "Too many open files"
[ https://issues.apache.org/jira/browse/CASSANDRA-4571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13440518#comment-13440518 ] Tobias Grahn commented on CASSANDRA-4571: - I have seen the problem on cassandra 1.1.3 as well. Our 3 node cluster has the same issue. It's a blocker. We are using Hector as client and FD increases up to 100K and keeps growing... Java (build 1.6.0_32-b05) Linux 2.6.32-220.el6.x86_64 #1 SMP Wed Nov 9 08:03:13 EST 2011 x86_64 x86_64 x86_64 GNU/Linux After a fresh start cassandra uses one unix FD then we put some load on and it keeps growing. lsof -p 14597 | grep -i unix java14597 root 43u unix 0x88082a3acc800t0 42443166 socket Put load on cassandra and then it increases lsof -p 14597 | grep -i unix | wc -l 5678 7654 . 98403 > Strange permament socket descriptors increasing leads to "Too many open files" > -- > > Key: CASSANDRA-4571 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4571 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.1.2 > Environment: CentOS 5.8 Linux 2.6.18-308.13.1.el5 #1 SMP Tue Aug 21 > 17:10:18 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux. > java version "1.6.0_33" > Java(TM) SE Runtime Environment (build 1.6.0_33-b03) > Java HotSpot(TM) 64-Bit Server VM (build 20.8-b03, mixed mode) >Reporter: Serg Shnerson >Priority: Critical > > On the two-node cluster there was found strange socket descriptors > increasing. lsof -n | grep java shows many rows like" > java 8380 cassandra 113r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 114r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 115r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 116r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 117r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 118r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 119r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 120r unix 0x8101a374a080 > 938348482 socket > " And number of this rows constantly increasing. After about 24 hours this > situation leads to error. > We use PHPCassa client. Load is not so high (aroud ~50kb/s on write). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4571) Strange permament socket descriptors increasing leads to "Too many open files"
[ https://issues.apache.org/jira/browse/CASSANDRA-4571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13440516#comment-13440516 ] Brandon Williams commented on CASSANDRA-4571: - I've seen this a few times, but never found a cause/resolution, so I'll go ahead and dump what I know: * All cases thus far seem to be upgrades, not new installations. * 1.1 but less than 1.1.2 doesn't seem to exhibit * Cassandra doesn't use unix sockets, at all * This is fairly rare and only hits a handful of users * some people have this happen on all nodes, some have it happen on only a portion * going to such lengths as trying all kinds of different JVM versions and completely switching OSes has not helped One user wrote a simple app to track the lost FDs here: http://pastebin.com/faBkJueB and it seemed to correlate with opening one sstable, and another user has corroborated that. Both report heavy reads on that CF. No way to reproduce is yet known, I've failed in all my attempts. > Strange permament socket descriptors increasing leads to "Too many open files" > -- > > Key: CASSANDRA-4571 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4571 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 1.1.2 > Environment: CentOS 5.8 Linux 2.6.18-308.13.1.el5 #1 SMP Tue Aug 21 > 17:10:18 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux. > java version "1.6.0_33" > Java(TM) SE Runtime Environment (build 1.6.0_33-b03) > Java HotSpot(TM) 64-Bit Server VM (build 20.8-b03, mixed mode) >Reporter: Serg Shnerson >Priority: Critical > > On the two-node cluster there was found strange socket descriptors > increasing. lsof -n | grep java shows many rows like" > java 8380 cassandra 113r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 114r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 115r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 116r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 117r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 118r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 119r unix 0x8101a374a080 > 938348482 socket > java 8380 cassandra 120r unix 0x8101a374a080 > 938348482 socket > " And number of this rows constantly increasing. After about 24 hours this > situation leads to error. > We use PHPCassa client. Load is not so high (aroud ~50kb/s on write). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4572) lost+found directory in the data dir causes problems again
Brandon Williams created CASSANDRA-4572:
---
Summary: lost+found directory in the data dir causes problems again
Key: CASSANDRA-4572
URL: https://issues.apache.org/jira/browse/CASSANDRA-4572
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0
Reporter: Brandon Williams
Fix For: 1.1.5
Looks like we've regressed from CASSANDRA-1547 and mounting a fs directly on
the data dir is a problem again.
{noformat}
INFO [main] 2012-08-22 23:30:03,710 Directories.java (line 475) Upgrade from
pre-1.1 version detected: migrating sstables to new directory layout ERROR
[main] 2012-08-22 23:30:03,712 AbstractCassandraDaemon.java (line 370)
Exception encountered during startup
java.lang.NullPointerException at
org.apache.cassandra.db.Directories.migrateSSTables(Directories.java:487)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-4572) lost+found directory in the data dir causes problems again
[
https://issues.apache.org/jira/browse/CASSANDRA-4572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-4572:
---
Assignee: Yuki Morishita
> lost+found directory in the data dir causes problems again
> --
>
> Key: CASSANDRA-4572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4572
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.1.0
>Reporter: Brandon Williams
>Assignee: Yuki Morishita
> Fix For: 1.1.5
>
>
> Looks like we've regressed from CASSANDRA-1547 and mounting a fs directly on
> the data dir is a problem again.
> {noformat}
> INFO [main] 2012-08-22 23:30:03,710 Directories.java (line 475) Upgrade from
> pre-1.1 version detected: migrating sstables to new directory layout ERROR
> [main] 2012-08-22 23:30:03,712 AbstractCassandraDaemon.java (line 370)
> Exception encountered during startup
> java.lang.NullPointerException at
> org.apache.cassandra.db.Directories.migrateSSTables(Directories.java:487)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4571) Strange permament socket descriptors increasing leads to "Too many open files"
Serg Shnerson created CASSANDRA-4571: Summary: Strange permament socket descriptors increasing leads to "Too many open files" Key: CASSANDRA-4571 URL: https://issues.apache.org/jira/browse/CASSANDRA-4571 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.2 Environment: CentOS 5.8 Linux 2.6.18-308.13.1.el5 #1 SMP Tue Aug 21 17:10:18 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux. java version "1.6.0_33" Java(TM) SE Runtime Environment (build 1.6.0_33-b03) Java HotSpot(TM) 64-Bit Server VM (build 20.8-b03, mixed mode) Reporter: Serg Shnerson Priority: Critical On the two-node cluster there was found strange socket descriptors increasing. lsof -n | grep java shows many rows like" java 8380 cassandra 113r unix 0x8101a374a080 938348482 socket java 8380 cassandra 114r unix 0x8101a374a080 938348482 socket java 8380 cassandra 115r unix 0x8101a374a080 938348482 socket java 8380 cassandra 116r unix 0x8101a374a080 938348482 socket java 8380 cassandra 117r unix 0x8101a374a080 938348482 socket java 8380 cassandra 118r unix 0x8101a374a080 938348482 socket java 8380 cassandra 119r unix 0x8101a374a080 938348482 socket java 8380 cassandra 120r unix 0x8101a374a080 938348482 socket " And number of this rows constantly increasing. After about 24 hours this situation leads to error. We use PHPCassa client. Load is not so high (aroud ~50kb/s on write). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4500) cqlsh: understand updated encodings for collections
[ https://issues.apache.org/jira/browse/CASSANDRA-4500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13440431#comment-13440431 ] Brandon Williams commented on CASSANDRA-4500: - Hmm, do we want to put a lib named 'beta2' in a major release? Can we get something more official released there to include? Otherwise, LGTM > cqlsh: understand updated encodings for collections > --- > > Key: CASSANDRA-4500 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4500 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Affects Versions: 1.2.0 >Reporter: paul cannon >Assignee: paul cannon > Labels: cqlsh > Fix For: 1.2.0 > > Attachments: 4500.patch.txt > > > After CASSANDRA-4453, collections will be represented using the binary > encoding in thrift CqlResults instead of json. Update cqlsh (and python-cql > as necessary) to support. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4567) Error in log related to Murmer3Partitioner
[
https://issues.apache.org/jira/browse/CASSANDRA-4567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13440424#comment-13440424
]
Tyler Patterson commented on CASSANDRA-4567:
Would it be feasible to provide a more helpful error message for people that
didn't read NEWS.txt?
> Error in log related to Murmer3Partitioner
> --
>
> Key: CASSANDRA-4567
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4567
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.2.0
> Environment: Using ccm on ubuntu
>Reporter: Tyler Patterson
>Assignee: Pavel Yaskevich
> Fix For: 1.2.0
>
>
> Start a 2-node cluster on cassandra-1.1. Bring down one node, upgrade it to
> trunk, start it back up. The following error shows up in the log:
> {code}
> ...
> INFO [main] 2012-08-22 10:44:40,012 CacheService.java (line 170) Scheduling
> row cache save to each 0 seconds (going to save all keys).
> INFO [SSTableBatchOpen:1] 2012-08-22 10:44:40,106 SSTableReader.java (line
> 164) Opening
> /tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-2
> (148 bytes)
> INFO [SSTableBatchOpen:2] 2012-08-22 10:44:40,106 SSTableReader.java (line
> 164) Opening
> /tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-1
> (226 bytes)
> INFO [SSTableBatchOpen:3] 2012-08-22 10:44:40,106 SSTableReader.java (line
> 164) Opening
> /tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-3
> (89 bytes)
> ERROR [SSTableBatchOpen:3] 2012-08-22 10:44:40,114 CassandraDaemon.java (line
> 131) Exception in thread Thread[SSTableBatchOpen:3,5,main]
> java.lang.RuntimeException: Cannot open
> /tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-3
> because partitioner does not match
> org.apache.cassandra.dht.Murmur3Partitioner
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:175)
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:149)
> at
> org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:236)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> ERROR [SSTableBatchOpen:2] 2012-08-22 10:44:40,114 CassandraDaemon.java (line
> 131) Exception in thread Thread[SSTableBatchOpen:2,5,main]
> java.lang.RuntimeException: Cannot open
> /tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-1
> because partitioner does not match
> org.apache.cassandra.dht.Murmur3Partitioner
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:175)
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:149)
> at
> org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:236)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> ERROR [SSTableBatchOpen:1] 2012-08-22 10:44:40,114 CassandraDaemon.java (line
> 131) Exception in thread Thread[SSTableBatchOpen:1,5,main]
> java.lang.RuntimeException: Cannot open
> /tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-2
> because partitioner does not match
> org.apache.cassandra.dht.Murmur3Partitioner
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:175)
> at
> org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:149)
> at
> org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:236)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPool
git commit: Murmur3Partitioner improvements patch by Pavel Yaskevich; reviewed by Jonathan Ellis for CASSANDRA-3772
Updated Branches:
refs/heads/trunk 3925aba84 -> a89ef1ffd
Murmur3Partitioner improvements
patch by Pavel Yaskevich; reviewed by Jonathan Ellis for CASSANDRA-3772
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/a89ef1ff
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a89ef1ff
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a89ef1ff
Branch: refs/heads/trunk
Commit: a89ef1ffd4cd2ee39a2751f37044dba3015d72f1
Parents: 3925aba
Author: Pavel Yaskevich
Authored: Thu Aug 23 01:45:19 2012 +0300
Committer: Pavel Yaskevich
Committed: Thu Aug 23 19:18:33 2012 +0300
--
NEWS.txt |3 +
.../cassandra/dht/AbstractHashedPartitioner.java | 194 ---
src/java/org/apache/cassandra/dht/LongToken.java | 33 +++
.../apache/cassandra/dht/Murmur3Partitioner.java | 158 +++--
.../apache/cassandra/dht/RandomPartitioner.java| 160 -
.../cassandra/dht/Murmur3PartitionerTest.java | 41 +++
.../apache/cassandra/dht/PartitionerTestCase.java |5 +
7 files changed, 378 insertions(+), 216 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/a89ef1ff/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index fe0b93d..199dd8a 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -38,6 +38,9 @@ Upgrading
- The default bloom filter fp chance has been increased to 1%.
This will save about 30% of the memory used by the old default.
Existing columnfamilies will retain their old setting.
+- The default partitioner was changed from RandomPartitioner to
+ Murmur3Partitioner which provides faster hashing as well as
+ improved performance with secondary indexes.
Features
http://git-wip-us.apache.org/repos/asf/cassandra/blob/a89ef1ff/src/java/org/apache/cassandra/dht/AbstractHashedPartitioner.java
--
diff --git a/src/java/org/apache/cassandra/dht/AbstractHashedPartitioner.java
b/src/java/org/apache/cassandra/dht/AbstractHashedPartitioner.java
deleted file mode 100644
index 55dfb97..000
--- a/src/java/org/apache/cassandra/dht/AbstractHashedPartitioner.java
+++ /dev/null
@@ -1,194 +0,0 @@
-/**
- * Licensed to the Apache Software Foundation (ASF) under one
- * or more contributor license agreements. See the NOTICE file
- * distributed with this work for additional information
- * regarding copyright ownership. The ASF licenses this file
- * to you under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance
- * with the License. You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
-package org.apache.cassandra.dht;
-
-import java.math.BigDecimal;
-import java.math.BigInteger;
-import java.nio.ByteBuffer;
-import java.nio.charset.CharacterCodingException;
-import java.util.*;
-
-import org.apache.cassandra.config.ConfigurationException;
-import org.apache.cassandra.db.DecoratedKey;
-import org.apache.cassandra.utils.ByteBufferUtil;
-import org.apache.cassandra.utils.FBUtilities;
-import org.apache.cassandra.utils.GuidGenerator;
-import org.apache.cassandra.utils.Pair;
-
-/**
- * This class is the super class of classes that generate a BigIntegerToken
using hash function.
- */
-public abstract class AbstractHashedPartitioner extends
AbstractPartitioner
-{
-public static final BigInteger ZERO = new BigInteger("0");
-public static final BigIntegerToken MINIMUM = new BigIntegerToken("-1");
-public static final BigInteger MAXIMUM = new BigInteger("2").pow(127);
-
-private static final byte DELIMITER_BYTE = ":".getBytes()[0];
-
-/**
- * returns a hash of the byte buffer in the range of 0 - 2**127 as a
BigInteger
- *
- * @param buffer the buffer to hash
- * @return the BigInteger hash value
- */
-protected abstract BigInteger hash(ByteBuffer buffer);
-
-public DecoratedKey decorateKey(ByteBuffer key)
-{
-return new DecoratedKey(getToken(key), key);
-}
-
-public DecoratedKey convertFromDiskFormat(ByteBuffer fromdisk)
-{
-// find the delimiter position
-int splitPoint = -1;
-for (int i = fromdisk.position(); i < fromdisk.limit(); i++)
-{
-if (fromdisk.get(i) == DELIMITER_BYTE)
-{
-
git commit: Make jmx setters consistent with yaml config. Patch by Chris Merrill, reviewed by brandonwilliams for CASSANDRA-4479
Updated Branches:
refs/heads/trunk 8bd1c1f86 -> 3925aba84
Make jmx setters consistent with yaml config.
Patch by Chris Merrill, reviewed by brandonwilliams for CASSANDRA-4479
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3925aba8
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3925aba8
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3925aba8
Branch: refs/heads/trunk
Commit: 3925aba84260063618bf85db6d51b409116f4050
Parents: 8bd1c1f
Author: Brandon Williams
Authored: Thu Aug 23 10:58:54 2012 -0500
Committer: Brandon Williams
Committed: Thu Aug 23 10:58:54 2012 -0500
--
src/java/org/apache/cassandra/config/Config.java | 24 --
.../cassandra/config/DatabaseDescriptor.java | 25 ++
.../org/apache/cassandra/gms/FailureDetector.java | 10 ++---
.../org/apache/cassandra/service/CacheService.java | 26 ++-
.../org/apache/cassandra/service/StorageProxy.java | 14 +++
5 files changed, 59 insertions(+), 40 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/3925aba8/src/java/org/apache/cassandra/config/Config.java
--
diff --git a/src/java/org/apache/cassandra/config/Config.java
b/src/java/org/apache/cassandra/config/Config.java
index 8da9777..8488d08 100644
--- a/src/java/org/apache/cassandra/config/Config.java
+++ b/src/java/org/apache/cassandra/config/Config.java
@@ -19,7 +19,11 @@ package org.apache.cassandra.config;
import org.apache.cassandra.cache.ConcurrentLinkedHashCacheProvider;
-
+/**
+ * A class that contains configuration properties for the cassandra node it
runs within.
+ *
+ * Properties declared as volatile can be mutated via JMX.
+ */
public class Config
{
public String cluster_name = "Test Cluster";
@@ -30,8 +34,8 @@ public class Config
public String partitioner;
public Boolean auto_bootstrap = true;
-public Boolean hinted_handoff_enabled = true;
-public Integer max_hint_window_in_ms = Integer.MAX_VALUE;
+public volatile Boolean hinted_handoff_enabled = true;
+public volatile Integer max_hint_window_in_ms = Integer.MAX_VALUE;
public SeedProviderDef seed_provider;
public DiskAccessMode disk_access_mode = DiskAccessMode.auto;
@@ -40,7 +44,7 @@ public class Config
public String initial_token;
public Integer num_tokens = 1;
-public Long rpc_timeout_in_ms = new Long(1);
+public volatile Long rpc_timeout_in_ms = new Long(1);
public Long read_rpc_timeout_in_ms = new Long(1);
@@ -52,7 +56,7 @@ public class Config
public Integer streaming_socket_timeout_in_ms = new Integer(0);
-public Double phi_convict_threshold = 8.0;
+public volatile Double phi_convict_threshold = 8.0;
public Integer concurrent_reads = 8;
public Integer concurrent_writes = 32;
@@ -90,12 +94,12 @@ public class Config
public Integer column_index_size_in_kb = 64;
public Integer in_memory_compaction_limit_in_mb = 256;
public Integer concurrent_compactors =
Runtime.getRuntime().availableProcessors();
-public Integer compaction_throughput_mb_per_sec = 16;
+public volatile Integer compaction_throughput_mb_per_sec = 16;
public Boolean multithreaded_compaction = false;
public Integer max_streaming_retries = 3;
-public Integer stream_throughput_outbound_megabits_per_sec;
+public volatile Integer stream_throughput_outbound_megabits_per_sec;
public String[] data_file_directories;
@@ -132,17 +136,17 @@ public class Config
public int max_hints_delivery_threads = 1;
public boolean compaction_preheat_key_cache = true;
-public boolean incremental_backups = false;
+public volatile boolean incremental_backups = false;
public int memtable_flush_queue_size = 4;
public boolean trickle_fsync = false;
public int trickle_fsync_interval_in_kb = 10240;
public Long key_cache_size_in_mb = null;
-public int key_cache_save_period = 14400;
+public volatile int key_cache_save_period = 14400;
public int key_cache_keys_to_save = Integer.MAX_VALUE;
public long row_cache_size_in_mb = 0;
-public int row_cache_save_period = 0;
+public volatile int row_cache_save_period = 0;
public int row_cache_keys_to_save = Integer.MAX_VALUE;
public String row_cache_provider =
ConcurrentLinkedHashCacheProvider.class.getSimpleName();
public boolean populate_io_cache_on_flush = false;
http://git-wip-us.apache.org/repos/asf/cassandra/blob/3925aba8/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
--
diff --git a/src/java/org/apache/cassandra/config/DatabaseDescripto
[jira] [Commented] (CASSANDRA-3772) Evaluate Murmur3-based partitioner
[ https://issues.apache.org/jira/browse/CASSANDRA-3772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13440374#comment-13440374 ] Jonathan Ellis commented on CASSANDRA-3772: --- Might be able to share a describeOwnership implementation b/t M3P and RP that deals with Token, but +1 from me. > Evaluate Murmur3-based partitioner > -- > > Key: CASSANDRA-3772 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3772 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Jonathan Ellis >Assignee: Pavel Yaskevich > Fix For: 1.2.0 > > Attachments: 0001-CASSANDRA-3772.patch, > 0001-CASSANDRA-3772-Test.patch, CASSANDRA-3772-v2.patch, > CASSANDRA-3772-v3.patch, CASSANDRA-3772-v4.patch, hashed_partitioner_3.diff, > hashed_partitioner.diff, MumPartitionerTest.docx, try_murmur3_2.diff, > try_murmur3.diff > > > MD5 is a relatively heavyweight hash to use when we don't need cryptographic > qualities, just a good output distribution. Let's see how much overhead we > can save by using Murmur3 instead. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3772) Evaluate Murmur3-based partitioner
[ https://issues.apache.org/jira/browse/CASSANDRA-3772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3772: --- Attachment: CASSANDRA-3772-v4.patch v4 includes the following changes: - LongToken is added to o.a.c.dht - M3P is changed to use LongToken - AbstractHashedPartitioner is removed as no longer needed - RP was reverted to it's previous code state (before split into AHP and M3P) - NEWS.txt are updated to reflect change in default partitioner - added Murmur3PartitionerTest change to use longs in M3P buys us another ~6-7 op/s comparing to BigIntegerToken. > Evaluate Murmur3-based partitioner > -- > > Key: CASSANDRA-3772 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3772 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Jonathan Ellis >Assignee: Pavel Yaskevich > Fix For: 1.2.0 > > Attachments: 0001-CASSANDRA-3772.patch, > 0001-CASSANDRA-3772-Test.patch, CASSANDRA-3772-v2.patch, > CASSANDRA-3772-v3.patch, CASSANDRA-3772-v4.patch, hashed_partitioner_3.diff, > hashed_partitioner.diff, MumPartitionerTest.docx, try_murmur3_2.diff, > try_murmur3.diff > > > MD5 is a relatively heavyweight hash to use when we don't need cryptographic > qualities, just a good output distribution. Let's see how much overhead we > can save by using Murmur3 instead. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
