[Cassandra Wiki] Update of Roger Mbiama by Roger Mbiama
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Cassandra Wiki for
change notification.
The Roger Mbiama page has been changed by Roger Mbiama:
http://wiki.apache.org/cassandra/Roger%20Mbiama
Comment:
Angosso
New page:
Describe Roger Mbiama here.
conf/README.txt
Required configuration files
cassandra.yaml: main Cassandra configuration file
log4j-server.proprties: log4j configuration file for Cassandra server
Optional configuration files
access.properties: used for authorization
passwd.properties: used for authentication
cassandra-rack.properties: used by PropertyFileSnitch
# 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.
calculate_heap_sizes()
{
case `uname` in
Linux)
system_memory_in_mb=`free -m | awk '/Mem:/ {print $2}'`
system_cpu_cores=`egrep -c 'processor([[:space:]]+):.*'
/proc/cpuinfo`
break
;;
FreeBSD)
system_memory_in_bytes=`sysctl hw.physmem | awk '{print $2}'`
system_memory_in_mb=`expr $system_memory_in_bytes / 1024 / 1024`
system_cpu_cores=`sysctl hw.ncpu | awk '{print $2}'`
break
;;
SunOS)
system_memory_in_mb=`prtconf | awk '/Memory size:/ {print $3}'`
system_cpu_cores=`psrinfo | wc -l`
break
;;
*)
# assume reasonable defaults for e.g. a modern desktop or
# cheap server
system_memory_in_mb=2048
system_cpu_cores=2
;;
esac
max_heap_size_in_mb=`expr $system_memory_in_mb / 2`
MAX_HEAP_SIZE=${max_heap_size_in_mb}M
# Young gen: min(max_sensible_per_modern_cpu_core * num_cores, 1/4 * heap
size)
max_sensible_yg_per_core_in_mb=100
max_sensible_yg_in_mb=`expr $max_sensible_yg_per_core_in_mb *
$system_cpu_cores`
desired_yg_in_mb=`expr $max_heap_size_in_mb / 4`
if [ $desired_yg_in_mb -gt $max_sensible_yg_in_mb ]
then
HEAP_NEWSIZE=${max_sensible_yg_in_mb}M
else
HEAP_NEWSIZE=${desired_yg_in_mb}M
fi
}
# Override these to set the amount of memory to allocate to the JVM at
# start-up. For production use you almost certainly want to adjust
# this for your environment. MAX_HEAP_SIZE is the total amount of
# memory dedicated to the Java heap; HEAP_NEWSIZE refers to the size
# of the young generation. Both MAX_HEAP_SIZE and HEAP_NEWSIZE should
# be either set or not (if you set one, set the other).
#
# The main trade-off for the young generation is that the larger it
# is, the longer GC pause times will be. The shorter it is, the more
# expensive GC will be (usually).
#
# The example HEAP_NEWSIZE assumes a modern 8-core+ machine for decent pause
# times. If in doubt, and if you do not particularly want to tweak, go with
# 100 MB per physical CPU core.
#MAX_HEAP_SIZE=4G
#HEAP_NEWSIZE=800M
if [ x$MAX_HEAP_SIZE = x ] [ x$HEAP_NEWSIZE = x ]; then
calculate_heap_sizes
else
if [ x$MAX_HEAP_SIZE = x ] || [ x$HEAP_NEWSIZE = x ]; then
echo please set or unset MAX_HEAP_SIZE and HEAP_NEWSIZE in pairs (see
cassandra-env.sh)
exit 1
fi
fi
# Specifies the default port over which Cassandra will be available for
# JMX connections.
JMX_PORT=7199
# Here we create the arguments that will get passed to the jvm when
# starting cassandra.
# enable assertions. disabling this in production will give a modest
# performance benefit (around 5%).
JVM_OPTS=$JVM_OPTS -ea
# add the jamm javaagent
check_openjdk=`${JAVA:-java} -version 21 | awk '{if (NR == 2) {print $1}}'`
if [ $check_openjdk != OpenJDK ]
then
JVM_OPTS=$JVM_OPTS -javaagent:$CASSANDRA_HOME/lib/jamm-0.2.2.jar
fi
# enable thread priorities, primarily so we can give periodic tasks
# a lower priority to avoid interfering with client workload
JVM_OPTS=$JVM_OPTS -XX:+UseThreadPriorities
# allows lowering thread priority without being root. see
# http://tech.stolsvik.com/2010/01/linux-java-thread-priorities-workaround.html
JVM_OPTS=$JVM_OPTS -XX:ThreadPriorityPolicy=42
# min and max heap sizes should be set to the same value to avoid
# stop-the-world GC pauses during resize, and so that we can lock the
# heap in memory on startup to
[jira] [Created] (CASSANDRA-3037) Could not get input splits Caused by: java.io.IOException: failed connecting to all endpoints slave1/123.198.69.242
Could not get input splits Caused by: java.io.IOException: failed connecting to all endpoints slave1/123.198.69.242 --- Key: CASSANDRA-3037 URL: https://issues.apache.org/jira/browse/CASSANDRA-3037 Project: Cassandra Issue Type: Bug Components: Hadoop Affects Versions: 0.8.4 Environment: Ubuntu 10.04 LTS Hadoop from Cloudera 0.20.203 Latest java Reporter: Anton Vedeshin Priority: Blocker After upgrade of cassandra from 0.8.2 to 0.8.4, got this error, before upgrade everything was working fine I have restarted cassandra, removed data, etc. nothing helps I have 6 identical machines in the cloud, before it was working fine. If I make netstat then it shows port 9160 listening nodetool ... ring - responces with 6 machines UP. Finally I have truncated all 6 servers and reinstalled hadoop + cassandra 0.8.4 from scratch. compiled and tried to execute word_cound receive the same error as after upgrade Error: 11/08/15 15:23:54 INFO WordCount: output reducer type: cassandra 11/08/15 15:23:54 INFO jvm.JvmMetrics: Initializing JVM Metrics with processName=JobTracker, sessionId= Exception in thread main java.io.IOException: Could not get input splits at org.apache.cassandra.hadoop.ColumnFamilyInputFormat.getSplits(ColumnFamilyInputFormat.java:157) at org.apache.hadoop.mapred.JobClient.writeNewSplits(JobClient.java:885) at org.apache.hadoop.mapred.JobClient.submitJobInternal(JobClient.java:779) at org.apache.hadoop.mapreduce.Job.submit(Job.java:432) at org.apache.hadoop.mapreduce.Job.waitForCompletion(Job.java:447) at WordCount.run(Unknown Source) at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:65) at WordCount.main(Unknown Source) Caused by: java.util.concurrent.ExecutionException: java.io.IOException: failed connecting to all endpoints slave1/154.198.69.242 at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222) at java.util.concurrent.FutureTask.get(FutureTask.java:83) at org.apache.cassandra.hadoop.ColumnFamilyInputFormat.getSplits(ColumnFamilyInputFormat.java:153) ... 7 more Caused by: java.io.IOException: failed connecting to all endpoints slave1/154.198.69.242 at org.apache.cassandra.hadoop.ColumnFamilyInputFormat.getSubSplits(ColumnFamilyInputFormat.java:234) at org.apache.cassandra.hadoop.ColumnFamilyInputFormat.access$200(ColumnFamilyInputFormat.java:70) at org.apache.cassandra.hadoop.ColumnFamilyInputFormat$SplitCallable.call(ColumnFamilyInputFormat.java:190) at org.apache.cassandra.hadoop.ColumnFamilyInputFormat$SplitCallable.call(ColumnFamilyInputFormat.java:175) 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) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2500) Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter
[ https://issues.apache.org/jira/browse/CASSANDRA-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085100#comment-13085100 ] Kelley Reynolds commented on CASSANDRA-2500: DBI-like driver is located at https://github.com/kreynolds/cassandra-cql. One thing to note is that using this driver is incompatible (mostly) with using fauna/cassandra because the thrift bindings use the same namespace and will redeclare constants. This should be solved with a dedicated gem such as located at https://github.com/kreynolds/cassandra-thrift. Would it be possible to automate generation and deployment of the shared gem with the cassandra release process or is that to be left as an exercise for the client developers? Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter --- Key: CASSANDRA-2500 URL: https://issues.apache.org/jira/browse/CASSANDRA-2500 Project: Cassandra Issue Type: Task Components: API Reporter: Jon Hermes Assignee: Kelley Reynolds Labels: cql Fix For: 0.8.5 Attachments: 2500.txt, genthriftrb.txt, rbcql-0.0.0.tgz Create a ruby driver for CQL. Lacking something standard (such as py-dbapi), going with something common instead -- RoR ActiveRecord Connection Adapter (http://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/AbstractAdapter.html). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2034) Make Read Repair unnecessary when Hinted Handoff is enabled
[ https://issues.apache.org/jira/browse/CASSANDRA-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085142#comment-13085142 ] Patricio Echague commented on CASSANDRA-2034: - I can do that. Also, I'm not quite happy with waiting for local hints to complete per mutation. I'm thinking of adding them to the handler so that we can wait for the hints after scheduling all the mutations. It has pros and cons: Pros: If the coordinator node is overwhelmed, we can tell the client right away. Cons: Por large mutations, we are actually blocking for local hints (if any) per mutation which is not ideal. Make Read Repair unnecessary when Hinted Handoff is enabled --- Key: CASSANDRA-2034 URL: https://issues.apache.org/jira/browse/CASSANDRA-2034 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Assignee: Patricio Echague Fix For: 1.0 Attachments: 2034-formatting.txt, CASSANDRA-2034-trunk-v10.patch, CASSANDRA-2034-trunk-v11.patch, CASSANDRA-2034-trunk-v11.patch, CASSANDRA-2034-trunk-v12.patch, CASSANDRA-2034-trunk-v13.patch, CASSANDRA-2034-trunk-v2.patch, CASSANDRA-2034-trunk-v3.patch, CASSANDRA-2034-trunk-v4.patch, CASSANDRA-2034-trunk-v5.patch, CASSANDRA-2034-trunk-v6.patch, CASSANDRA-2034-trunk-v7.patch, CASSANDRA-2034-trunk-v8.patch, CASSANDRA-2034-trunk-v9.patch, CASSANDRA-2034-trunk.patch Original Estimate: 8h Remaining Estimate: 8h Currently, HH is purely an optimization -- if a machine goes down, enabling HH means RR/AES will have less work to do, but you can't disable RR entirely in most situations since HH doesn't kick in until the FailureDetector does. Let's add a scheduled task to the mutate path, such that we return to the client normally after ConsistencyLevel is achieved, but after RpcTimeout we check the responseHandler write acks and write local hints for any missing targets. This would making disabling RR when HH is enabled a much more reasonable option, which has a huge impact on read throughput. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2034) Make Read Repair unnecessary when Hinted Handoff is enabled
[ https://issues.apache.org/jira/browse/CASSANDRA-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085151#comment-13085151 ] Jonathan Ellis commented on CASSANDRA-2034: --- Yes, that should be in mutate() or the handler so the waiting is parallelized. Make Read Repair unnecessary when Hinted Handoff is enabled --- Key: CASSANDRA-2034 URL: https://issues.apache.org/jira/browse/CASSANDRA-2034 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Assignee: Patricio Echague Fix For: 1.0 Attachments: 2034-formatting.txt, CASSANDRA-2034-trunk-v10.patch, CASSANDRA-2034-trunk-v11.patch, CASSANDRA-2034-trunk-v11.patch, CASSANDRA-2034-trunk-v12.patch, CASSANDRA-2034-trunk-v13.patch, CASSANDRA-2034-trunk-v2.patch, CASSANDRA-2034-trunk-v3.patch, CASSANDRA-2034-trunk-v4.patch, CASSANDRA-2034-trunk-v5.patch, CASSANDRA-2034-trunk-v6.patch, CASSANDRA-2034-trunk-v7.patch, CASSANDRA-2034-trunk-v8.patch, CASSANDRA-2034-trunk-v9.patch, CASSANDRA-2034-trunk.patch Original Estimate: 8h Remaining Estimate: 8h Currently, HH is purely an optimization -- if a machine goes down, enabling HH means RR/AES will have less work to do, but you can't disable RR entirely in most situations since HH doesn't kick in until the FailureDetector does. Let's add a scheduled task to the mutate path, such that we return to the client normally after ConsistencyLevel is achieved, but after RpcTimeout we check the responseHandler write acks and write local hints for any missing targets. This would making disabling RR when HH is enabled a much more reasonable option, which has a huge impact on read throughput. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2820) Re-introduce FastByteArrayInputStream (and Output equivalent)
[ https://issues.apache.org/jira/browse/CASSANDRA-2820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Loy updated CASSANDRA-2820: Attachment: fast_bytearray_iostreams_harmony-patch-5.txt Re-introduce FastByteArrayInputStream (and Output equivalent) - Key: CASSANDRA-2820 URL: https://issues.apache.org/jira/browse/CASSANDRA-2820 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.8.0 Environment: n/a Reporter: Paul Loy Priority: Minor Labels: bytearrayinputstream, bytearrayoutputstream, license, synchronized Fix For: 1.0 Attachments: fast_bytearray_iostreams_harmony-patch-2.txt, fast_bytearray_iostreams_harmony-patch-3.txt, fast_bytearray_iostreams_harmony-patch-4.txt, fast_bytearray_iostreams_harmony-patch-5.txt In https://issues.apache.org/jira/browse/CASSANDRA-37 FastByteArrayInputStream and FastByteArrayOutputStream were removed due to being code copied from the JDK and then subsequently modified. The JDK license is incompatible with Apache 2 license so the code had to go. I have since had a look at the performance of the JDK ByteArrayInputStream and a FastByteArrayInputStream (i.e. one with synchronized methods made un-synchronized) and seen the difference is significant. After a warmup-period of 1 loops I get the following for 1 loops through a 128000 byte array: bais : 3513ms fbais: 72ms This varies depending on the OS, machine and Java version, but it's always in favour of the FastByteArrayInputStream as you might expect. Then, at Jonathan Ellis' suggestion, I tried this using a modified Apache Harmony ByteArrayInputStream - i.e. one whose license is compatible - and the results were the same. A significant boost. I will attach a patch with changes for the 0.8.0 tag. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2500) Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter
[ https://issues.apache.org/jira/browse/CASSANDRA-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085176#comment-13085176 ] Ryan King commented on CASSANDRA-2500: -- What would we need to change in fauna/cassandra? Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter --- Key: CASSANDRA-2500 URL: https://issues.apache.org/jira/browse/CASSANDRA-2500 Project: Cassandra Issue Type: Task Components: API Reporter: Jon Hermes Assignee: Kelley Reynolds Labels: cql Fix For: 0.8.5 Attachments: 2500.txt, genthriftrb.txt, rbcql-0.0.0.tgz Create a ruby driver for CQL. Lacking something standard (such as py-dbapi), going with something common instead -- RoR ActiveRecord Connection Adapter (http://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/AbstractAdapter.html). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2500) Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter
[ https://issues.apache.org/jira/browse/CASSANDRA-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085183#comment-13085183 ] Kelley Reynolds commented on CASSANDRA-2500: As you know there are several ways to solve that but a common cassandra-thrift gem (maintained by .. somebody) is one way. Fauna has the marketshare so I'm open to suggestions :) Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter --- Key: CASSANDRA-2500 URL: https://issues.apache.org/jira/browse/CASSANDRA-2500 Project: Cassandra Issue Type: Task Components: API Reporter: Jon Hermes Assignee: Kelley Reynolds Labels: cql Fix For: 0.8.5 Attachments: 2500.txt, genthriftrb.txt, rbcql-0.0.0.tgz Create a ruby driver for CQL. Lacking something standard (such as py-dbapi), going with something common instead -- RoR ActiveRecord Connection Adapter (http://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/AbstractAdapter.html). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-3038) nodetool snapshot does not handle keyspace arguments correctly
nodetool snapshot does not handle keyspace arguments correctly -- Key: CASSANDRA-3038 URL: https://issues.apache.org/jira/browse/CASSANDRA-3038 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.8.4 Reporter: Nate McCall Assignee: Nate McCall Priority: Minor Given the following invocation: ./bin/nodetool snapshot Keyspace1 -t keyspace1_snapshot -h localhost Snapshots are made for all keyspaces Given a multi-keyspace invocation: ./bin/nodetool snapshot Keyspace1 Keyspace2 Keyspac3 -t keyspace1_snapshot -h localhost Snapshots will be made for Keyspace2 and Keyspace3 but not Keyspace1. It appears there is just some antiquated command argument noodling in NodeCmd#handleSnapshots -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3038) nodetool snapshot does not handle keyspace arguments correctly
[ https://issues.apache.org/jira/browse/CASSANDRA-3038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate McCall updated CASSANDRA-3038: --- Attachment: 3038.txt Change to just make a copy of the cmdArgs array without modifying position. nodetool snapshot does not handle keyspace arguments correctly -- Key: CASSANDRA-3038 URL: https://issues.apache.org/jira/browse/CASSANDRA-3038 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.8.4 Reporter: Nate McCall Assignee: Nate McCall Priority: Minor Attachments: 3038.txt Given the following invocation: ./bin/nodetool snapshot Keyspace1 -t keyspace1_snapshot -h localhost Snapshots are made for all keyspaces Given a multi-keyspace invocation: ./bin/nodetool snapshot Keyspace1 Keyspace2 Keyspac3 -t keyspace1_snapshot -h localhost Snapshots will be made for Keyspace2 and Keyspace3 but not Keyspace1. It appears there is just some antiquated command argument noodling in NodeCmd#handleSnapshots -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2388) ColumnFamilyRecordReader fails for a given split because a host is down, even if records could reasonably be read from other replica.
[ https://issues.apache.org/jira/browse/CASSANDRA-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085255#comment-13085255 ] Jonathan Ellis commented on CASSANDRA-2388: --- Does that really fix things though? Because you could have a data node be reachable from the coordinator answering describe_alive_nodes, but unreachable from the client. So the client still needs to be able to skip unreachable endpoints itself, so describe_alive seems like gratuitous complexity. ColumnFamilyRecordReader fails for a given split because a host is down, even if records could reasonably be read from other replica. - Key: CASSANDRA-2388 URL: https://issues.apache.org/jira/browse/CASSANDRA-2388 Project: Cassandra Issue Type: Bug Components: Hadoop Affects Versions: 0.7.6, 0.8.0 Reporter: Eldon Stegall Assignee: Jeremy Hanna Labels: hadoop, inputformat Fix For: 0.7.9 Attachments: 0002_On_TException_try_next_split.patch, CASSANDRA-2388-addition1.patch, CASSANDRA-2388-extended.patch, CASSANDRA-2388.patch, CASSANDRA-2388.patch, CASSANDRA-2388.patch, CASSANDRA-2388.patch ColumnFamilyRecordReader only tries the first location for a given split. We should try multiple locations for a given split. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-3039) AssertionError on nodetool cleanup
AssertionError on nodetool cleanup -- Key: CASSANDRA-3039 URL: https://issues.apache.org/jira/browse/CASSANDRA-3039 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.4 Environment: Distributor ID: Ubuntu Description:Ubuntu 10.10 Release:10.10 Codename: maverick AWS: m2.xlarge instance 6 Node Cluster Reporter: Ray Slakinski While doing a cleanup I got the following AssertionError, I have tried a scrub and a major compaction before the cleanup which has not helped. ST: INFO 18:49:58,540 Scrubbing SSTableReader(path='/vol/cassandra/data/system/LocationInfo-g-93-Data.db') INFO 18:49:58,834 Scrub of SSTableReader(path='/vol/cassandra/data/system/LocationInfo-g-93-Data.db') complete: 4 rows in new sstable and 0 empty (tombstoned) rows dropped INFO 18:49:58,913 Scrubbing SSTableReader(path='/vol/cassandra/data/system/Migrations-g-56-Data.db') INFO 18:49:59,218 Scrub of SSTableReader(path='/vol/cassandra/data/system/Migrations-g-56-Data.db') complete: 1 rows in new sstable and 0 empty (tombstoned) rows dropped INFO 18:49:59,256 Scrubbing SSTableReader(path='/vol/cassandra/data/system/Schema-g-58-Data.db') INFO 18:49:59,323 Scrub of SSTableReader(path='/vol/cassandra/data/system/Schema-g-58-Data.db') complete: 34 rows in new sstable and 0 empty (tombstoned) rows dropped INFO 18:49:59,416 Scrubbing SSTableReader(path='/vol/cassandra/data/SpiderServices/Content2-g-5074-Data.db') INFO 18:50:50,137 Scrub of SSTableReader(path='/vol/cassandra/data/SpiderServices/Content2-g-5074-Data.db') complete: 91735 rows in new sstable and 32 empty (tombstoned) rows dropped INFO 18:50:50,137 Scrubbing SSTableReader(path='/vol/cassandra/data/SpiderServices/Content2-g-5075-Data.db') INFO 18:50:53,075 Scrub of SSTableReader(path='/vol/cassandra/data/SpiderServices/Content2-g-5075-Data.db') complete: 27940 rows in new sstable and 0 empty (tombstoned) rows dropped INFO 18:50:53,089 Scrubbing SSTableReader(path='/vol/cassandra/data/SpiderServices/Content-g-238-Data.db') INFO 18:51:10,302 Scrub of SSTableReader(path='/vol/cassandra/data/SpiderServices/Content-g-238-Data.db') complete: 70815 rows in new sstable and 0 empty (tombstoned) rows dropped INFO 18:53:05,420 Cleaning up SSTableReader(path='/vol/cassandra/data/SpiderServices/Content2-g-5078-Data.db') INFO 18:53:13,266 Cleaned up to /vol/cassandra/data/SpiderServices/Content2-tmp-g-5079-Data.db. 198,705,176 to 198,705,176 (~100% of original) bytes for 27,940 keys. Time: 7,846ms. INFO 18:53:13,267 Cleaning up SSTableReader(path='/vol/cassandra/data/SpiderServices/Content2-g-5077-Data.db') ERROR 18:53:33,913 Fatal exception in thread Thread[CompactionExecutor:21,1,RMI Runtime] java.lang.AssertionError at org.apache.cassandra.db.compaction.PrecompactedRow.write(PrecompactedRow.java:107) at org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:132) at org.apache.cassandra.db.compaction.CompactionManager.doCleanupCompaction(CompactionManager.java:866) at org.apache.cassandra.db.compaction.CompactionManager.access$500(CompactionManager.java:65) at org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:204) 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) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3039) AssertionError on nodetool cleanup
[ https://issues.apache.org/jira/browse/CASSANDRA-3039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-3039: -- Attachment: 3039.txt Patch to make cleanup and normal compaction able to skip empty rows (rows containing nothing but expired tombstones). Scrub can already handle these, so you can workaround by scrubbing frequently, but if your workload results in a lot of these rows you probably want to apply this patch sooner than later. AssertionError on nodetool cleanup -- Key: CASSANDRA-3039 URL: https://issues.apache.org/jira/browse/CASSANDRA-3039 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.4 Environment: Distributor ID: Ubuntu Description: Ubuntu 10.10 Release: 10.10 Codename: maverick AWS: m2.xlarge instance 6 Node Cluster Reporter: Ray Slakinski Labels: exception, nodetool Fix For: 0.8.5 Attachments: 3039.txt While doing a cleanup I got the following AssertionError, I have tried a scrub and a major compaction before the cleanup which has not helped. ST: INFO 18:49:58,540 Scrubbing SSTableReader(path='/vol/cassandra/data/system/LocationInfo-g-93-Data.db') INFO 18:49:58,834 Scrub of SSTableReader(path='/vol/cassandra/data/system/LocationInfo-g-93-Data.db') complete: 4 rows in new sstable and 0 empty (tombstoned) rows dropped INFO 18:49:58,913 Scrubbing SSTableReader(path='/vol/cassandra/data/system/Migrations-g-56-Data.db') INFO 18:49:59,218 Scrub of SSTableReader(path='/vol/cassandra/data/system/Migrations-g-56-Data.db') complete: 1 rows in new sstable and 0 empty (tombstoned) rows dropped INFO 18:49:59,256 Scrubbing SSTableReader(path='/vol/cassandra/data/system/Schema-g-58-Data.db') INFO 18:49:59,323 Scrub of SSTableReader(path='/vol/cassandra/data/system/Schema-g-58-Data.db') complete: 34 rows in new sstable and 0 empty (tombstoned) rows dropped INFO 18:49:59,416 Scrubbing SSTableReader(path='/vol/cassandra/data/SpiderServices/Content2-g-5074-Data.db') INFO 18:50:50,137 Scrub of SSTableReader(path='/vol/cassandra/data/SpiderServices/Content2-g-5074-Data.db') complete: 91735 rows in new sstable and 32 empty (tombstoned) rows dropped INFO 18:50:50,137 Scrubbing SSTableReader(path='/vol/cassandra/data/SpiderServices/Content2-g-5075-Data.db') INFO 18:50:53,075 Scrub of SSTableReader(path='/vol/cassandra/data/SpiderServices/Content2-g-5075-Data.db') complete: 27940 rows in new sstable and 0 empty (tombstoned) rows dropped INFO 18:50:53,089 Scrubbing SSTableReader(path='/vol/cassandra/data/SpiderServices/Content-g-238-Data.db') INFO 18:51:10,302 Scrub of SSTableReader(path='/vol/cassandra/data/SpiderServices/Content-g-238-Data.db') complete: 70815 rows in new sstable and 0 empty (tombstoned) rows dropped INFO 18:53:05,420 Cleaning up SSTableReader(path='/vol/cassandra/data/SpiderServices/Content2-g-5078-Data.db') INFO 18:53:13,266 Cleaned up to /vol/cassandra/data/SpiderServices/Content2-tmp-g-5079-Data.db. 198,705,176 to 198,705,176 (~100% of original) bytes for 27,940 keys. Time: 7,846ms. INFO 18:53:13,267 Cleaning up SSTableReader(path='/vol/cassandra/data/SpiderServices/Content2-g-5077-Data.db') ERROR 18:53:33,913 Fatal exception in thread Thread[CompactionExecutor:21,1,RMI Runtime] java.lang.AssertionError at org.apache.cassandra.db.compaction.PrecompactedRow.write(PrecompactedRow.java:107) at org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:132) at org.apache.cassandra.db.compaction.CompactionManager.doCleanupCompaction(CompactionManager.java:866) at org.apache.cassandra.db.compaction.CompactionManager.access$500(CompactionManager.java:65) at org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:204) 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) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2991) Add a 'load new sstables' JMX/nodetool command
[ https://issues.apache.org/jira/browse/CASSANDRA-2991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085300#comment-13085300 ] Brandon Williams commented on CASSANDRA-2991: - I too would prefer a simpler name for the nodetool command, perhaps just 'refresh' or 'scanfiles'? I don't want to bikeshed too much here, but I think the command should be something more concise. +1 otherwise, however. Add a 'load new sstables' JMX/nodetool command -- Key: CASSANDRA-2991 URL: https://issues.apache.org/jira/browse/CASSANDRA-2991 Project: Cassandra Issue Type: New Feature Components: Tools Reporter: Brandon Williams Assignee: Pavel Yaskevich Fix For: 0.8.5 Attachments: CASSANDRA-2991.patch Sometimes people have to create a new cluster to get around a problem and need to copy sstables around. It would be convenient to be able to trigger this from nodetool or JMX instead of doing a restart of the node. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2991) Add a 'load new sstables' JMX/nodetool command
[ https://issues.apache.org/jira/browse/CASSANDRA-2991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085307#comment-13085307 ] Pavel Yaskevich commented on CASSANDRA-2991: refresh if fine by me, will change before commit. Add a 'load new sstables' JMX/nodetool command -- Key: CASSANDRA-2991 URL: https://issues.apache.org/jira/browse/CASSANDRA-2991 Project: Cassandra Issue Type: New Feature Components: Tools Reporter: Brandon Williams Assignee: Pavel Yaskevich Fix For: 0.8.5 Attachments: CASSANDRA-2991.patch Sometimes people have to create a new cluster to get around a problem and need to copy sstables around. It would be convenient to be able to trigger this from nodetool or JMX instead of doing a restart of the node. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3023) NPE in describe_ring
[ https://issues.apache.org/jira/browse/CASSANDRA-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams reassigned CASSANDRA-3023: --- Assignee: Brandon Williams NPE in describe_ring Key: CASSANDRA-3023 URL: https://issues.apache.org/jira/browse/CASSANDRA-3023 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.4 Reporter: Eric Falcao Assignee: Brandon Williams Not sure how much of the following is relevant besides the stack trace, but here I go: I have a 2 DC, 2 node per DC cluster. DC1 had it's seed replaced but I hadn't restarted. I upgraded to 0.8.4 in the following fashion: -edited seeds -stopped both DC1 nodes -upgraded jars -started both nodes at the same time The non-seed node came up first and showed the following error. Then when the seed node came up, the error went away on the non-seed node but started occurring on the seed node: ERROR [pool-2-thread-15] 2011-08-12 22:32:27,438 Cassandra.java (line 3668) Internal error processing describe_ring java.lang.NullPointerException at org.apache.cassandra.service.StorageService.getRangeToRpcaddressMap(StorageService.java:623) at org.apache.cassandra.thrift.CassandraServer.describe_ring(CassandraServer.java:731) at org.apache.cassandra.thrift.Cassandra$Processor$describe_ring.process(Cassandra.java:3664) at org.apache.cassandra.thrift.Brisk$Processor.process(Brisk.java:464) at org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:187) 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:619) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3023) NPE in describe_ring
[ https://issues.apache.org/jira/browse/CASSANDRA-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085309#comment-13085309 ] Brandon Williams commented on CASSANDRA-3023: - This is going to happen anytime a) the tokens are known from being persisted in the system table and (so the coordinator knows about the nodes) but b) it has not actually talked to them, so it has no state information yet. There's no good way to fix this, because either we leave out tokens that we know about but do not have any other information for, or we just leave the NPE. On the bright side, the window to trigger this should be very short, probably just a handful of seconds at most. NPE in describe_ring Key: CASSANDRA-3023 URL: https://issues.apache.org/jira/browse/CASSANDRA-3023 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.4 Reporter: Eric Falcao Not sure how much of the following is relevant besides the stack trace, but here I go: I have a 2 DC, 2 node per DC cluster. DC1 had it's seed replaced but I hadn't restarted. I upgraded to 0.8.4 in the following fashion: -edited seeds -stopped both DC1 nodes -upgraded jars -started both nodes at the same time The non-seed node came up first and showed the following error. Then when the seed node came up, the error went away on the non-seed node but started occurring on the seed node: ERROR [pool-2-thread-15] 2011-08-12 22:32:27,438 Cassandra.java (line 3668) Internal error processing describe_ring java.lang.NullPointerException at org.apache.cassandra.service.StorageService.getRangeToRpcaddressMap(StorageService.java:623) at org.apache.cassandra.thrift.CassandraServer.describe_ring(CassandraServer.java:731) at org.apache.cassandra.thrift.Cassandra$Processor$describe_ring.process(Cassandra.java:3664) at org.apache.cassandra.thrift.Brisk$Processor.process(Brisk.java:464) at org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:187) 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:619) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2447) Remove auto-bootstrap option
[ https://issues.apache.org/jira/browse/CASSANDRA-2447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085311#comment-13085311 ] Brandon Williams commented on CASSANDRA-2447: - +1 Remove auto-bootstrap option Key: CASSANDRA-2447 URL: https://issues.apache.org/jira/browse/CASSANDRA-2447 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 1.0 Attachments: 2447-v2.txt We already optimize auto-bootstrap to be no-op if there are no non-system tables. Given that, the only penalty imposed by autobootstrap is a 30s sleep waiting for gossip. Feels worth it to avoid the confusion this option causes, and the problems if you don't turn it on when it should be. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2712) Old node that is no longer part of ring still appears via gossip in logs
[ https://issues.apache.org/jira/browse/CASSANDRA-2712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085315#comment-13085315 ] Brandon Williams commented on CASSANDRA-2712: - Actually, no, this is CASSANDRA-1730. Fixed in 0.6.9. Old node that is no longer part of ring still appears via gossip in logs Key: CASSANDRA-2712 URL: https://issues.apache.org/jira/browse/CASSANDRA-2712 Project: Cassandra Issue Type: Bug Affects Versions: 0.6.7 Reporter: Erik Bartels Priority: Minor A node that no longer shows up in nodetool -h localhost ring and is no longer accessible on the network still appears via gossip in the logs. 2011-05-26_06:03:59.95168 '' INFO [Timer-0] 06:04:47,230 Gossiper.java:406 FatClient /10.12.22.112 has been silent for 360ms, removing from gossip 2011-05-26_06:04:57.58040 '' INFO [GMFD:1] 06:05:17,692 Gossiper.java:591 Node /10.12.22.112 is now part of the cluster 2011-05-26_07:04:59.88488 '' INFO [Timer-0] 07:05:18,187 Gossiper.java:406 FatClient /10.12.22.112 has been silent for 360ms, removing from gossip 2011-05-26_07:05:18.18762 '' INFO [GMFD:1] 07:05:49,431 Gossiper.java:591 Node /10.12.22.112 is now part of the cluster 2011-05-26_08:05:27.91892 '' INFO [Timer-0] 08:05:50,010 Gossiper.java:406 FatClient /10.12.22.112 has been silent for 360ms, removing from gossip 2011-05-26_08:05:59.99158 '' INFO [GMFD:1] 08:06:20,161 Gossiper.java:591 Node /10.12.22.112 is now part of the cluster 2011-05-26_09:06:02.76256 '' INFO [Timer-0] 09:06:20,863 Gossiper.java:406 FatClient /10.12.22.112 has been silent for 360ms, removing from gossip 2011-05-26_09:06:20.86600 '' INFO [GMFD:1] 09:06:52,784 Gossiper.java:591 Node /10.12.22.112 is now part of the cluster 2011-05-26_10:05:19.26673 '' INFO [Timer-0] 10:06:52,972 Gossiper.java:406 FatClient /10.12.22.112 has been silent for 360ms, removing from gossip 2011-05-26_10:07:02.86638 '' INFO [GMFD:1] 10:07:23,108 Gossiper.java:591 Node /10.12.22.112 is now part of the cluster 2011-05-26_11:06:32.15460 '' INFO [Timer-0] 11:07:23,188 Gossiper.java:406 FatClient /10.12.22.112 has been silent for 360ms, removing from gossip 2011-05-26_11:07:23.18851 '' INFO [GMFD:1] 11:07:54,283 Gossiper.java:591 Node /10.12.22.112 is now part of the cluster 2011-05-26_12:07:30.27539 '' INFO [Timer-0] 12:07:54,946 Gossiper.java:406 FatClient /10.12.22.112 has been silent for 360ms, removing from gossip 2011-05-26_12:07:54.94630 '' INFO [GMFD:1] 12:08:25,108 Gossiper.java:591 Node /10.12.22.112 is now part of the cluster 2011-05-26_13:08:05.38616 '' INFO [Timer-0] 13:08:25,861 Gossiper.java:406 FatClient /10.12.22.112 has been silent for 360ms, removing from gossip 2011-05-26_13:08:25.86333 '' INFO [GMFD:1] 13:08:59,097 Gossiper.java:591 Node /10.12.22.112 is now part of the cluster 2011-05-26_14:08:42.40855 '' INFO [Timer-0] 14:08:59,779 Gossiper.java:406 FatClient /10.12.22.112 has been silent for 360ms, removing from gossip 2011-05-26_14:08:59.77963 '' INFO [GMFD:1] 14:09:30,266 Gossiper.java:591 Node /10.12.22.112 is now part of the cluster -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1158005 - in /cassandra/trunk: src/java/org/apache/cassandra/service/ test/unit/org/apache/cassandra/db/ test/unit/org/apache/cassandra/dht/ test/unit/org/apache/cassandra/service/
Author: jbellis
Date: Mon Aug 15 20:45:38 2011
New Revision: 1158005
URL: http://svn.apache.org/viewvc?rev=1158005view=rev
Log:
default auto_bootstrap to true and remove from example configuration
patch by jbellis; reviewed by brandonwilliams for CASSANDRA-2477
Modified:
cassandra/trunk/src/java/org/apache/cassandra/service/LoadBroadcaster.java
cassandra/trunk/src/java/org/apache/cassandra/service/StorageService.java
cassandra/trunk/test/unit/org/apache/cassandra/db/CleanupTest.java
cassandra/trunk/test/unit/org/apache/cassandra/dht/BootStrapperTest.java
cassandra/trunk/test/unit/org/apache/cassandra/service/AntiEntropyServiceTestAbstract.java
cassandra/trunk/test/unit/org/apache/cassandra/service/StorageServiceServerTest.java
Modified:
cassandra/trunk/src/java/org/apache/cassandra/service/LoadBroadcaster.java
URL:
http://svn.apache.org/viewvc/cassandra/trunk/src/java/org/apache/cassandra/service/LoadBroadcaster.java?rev=1158005r1=1158004r2=1158005view=diff
==
--- cassandra/trunk/src/java/org/apache/cassandra/service/LoadBroadcaster.java
(original)
+++ cassandra/trunk/src/java/org/apache/cassandra/service/LoadBroadcaster.java
Mon Aug 15 20:45:38 2011
@@ -85,23 +85,5 @@ public class LoadBroadcaster implements
};
StorageService.scheduledTasks.scheduleWithFixedDelay(runnable, 2 *
Gossiper.intervalInMillis, BROADCAST_INTERVAL, TimeUnit.MILLISECONDS);
}
-
-/**
- * Wait for at least BROADCAST_INTERVAL ms, to give all nodes enough time
to
- * report in.
- */
-public void waitForLoadInfo()
-{
-int duration = BROADCAST_INTERVAL + StorageService.RING_DELAY;
-try
-{
-logger_.info(Sleeping {} ms to wait for load information...,
duration);
-Thread.sleep(duration);
-}
-catch (InterruptedException e)
-{
-throw new AssertionError(e);
-}
-}
}
Modified:
cassandra/trunk/src/java/org/apache/cassandra/service/StorageService.java
URL:
http://svn.apache.org/viewvc/cassandra/trunk/src/java/org/apache/cassandra/service/StorageService.java?rev=1158005r1=1158004r2=1158005view=diff
==
--- cassandra/trunk/src/java/org/apache/cassandra/service/StorageService.java
(original)
+++ cassandra/trunk/src/java/org/apache/cassandra/service/StorageService.java
Mon Aug 15 20:45:38 2011
@@ -367,7 +367,12 @@ public class StorageService implements I
MigrationManager.passiveAnnounce(DatabaseDescriptor.getDefsVersion());
}
-public synchronized void initServer() throws IOException,
org.apache.cassandra.config.ConfigurationException
+public synchronized void initServer() throws IOException,
ConfigurationException
+{
+initServer(RING_DELAY);
+}
+
+public synchronized void initServer(int delay) throws IOException,
ConfigurationException
{
logger_.info(Cassandra version: +
FBUtilities.getReleaseVersionString());
logger_.info(Thrift API version: + Constants.VERSION);
@@ -431,7 +436,7 @@ public class StorageService implements I
if (Boolean.parseBoolean(System.getProperty(cassandra.join_ring,
true)))
{
-joinTokenRing();
+joinTokenRing(delay);
}
else
{
@@ -439,7 +444,7 @@ public class StorageService implements I
}
}
-private void joinTokenRing() throws IOException,
org.apache.cassandra.config.ConfigurationException
+private void joinTokenRing(int delay) throws IOException,
org.apache.cassandra.config.ConfigurationException
{
logger_.info(Starting up server gossip);
joined = true;
@@ -469,10 +474,17 @@ public class StorageService implements I
if (DatabaseDescriptor.isAutoBootstrap()
!(DatabaseDescriptor.getSeeds().contains(FBUtilities.getBroadcastAddress()) ||
SystemTable.isBootstrapped()))
{
-setMode(Joining: getting load and schema information, true);
-LoadBroadcaster.instance.waitForLoadInfo();
+setMode(Joining: waiting for ring and schema information, true);
+try
+{
+Thread.sleep(delay);
+}
+catch (InterruptedException e)
+{
+throw new AssertionError(e);
+}
if (logger_.isDebugEnabled())
-logger_.debug(... got load + schema info);
+logger_.debug(... got ring + schema info);
if (tokenMetadata_.isMember(FBUtilities.getBroadcastAddress()))
{
String s = This node is already a member of the token ring;
bootstrap aborted. (If replacing a dead node, remove the old one from the ring
first.);
@@ -526,7 +538,7 @@ public class StorageService implements I
if (!joined)
svn commit: r1158006 - /cassandra/trunk/src/java/org/apache/cassandra/cli/CliClient.java
Author: jbellis
Date: Mon Aug 15 20:50:47 2011
New Revision: 1158006
URL: http://svn.apache.org/viewvc?rev=1158006view=rev
Log:
fix loading cli help outside command execution loop
patch by jbellis
Modified:
cassandra/trunk/src/java/org/apache/cassandra/cli/CliClient.java
Modified: cassandra/trunk/src/java/org/apache/cassandra/cli/CliClient.java
URL:
http://svn.apache.org/viewvc/cassandra/trunk/src/java/org/apache/cassandra/cli/CliClient.java?rev=1158006r1=1158005r2=1158006view=diff
==
--- cassandra/trunk/src/java/org/apache/cassandra/cli/CliClient.java (original)
+++ cassandra/trunk/src/java/org/apache/cassandra/cli/CliClient.java Mon Aug 15
20:50:47 2011
@@ -17,7 +17,6 @@
*/
package org.apache.cassandra.cli;
-import java.io.IOError;
import java.io.IOException;
import java.io.InputStream;
import java.net.InetAddress;
@@ -58,7 +57,6 @@ import org.yaml.snakeyaml.Yaml;
// Cli Client Side Library
public class CliClient
{
-
/**
* Available value conversion functions
* Used by convertValueByFunction(Tree functionCall) method
@@ -163,6 +161,13 @@ public class CliClient
private CliUserHelp getHelp()
{
+if (help == null)
+help = loadHelp();
+return help;
+}
+
+private CliUserHelp loadHelp()
+{
final InputStream is =
CliClient.class.getClassLoader().getResourceAsStream(org/apache/cassandra/cli/CliHelp.yaml);
assert is != null;
@@ -182,7 +187,7 @@ public class CliClient
public void printBanner()
{
-sessionState.out.println(help.banner);
+sessionState.out.println(getHelp().banner);
}
// Execute a CLI Statement
@@ -315,13 +320,10 @@ public class CliClient
private void executeHelp(Tree tree)
{
-if (help == null)
-help = getHelp();
-
if (tree.getChildCount() 0)
{
String token = tree.getChild(0).getText();
-for (CliCommandHelp ch : help.commands)
+for (CliCommandHelp ch : getHelp().commands)
{
if (token.equals(ch.name))
{
@@ -332,7 +334,7 @@ public class CliClient
}
else
{
-sessionState.out.println(help.help);
+sessionState.out.println(getHelp().help);
}
}
[jira] [Commented] (CASSANDRA-2252) off-heap memtables
[ https://issues.apache.org/jira/browse/CASSANDRA-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085330#comment-13085330 ] Brandon Williams commented on CASSANDRA-2252: - bq. Also, I would like to know who the clown is that estimated this as 0.4 hours. :) Probably some suit. ;) off-heap memtables -- Key: CASSANDRA-2252 URL: https://issues.apache.org/jira/browse/CASSANDRA-2252 Project: Cassandra Issue Type: Improvement Reporter: Jonathan Ellis Assignee: Jonathan Ellis Fix For: 1.0 Attachments: 0001-add-MemtableAllocator.txt, 0002-add-off-heap-MemtableAllocator-support.txt, 2252-v3.txt, 2252-v4.txt, merged-2252.tgz Original Estimate: 0.4h Remaining Estimate: 0.4h The memtable design practically actively fights Java's GC design. Todd Lipcon gave a good explanation over on HBASE-3455. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3023) NPE in describe_ring
[ https://issues.apache.org/jira/browse/CASSANDRA-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085333#comment-13085333 ] Eric Falcao commented on CASSANDRA-3023: FWIW, and I should have mentioned originally, the exception is thrown repeatedly every few seconds and doesn't seem to stop on the seed node NPE in describe_ring Key: CASSANDRA-3023 URL: https://issues.apache.org/jira/browse/CASSANDRA-3023 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.4 Reporter: Eric Falcao Assignee: Brandon Williams Not sure how much of the following is relevant besides the stack trace, but here I go: I have a 2 DC, 2 node per DC cluster. DC1 had it's seed replaced but I hadn't restarted. I upgraded to 0.8.4 in the following fashion: -edited seeds -stopped both DC1 nodes -upgraded jars -started both nodes at the same time The non-seed node came up first and showed the following error. Then when the seed node came up, the error went away on the non-seed node but started occurring on the seed node: ERROR [pool-2-thread-15] 2011-08-12 22:32:27,438 Cassandra.java (line 3668) Internal error processing describe_ring java.lang.NullPointerException at org.apache.cassandra.service.StorageService.getRangeToRpcaddressMap(StorageService.java:623) at org.apache.cassandra.thrift.CassandraServer.describe_ring(CassandraServer.java:731) at org.apache.cassandra.thrift.Cassandra$Processor$describe_ring.process(Cassandra.java:3664) at org.apache.cassandra.thrift.Brisk$Processor.process(Brisk.java:464) at org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:187) 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:619) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2806) Expose gossip/FD info to JMX
[ https://issues.apache.org/jira/browse/CASSANDRA-2806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085348#comment-13085348 ] Brandon Williams commented on CASSANDRA-2806: - In the gossiper, we also need to expose the following op: * Forced quarantine/eviction of an IP address, possibly taking a parameter to define how long to quarantine it for. This way in the rare event that someone does break CASSANDRA-1730, they can fix it without full ring restarts, avoid other full ring restart situations. This shouldn't be exposed in nodetool though because it can easily be dangerous. Expose gossip/FD info to JMX Key: CASSANDRA-2806 URL: https://issues.apache.org/jira/browse/CASSANDRA-2806 Project: Cassandra Issue Type: Improvement Reporter: Brandon Williams Assignee: Patricio Echague Priority: Minor Fix For: 0.8.5 Attachments: CASSANDRA-2806-0.8-v1.patch, screenshot-1.jpg -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3023) NPE in describe_ring
[ https://issues.apache.org/jira/browse/CASSANDRA-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085353#comment-13085353 ] Brandon Williams commented on CASSANDRA-3023: - Was the cluster still mixed between 0.8.3 and 0.8.4 at that point? That would do it. The easiest thing to do is not describe the ring until all machines are on the same version. NPE in describe_ring Key: CASSANDRA-3023 URL: https://issues.apache.org/jira/browse/CASSANDRA-3023 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.4 Reporter: Eric Falcao Assignee: Brandon Williams Not sure how much of the following is relevant besides the stack trace, but here I go: I have a 2 DC, 2 node per DC cluster. DC1 had it's seed replaced but I hadn't restarted. I upgraded to 0.8.4 in the following fashion: -edited seeds -stopped both DC1 nodes -upgraded jars -started both nodes at the same time The non-seed node came up first and showed the following error. Then when the seed node came up, the error went away on the non-seed node but started occurring on the seed node: ERROR [pool-2-thread-15] 2011-08-12 22:32:27,438 Cassandra.java (line 3668) Internal error processing describe_ring java.lang.NullPointerException at org.apache.cassandra.service.StorageService.getRangeToRpcaddressMap(StorageService.java:623) at org.apache.cassandra.thrift.CassandraServer.describe_ring(CassandraServer.java:731) at org.apache.cassandra.thrift.Cassandra$Processor$describe_ring.process(Cassandra.java:3664) at org.apache.cassandra.thrift.Brisk$Processor.process(Brisk.java:464) at org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:187) 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:619) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3038) nodetool snapshot does not handle keyspace arguments correctly
[ https://issues.apache.org/jira/browse/CASSANDRA-3038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-3038: Reviewer: brandon.williams nodetool snapshot does not handle keyspace arguments correctly -- Key: CASSANDRA-3038 URL: https://issues.apache.org/jira/browse/CASSANDRA-3038 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.8.4 Reporter: Nate McCall Assignee: Nate McCall Priority: Minor Fix For: 0.8.5 Attachments: 3038.txt Given the following invocation: ./bin/nodetool snapshot Keyspace1 -t keyspace1_snapshot -h localhost Snapshots are made for all keyspaces Given a multi-keyspace invocation: ./bin/nodetool snapshot Keyspace1 Keyspace2 Keyspac3 -t keyspace1_snapshot -h localhost Snapshots will be made for Keyspace2 and Keyspace3 but not Keyspace1. It appears there is just some antiquated command argument noodling in NodeCmd#handleSnapshots -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2806) Expose gossip/FD info to JMX
[ https://issues.apache.org/jira/browse/CASSANDRA-2806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-2806: Reviewer: brandon.williams Expose gossip/FD info to JMX Key: CASSANDRA-2806 URL: https://issues.apache.org/jira/browse/CASSANDRA-2806 Project: Cassandra Issue Type: Improvement Reporter: Brandon Williams Assignee: Patricio Echague Priority: Minor Fix For: 0.8.5 Attachments: CASSANDRA-2806-0.8-v1.patch, screenshot-1.jpg -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2961) Expire dead gossip states based on time
[ https://issues.apache.org/jira/browse/CASSANDRA-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-2961: Reviewer: brandon.williams Expire dead gossip states based on time --- Key: CASSANDRA-2961 URL: https://issues.apache.org/jira/browse/CASSANDRA-2961 Project: Cassandra Issue Type: Improvement Reporter: Brandon Williams Assignee: Patricio Echague Currently dead states are held until aVeryLongTime, 3 days. The problem is that if a node reboots within this period, it begins a new 3 days and will repopulate the ring with the dead state. While mostly harmless, perpetuating the state forever is at least wasting a small amount of bandwidth. Instead, we can expire states based on a ttl, which will require that the cluster be loosely time synced; within the quarantine period of 60s. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3023) NPE in describe_ring
[ https://issues.apache.org/jira/browse/CASSANDRA-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085360#comment-13085360 ] Eric Falcao commented on CASSANDRA-3023: i was upgrading one DC first and that's when i noticed it (and never upgraded the 2nd DC). Not sure if that matters. If so, I'll try upgrading both DC's and see if the error persists after fully upgraded. NPE in describe_ring Key: CASSANDRA-3023 URL: https://issues.apache.org/jira/browse/CASSANDRA-3023 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.4 Reporter: Eric Falcao Assignee: Brandon Williams Not sure how much of the following is relevant besides the stack trace, but here I go: I have a 2 DC, 2 node per DC cluster. DC1 had it's seed replaced but I hadn't restarted. I upgraded to 0.8.4 in the following fashion: -edited seeds -stopped both DC1 nodes -upgraded jars -started both nodes at the same time The non-seed node came up first and showed the following error. Then when the seed node came up, the error went away on the non-seed node but started occurring on the seed node: ERROR [pool-2-thread-15] 2011-08-12 22:32:27,438 Cassandra.java (line 3668) Internal error processing describe_ring java.lang.NullPointerException at org.apache.cassandra.service.StorageService.getRangeToRpcaddressMap(StorageService.java:623) at org.apache.cassandra.thrift.CassandraServer.describe_ring(CassandraServer.java:731) at org.apache.cassandra.thrift.Cassandra$Processor$describe_ring.process(Cassandra.java:3664) at org.apache.cassandra.thrift.Brisk$Processor.process(Brisk.java:464) at org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:187) 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:619) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3023) NPE in describe_ring
[ https://issues.apache.org/jira/browse/CASSANDRA-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085369#comment-13085369 ] Brandon Williams commented on CASSANDRA-3023: - This will happen in a mixed cluster because nodes prior to CASSANDRA-1777 will not have advertised the information that describe_ring now relies on, causing the NPE when the nodes that do have 1777 try to access it. There's not a lot we can do here. We can basically return half-broken data for nodes that haven't advertised this info yet, but that puts us back to before CASSANDRA-1777, so it's not much of a win. I can't think of a reason why clients would need to call describe_ring while there's an upgrade in process; topology isn't changing. NPE in describe_ring Key: CASSANDRA-3023 URL: https://issues.apache.org/jira/browse/CASSANDRA-3023 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.4 Reporter: Eric Falcao Assignee: Brandon Williams Not sure how much of the following is relevant besides the stack trace, but here I go: I have a 2 DC, 2 node per DC cluster. DC1 had it's seed replaced but I hadn't restarted. I upgraded to 0.8.4 in the following fashion: -edited seeds -stopped both DC1 nodes -upgraded jars -started both nodes at the same time The non-seed node came up first and showed the following error. Then when the seed node came up, the error went away on the non-seed node but started occurring on the seed node: ERROR [pool-2-thread-15] 2011-08-12 22:32:27,438 Cassandra.java (line 3668) Internal error processing describe_ring java.lang.NullPointerException at org.apache.cassandra.service.StorageService.getRangeToRpcaddressMap(StorageService.java:623) at org.apache.cassandra.thrift.CassandraServer.describe_ring(CassandraServer.java:731) at org.apache.cassandra.thrift.Cassandra$Processor$describe_ring.process(Cassandra.java:3664) at org.apache.cassandra.thrift.Brisk$Processor.process(Brisk.java:464) at org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:187) 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:619) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2991) Add a 'load new sstables' JMX/nodetool command
[ https://issues.apache.org/jira/browse/CASSANDRA-2991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085379#comment-13085379 ] Hudson commented on CASSANDRA-2991: --- Integrated in Cassandra-0.8 #280 (See [https://builds.apache.org/job/Cassandra-0.8/280/]) Add 'load new SSTables' functionality to JMX and corresponding refresh command to the nodetool patch by Pavel Yaskevich; reviewed by Brandon Williams for CASSANDRA-2991 xedin : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1158008 Files : * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/tools/NodeProbe.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/StorageServiceMBean.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/ColumnFamilyStoreMBean.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/tools/NodeCmd.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/ColumnFamilyStore.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/StorageService.java Add a 'load new sstables' JMX/nodetool command -- Key: CASSANDRA-2991 URL: https://issues.apache.org/jira/browse/CASSANDRA-2991 Project: Cassandra Issue Type: New Feature Components: Tools Reporter: Brandon Williams Assignee: Pavel Yaskevich Fix For: 0.8.5 Attachments: CASSANDRA-2991.patch Sometimes people have to create a new cluster to get around a problem and need to copy sstables around. It would be convenient to be able to trigger this from nodetool or JMX instead of doing a restart of the node. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2820) Re-introduce FastByteArrayInputStream (and Output equivalent)
[ https://issues.apache.org/jira/browse/CASSANDRA-2820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085152#comment-13085152 ] Paul Loy edited comment on CASSANDRA-2820 at 8/15/11 10:22 PM: --- Hey Sylvian, likewise sorry for my delay. Have been job hunting, and will now be relocating to LA from London. I've just rebased, will attach a patch. Paul was (Author: keteracel): Hey Silvian, likewise sorry for my delay. Have been job hunting, and will now be relocating to LA from London. I've just rebased, will attach a patch. Paul Re-introduce FastByteArrayInputStream (and Output equivalent) - Key: CASSANDRA-2820 URL: https://issues.apache.org/jira/browse/CASSANDRA-2820 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.8.0 Environment: n/a Reporter: Paul Loy Priority: Minor Labels: bytearrayinputstream, bytearrayoutputstream, license, synchronized Fix For: 1.0 Attachments: fast_bytearray_iostreams_harmony-patch-2.txt, fast_bytearray_iostreams_harmony-patch-3.txt, fast_bytearray_iostreams_harmony-patch-4.txt, fast_bytearray_iostreams_harmony-patch-5.txt In https://issues.apache.org/jira/browse/CASSANDRA-37 FastByteArrayInputStream and FastByteArrayOutputStream were removed due to being code copied from the JDK and then subsequently modified. The JDK license is incompatible with Apache 2 license so the code had to go. I have since had a look at the performance of the JDK ByteArrayInputStream and a FastByteArrayInputStream (i.e. one with synchronized methods made un-synchronized) and seen the difference is significant. After a warmup-period of 1 loops I get the following for 1 loops through a 128000 byte array: bais : 3513ms fbais: 72ms This varies depending on the OS, machine and Java version, but it's always in favour of the FastByteArrayInputStream as you might expect. Then, at Jonathan Ellis' suggestion, I tried this using a modified Apache Harmony ByteArrayInputStream - i.e. one whose license is compatible - and the results were the same. A significant boost. I will attach a patch with changes for the 0.8.0 tag. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2034) Make Read Repair unnecessary when Hinted Handoff is enabled
[ https://issues.apache.org/jira/browse/CASSANDRA-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patricio Echague updated CASSANDRA-2034: Attachment: CASSANDRA-2034-trunk-v14.patch v14 replaces v13. - Wait for the hint at SP.mutate() - Avoid passing a list of down host and handle them with FD. - Simplifies even more the logic in SP.sendToHintedEndpoints Make Read Repair unnecessary when Hinted Handoff is enabled --- Key: CASSANDRA-2034 URL: https://issues.apache.org/jira/browse/CASSANDRA-2034 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Assignee: Patricio Echague Fix For: 1.0 Attachments: 2034-formatting.txt, CASSANDRA-2034-trunk-v10.patch, CASSANDRA-2034-trunk-v11.patch, CASSANDRA-2034-trunk-v11.patch, CASSANDRA-2034-trunk-v12.patch, CASSANDRA-2034-trunk-v13.patch, CASSANDRA-2034-trunk-v14.patch, CASSANDRA-2034-trunk-v2.patch, CASSANDRA-2034-trunk-v3.patch, CASSANDRA-2034-trunk-v4.patch, CASSANDRA-2034-trunk-v5.patch, CASSANDRA-2034-trunk-v6.patch, CASSANDRA-2034-trunk-v7.patch, CASSANDRA-2034-trunk-v8.patch, CASSANDRA-2034-trunk-v9.patch, CASSANDRA-2034-trunk.patch Original Estimate: 8h Remaining Estimate: 8h Currently, HH is purely an optimization -- if a machine goes down, enabling HH means RR/AES will have less work to do, but you can't disable RR entirely in most situations since HH doesn't kick in until the FailureDetector does. Let's add a scheduled task to the mutate path, such that we return to the client normally after ConsistencyLevel is achieved, but after RpcTimeout we check the responseHandler write acks and write local hints for any missing targets. This would making disabling RR when HH is enabled a much more reasonable option, which has a huge impact on read throughput. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2806) Expose gossip/FD info to JMX
[ https://issues.apache.org/jira/browse/CASSANDRA-2806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patricio Echague updated CASSANDRA-2806: Attachment: CASSANDRA-2806-0.8-v2.patch v2 replaces v1 - Add GossiperMBean with its implementation. Expose gossip/FD info to JMX Key: CASSANDRA-2806 URL: https://issues.apache.org/jira/browse/CASSANDRA-2806 Project: Cassandra Issue Type: Improvement Reporter: Brandon Williams Assignee: Patricio Echague Priority: Minor Fix For: 0.8.5 Attachments: CASSANDRA-2806-0.8-v1.patch, CASSANDRA-2806-0.8-v2.patch, screenshot-1.jpg -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2034) Make Read Repair unnecessary when Hinted Handoff is enabled
[
https://issues.apache.org/jira/browse/CASSANDRA-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085497#comment-13085497
]
Jonathan Ellis commented on CASSANDRA-2034:
---
Hmm. I think you're right: it would work better to do the hints in the handler
instead of passing these lists around. Sorry; let's change it to do it that
way.
Other notes:
SP.shouldHint is broken (will always return true when hints are disabled). I
would write it like this:
{code}
public static boolean shouldHint(InetAddress ep)
{
if (!isHintedHandoffEnabled())
return false;
boolean hintWindowExpired = Gossiper.instance.getEndpointDowntime(ep)
maxHintWindow;
if (hintWindowExpired)
logger.debug(not hinting {} which has been down {}ms, ep,
Gossiper.instance.getEndpointDowntime(ep));
return !hintWindowExpired;
}
{code}
CallbackInfo.shouldHint is broken a different way. It should be returning true
if and only if the write to the target failed. (Calling this variable from
is odd -- from is used to refer to localhost in a MessageService context.)
Currently, it returns true if the overall CL is achieved, which in the general
case tells us nothing about the individual replica in question.
Make Read Repair unnecessary when Hinted Handoff is enabled
---
Key: CASSANDRA-2034
URL: https://issues.apache.org/jira/browse/CASSANDRA-2034
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Jonathan Ellis
Assignee: Patricio Echague
Fix For: 1.0
Attachments: 2034-formatting.txt, CASSANDRA-2034-trunk-v10.patch,
CASSANDRA-2034-trunk-v11.patch, CASSANDRA-2034-trunk-v11.patch,
CASSANDRA-2034-trunk-v12.patch, CASSANDRA-2034-trunk-v13.patch,
CASSANDRA-2034-trunk-v14.patch, CASSANDRA-2034-trunk-v2.patch,
CASSANDRA-2034-trunk-v3.patch, CASSANDRA-2034-trunk-v4.patch,
CASSANDRA-2034-trunk-v5.patch, CASSANDRA-2034-trunk-v6.patch,
CASSANDRA-2034-trunk-v7.patch, CASSANDRA-2034-trunk-v8.patch,
CASSANDRA-2034-trunk-v9.patch, CASSANDRA-2034-trunk.patch
Original Estimate: 8h
Remaining Estimate: 8h
Currently, HH is purely an optimization -- if a machine goes down, enabling
HH means RR/AES will have less work to do, but you can't disable RR entirely
in most situations since HH doesn't kick in until the FailureDetector does.
Let's add a scheduled task to the mutate path, such that we return to the
client normally after ConsistencyLevel is achieved, but after RpcTimeout we
check the responseHandler write acks and write local hints for any missing
targets.
This would making disabling RR when HH is enabled a much more reasonable
option, which has a huge impact on read throughput.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2820) Re-introduce FastByteArrayInputStream (and Output equivalent)
[ https://issues.apache.org/jira/browse/CASSANDRA-2820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085513#comment-13085513 ] Jonathan Ellis commented on CASSANDRA-2820: --- Hi Paul, Sylvain is on vacation but I can take care of committing this. It looks like v5 is against 0.8, can you attach a patch against trunk? Re-introduce FastByteArrayInputStream (and Output equivalent) - Key: CASSANDRA-2820 URL: https://issues.apache.org/jira/browse/CASSANDRA-2820 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.8.0 Environment: n/a Reporter: Paul Loy Priority: Minor Labels: bytearrayinputstream, bytearrayoutputstream, license, synchronized Fix For: 1.0 Attachments: fast_bytearray_iostreams_harmony-patch-2.txt, fast_bytearray_iostreams_harmony-patch-3.txt, fast_bytearray_iostreams_harmony-patch-4.txt, fast_bytearray_iostreams_harmony-patch-5.txt In https://issues.apache.org/jira/browse/CASSANDRA-37 FastByteArrayInputStream and FastByteArrayOutputStream were removed due to being code copied from the JDK and then subsequently modified. The JDK license is incompatible with Apache 2 license so the code had to go. I have since had a look at the performance of the JDK ByteArrayInputStream and a FastByteArrayInputStream (i.e. one with synchronized methods made un-synchronized) and seen the difference is significant. After a warmup-period of 1 loops I get the following for 1 loops through a 128000 byte array: bais : 3513ms fbais: 72ms This varies depending on the OS, machine and Java version, but it's always in favour of the FastByteArrayInputStream as you might expect. Then, at Jonathan Ellis' suggestion, I tried this using a modified Apache Harmony ByteArrayInputStream - i.e. one whose license is compatible - and the results were the same. A significant boost. I will attach a patch with changes for the 0.8.0 tag. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
