[jira] [Created] (CASSANDRA-4154) CFRR wide row iterator does not handle tombstones well
CFRR wide row iterator does not handle tombstones well
--
Key: CASSANDRA-4154
URL: https://issues.apache.org/jira/browse/CASSANDRA-4154
Project: Cassandra
Issue Type: Bug
Components: Hadoop
Affects Versions: 1.1.0
Reporter: Brandon Williams
Assignee: Jonathan Ellis
Fix For: 1.1.0
If the last row is a tombstone, CFRR's wide row iterator will throw an
exception:
{noformat}
java.util.NoSuchElementException
at com.google.common.collect.Iterables.getLast(Iterables.java:663)
at
org.apache.cassandra.hadoop.ColumnFamilyRecordReader$WideRowIterator.maybeInit(ColumnFamilyRecordReader.java:441)
at
org.apache.cassandra.hadoop.ColumnFamilyRecordReader$WideRowIterator.computeNext(ColumnFamilyRecordReader.java:467)
at
org.apache.cassandra.hadoop.ColumnFamilyRecordReader$WideRowIterator.computeNext(ColumnFamilyRecordReader.java:413)
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:137)
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:132)
at
org.apache.cassandra.hadoop.ColumnFamilyRecordReader.nextKeyValue(ColumnFamilyRecordReader.java:188)
at
org.apache.cassandra.hadoop.pig.CassandraStorage.getNextWide(CassandraStorage.java:140)
at
org.apache.cassandra.hadoop.pig.CassandraStorage.getNext(CassandraStorage.java:199)
at
org.apache.pig.backend.hadoop.executionengine.mapReduceLayer.PigRecordReader.nextKeyValue(PigRecordReader.java:187)
at
org.apache.hadoop.mapred.MapTask$NewTrackingRecordReader.nextKeyValue(MapTask.java:423)
at
org.apache.hadoop.mapreduce.MapContext.nextKeyValue(MapContext.java:67)
at org.apache.hadoop.mapreduce.Mapper.run(Mapper.java:143)
at org.apache.hadoop.mapred.MapTask.runNewMapper(MapTask.java:621)
at org.apache.hadoop.mapred.MapTask.run(MapTask.java:305)
at
org.apache.hadoop.mapred.LocalJobRunner$Job.run(LocalJobRunner.java:177)
{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-4101) Gossip should propagate MessagingService.version
Gossip should propagate MessagingService.version Key: CASSANDRA-4101 URL: https://issues.apache.org/jira/browse/CASSANDRA-4101 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Brandon Williams Priority: Critical Fix For: 1.1.0 In CASSANDRA-4099 it's becoming apparent that it's time to fix our hacky versioning tricks we've used to remain backward-compatible. As a first step, let's communicate the version via gossip so we can eventually reason based on that. -- 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-4094) MS.getCommandPendingTasks returns a double
MS.getCommandPendingTasks returns a double -- Key: CASSANDRA-4094 URL: https://issues.apache.org/jira/browse/CASSANDRA-4094 Project: Cassandra Issue Type: Improvement Reporter: Brandon Williams Assignee: Brandon Williams Priority: Trivial Fix For: 1.2 This makes no sense, since you can't have a partial task. -- 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-4086) decom should shut thrift down
decom should shut thrift down - Key: CASSANDRA-4086 URL: https://issues.apache.org/jira/browse/CASSANDRA-4086 Project: Cassandra Issue Type: Bug Reporter: Brandon Williams Assignee: Brandon Williams If you decom a node an then try to use it, you get nothing but timeouts. Instead let's just kill thrift so intelligent clients can move along. -- 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-4064) cfstats should include the cfId
cfstats should include the cfId --- Key: CASSANDRA-4064 URL: https://issues.apache.org/jira/browse/CASSANDRA-4064 Project: Cassandra Issue Type: Improvement Reporter: Brandon Williams Assignee: Brandon Williams Fix For: 1.0.9 Specifically, when troubleshooting the dreaded UnserializableColumnFamilyException: Couldn't find cfId=1001 type of error (and the schema is in agreement), it would be really useful to easily see the cfIds so you where the problem is (or is not) -- 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-4061) Decommission should take a token
Decommission should take a token Key: CASSANDRA-4061 URL: https://issues.apache.org/jira/browse/CASSANDRA-4061 Project: Cassandra Issue Type: Bug Reporter: Brandon Williams Assignee: Brandon Williams Fix For: 1.2 Like removetoken, decom should take a token parameter. This is a bit easier said than done because it changes gossip, but I've seen enough people burned by this (as I have myself.) In the short term though *decommission still accepts a token parameter* which I thought we had fixed. -- 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-4051) Stream sessions can only fail via the FailureDetector
Stream sessions can only fail via the FailureDetector - Key: CASSANDRA-4051 URL: https://issues.apache.org/jira/browse/CASSANDRA-4051 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.0 Reporter: Brandon Williams Assignee: Brandon Williams Fix For: 1.1.1 If for some reason, FileStreamTask itself fails more than the number of retry attempts but gossip continues to work, the stream session will never be closed. This is unlikely to happen in practice since it requires blocking the storage port from new connections but keeping the existing ones, however for the bulk loader this is especially problematic since it doesn't have access to a failure detector and thus no way of knowing if a session failed. -- 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-4045) BOF fails when some nodes are down
BOF fails when some nodes are down -- Key: CASSANDRA-4045 URL: https://issues.apache.org/jira/browse/CASSANDRA-4045 Project: Cassandra Issue Type: Bug Components: Core Reporter: Brandon Williams Assignee: Brandon Williams Fix For: 1.1.0 As the summary says, we should allow jobs to complete when some targets are unavailable. -- 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-4047) Bulk hinting
Bulk hinting Key: CASSANDRA-4047 URL: https://issues.apache.org/jira/browse/CASSANDRA-4047 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Brandon Williams Fix For: 1.2 With the introduction of the BulkOutputFormat, there may be cases where someone would like to tolerate node failures and have the job complete, but afterwards since we streamed they have to repair or rely on read repair. We don't currently have any way of hinting streams, but a node could take a snapshot before acknowledging the stream session, then remember to send the files in the snapshot to the unavailable nodes when they come back up. This isn't quite ideal since of course the node may have compacted these files, however it's much simpler than any sort of key tracking at this scale. -- 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-4038) Investigate improving the dynamic snitch with reservoir sampling
Investigate improving the dynamic snitch with reservoir sampling Key: CASSANDRA-4038 URL: https://issues.apache.org/jira/browse/CASSANDRA-4038 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Brandon Williams Assignee: Brandon Williams Fix For: 1.2 Dsnitch's UPDATES_PER_INTERVAL and WINDOW_SIZE are chosen somewhat arbitrarily. A better fit may be something similar to Metric's ExponentiallyDecayingSample, where more recent information is weighted heavier than past information, and reservoir sampling would also be an efficient way of keeping a statistically significant sample rather than refusing updates after UPDATES_PER_INTERVAL and only keeping WINDOW_SIZE amount. -- 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-4021) CFS.scrubDataDirectories tries to delete nonexistent orphans
CFS.scrubDataDirectories tries to delete nonexistent orphans
Key: CASSANDRA-4021
URL: https://issues.apache.org/jira/browse/CASSANDRA-4021
Project: Cassandra
Issue Type: Bug
Reporter: Brandon Williams
Priority: Minor
The check only looks for a missing data file, then deletes all other
components, however it's possible for the data file and another component to be
missing, causing an error:
{noformat}
WARN 17:19:28,765 Removing orphans for
/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-24492:
[Index.db, Filter.db, Digest.sha1, Statistics.db, Data.db]
ERROR 17:19:28,766 Exception encountered during startup
java.lang.AssertionError: attempted to delete non-existing file
system-HintsColumnFamily-hd-24492-Index.db
at
org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:49)
at
org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:44)
at
org.apache.cassandra.db.ColumnFamilyStore.scrubDataDirectories(ColumnFamilyStore.java:357)
at
org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:167)
at
org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:352)
at
org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:105)
java.lang.AssertionError: attempted to delete non-existing file
system-HintsColumnFamily-hd-24492-Index.db
at
org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:49)
at
org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:44)
at
org.apache.cassandra.db.ColumnFamilyStore.scrubDataDirectories(ColumnFamilyStore.java:357)
at
org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:167)
at
org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:352)
at
org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:105)
Exception encountered during startup: attempted to delete non-existing file
system-HintsColumnFamily-hd-24492-Index.db
{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-4022) Compaction of hints can get stuck in a loop
Compaction of hints can get stuck in a loop
---
Key: CASSANDRA-4022
URL: https://issues.apache.org/jira/browse/CASSANDRA-4022
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Brandon Williams
Assignee: Brandon Williams
Priority: Critical
Fix For: 1.1.0
Not exactly sure how I caused this as I was working on something else in trunk,
but:
{noformat}
INFO 17:41:35,682 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-339-Data.db')]
INFO 17:41:36,430 Compacted to
[/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-340-Data.db,].
4,637,160 to 4,637,160 (~100% of original) bytes
for 1 keys at 5.912220MB/s. Time: 748ms.
INFO 17:41:36,431 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-340-Data.db')]
INFO 17:41:37,238 Compacted to
[/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-341-Data.db,].
4,637,160 to 4,637,160 (~100% of original) bytes
for 1 keys at 5.479976MB/s. Time: 807ms.
INFO 17:41:37,239 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-341-Data.db')]
INFO 17:41:38,163 Compacted to
[/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-342-Data.db,].
4,637,160 to 4,637,160 (~100% of original) bytes
for 1 keys at 4.786083MB/s. Time: 924ms.
INFO 17:41:38,164 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-342-Data.db')]
INFO 17:41:39,014 GC for ParNew: 274 ms for 1 collections, 541261288 used; max
is 1024458752
INFO 17:41:39,151 Compacted to
[/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-343-Data.db,].
4,637,160 to 4,637,160 (~100% of original) bytes
for 1 keys at 4.485132MB/s. Time: 986ms.
INFO 17:41:39,151 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-343-Data.db')]
INFO 17:41:40,016 GC for ParNew: 308 ms for 1 collections, 585582200 used; max
is 1024458752
INFO 17:41:40,200 Compacted to
[/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-344-Data.db,].
4,637,160 to 4,637,160 (~100% of original) bytes
for 1 keys at 4.223821MB/s. Time: 1,047ms.
INFO 17:41:40,201 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-344-Data.db')]
INFO 17:41:41,017 GC for ParNew: 252 ms for 1 collections, 617877904 used; max
is 1024458752
INFO 17:41:41,178 Compacted to
[/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-345-Data.db,].
4,637,160 to 4,637,160 (~100% of original) bytes
for 1 keys at 4.526449MB/s. Time: 977ms.
INFO 17:41:41,179 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-345-Data.db')]
INFO 17:41:41,885 Compacted to
[/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-346-Data.db,].
4,637,160 to 4,637,160 (~100% of original) bytes
for 1 keys at 6.263938MB/s. Time: 706ms.
INFO 17:41:41,887 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-346-Data.db')]
INFO 17:41:42,617 Compacted to
[/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-347-Data.db,].
4,637,160 to 4,637,160 (~100% of original) bytes for 1 keys at 6.066311MB/s.
Time: 729ms.
INFO 17:41:42,618 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-347-Data.db')]
INFO 17:41:43,376 Compacted to
[/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-348-Data.db,].
4,637,160 to 4,637,160 (~100% of original) bytes for 1 keys at 5.834222MB/s.
Time: 758ms.
INFO 17:41:43,377 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-348-Data.db')]
INFO 17:41:44,307 Compacted to
[/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-349-Data.db,].
4,637,160 to 4,637,160 (~100% of original) bytes for 1 keys at 4.760323MB/s.
Time: 929ms.
INFO 17:41:44,308 Compacting
[SSTableReader(path='/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-349-Data.db')]
INFO 17:41:45,021 GC for ParNew: 245 ms for 1 collections, 731287832 used; max
is 1024458752
INFO 17:41:45,316 Compacted to
[/var/lib/cassandra/data/system/HintsColumnFamily/system-HintsColumnFamily-hd-350-Data.db,].
4,637,160 to 4,637,160 (~100% of original) bytes for 1 keys at 4.395965MB/s.
Time: 1,006ms.
INFO 17:41:45,316 Compacting
[jira] [Created] (CASSANDRA-4009) Increase usage of Metrics and flesh out o.a.c.metrics
Increase usage of Metrics and flesh out o.a.c.metrics - Key: CASSANDRA-4009 URL: https://issues.apache.org/jira/browse/CASSANDRA-4009 Project: Cassandra Issue Type: Improvement Reporter: Brandon Williams Assignee: Brandon Williams Fix For: 1.1.1 With CASSANDRA-3671 we have begun using the Metrics packages to expose stats in a new JMX structure, intended to be more user-friendly (for example, you don't need to know what a StorageProxy is or does.) This ticket serves as a parent for subtasks to finish fleshing out the rest of the enhanced metrics. -- 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-3991) Investigate importance of jsvc in debian packages
Investigate importance of jsvc in debian packages - Key: CASSANDRA-3991 URL: https://issues.apache.org/jira/browse/CASSANDRA-3991 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Brandon Williams Assignee: Brandon Williams Fix For: 1.1.1 jsvc seems to be buggy at best. For instance, if you set a small heap like 128M it seems to completely ignore this and use as much memory as it wants. I don't what this is buying us over launching /usr/bin/cassandra directly like the redhat scripts do, but I've seen multiple complaints about its memory usage. -- 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-3980) Cli should be able to define CompositeType comparators
Cli should be able to define CompositeType comparators -- Key: CASSANDRA-3980 URL: https://issues.apache.org/jira/browse/CASSANDRA-3980 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Brandon Williams Assignee: Pavel Yaskevich Fix For: 1.0.9 There is currently no way to define, for instance, CompositeType(UTF8Type,Int32Type) in a CF definition. -- 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-3972) HintedHandoff fails to deliver any hints
HintedHandoff fails to deliver any hints Key: CASSANDRA-3972 URL: https://issues.apache.org/jira/browse/CASSANDRA-3972 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.0 Reporter: Brandon Williams Assignee: Brandon Williams Priority: Blocker Fix For: 1.1.0 Summary says it all. Whether in a memtable or sstable, no hints are delivered. -- 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-3955) HintedHandoff won't compact a single sstable, resulting in repeated log messages
HintedHandoff won't compact a single sstable, resulting in repeated log messages Key: CASSANDRA-3955 URL: https://issues.apache.org/jira/browse/CASSANDRA-3955 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.7 Reporter: Brandon Williams Fix For: 1.0.9 First introduced by CASSANDRA-3554, and then mostly solved in CASSANDRA-3733, there is still one special case where the HH log message will repeat every 10 mins for 0 rows: when there have previously been hints delivered to the node, but now only a single sstable exists. Because the we refused to compact a single sstable, and it contains tombstones for the hints, the message repeats. -- 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-3936) Gossip should have a 'goodbye' command to indicate shutdown
Gossip should have a 'goodbye' command to indicate shutdown --- Key: CASSANDRA-3936 URL: https://issues.apache.org/jira/browse/CASSANDRA-3936 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Brandon Williams Assignee: Brandon Williams Fix For: 1.2 Cassandra is crash-only, however there are times when you _know_ you are taking the node down (rolling restarts, for instance) where it would be advantageous to instantly have the node marked down rather than wait on the FD. We could also improve the efficacy of the 'disablegossip' command this way as well. -- 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-3913) Incorrect InetAddress equality test
Incorrect InetAddress equality test --- Key: CASSANDRA-3913 URL: https://issues.apache.org/jira/browse/CASSANDRA-3913 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.6, 0.8.9 Reporter: Brandon Williams Assignee: Brandon Williams Priority: Trivial Fix For: 1.0.8 Attachments: 3913.txt CASSANDRA-3485 introduced some InetAddress checks using == instead of .equals. -- 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-3914) Remove py_stress
Remove py_stress Key: CASSANDRA-3914 URL: https://issues.apache.org/jira/browse/CASSANDRA-3914 Project: Cassandra Issue Type: Task Components: Tools Reporter: Brandon Williams Assignee: Brandon Williams Priority: Trivial Fix For: 1.1.0 I don't even know if this works anymore. Patch is 'git rm -rf tools/py_stress' -- 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-3909) Pig should handle wide rows
Pig should handle wide rows --- Key: CASSANDRA-3909 URL: https://issues.apache.org/jira/browse/CASSANDRA-3909 Project: Cassandra Issue Type: Bug Components: Hadoop Reporter: Brandon Williams Assignee: Brandon Williams Fix For: 1.1.0 Pig should be able to use the wide row support in CFIF. -- 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-3886) Pig can't store some types after loading them
Pig can't store some types after loading them
-
Key: CASSANDRA-3886
URL: https://issues.apache.org/jira/browse/CASSANDRA-3886
Project: Cassandra
Issue Type: Bug
Components: Hadoop
Affects Versions: 0.8.7
Reporter: Brandon Williams
Assignee: Brandon Williams
Fix For: 1.0.8
In CASSANDRA-2810, we removed the decompose methods in putNext instead relying
on objToBB, however it cannot sufficiently handle all types. For instance, if
longs are loaded and then an attempt to store them is made, this causes a cast
exception: java.io.IOException: java.io.IOException:
java.lang.ClassCastException: java.lang.Long cannot be cast to
org.apache.pig.data.DataByteArray Output must be (key, {(column,value)...}) for
ColumnFamily or (key, {supercolumn:{(column,value)...}...}) for
SuperColumnFamily
--
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-3883) CFIF WideRowIterator only returns batch size columns
CFIF WideRowIterator only returns batch size columns Key: CASSANDRA-3883 URL: https://issues.apache.org/jira/browse/CASSANDRA-3883 Project: Cassandra Issue Type: Bug Components: Hadoop Affects Versions: 1.1.0 Reporter: Brandon Williams Fix For: 1.1.0 Most evident with the word count, where there are 1250 'word1' items in two rows (1000 in one, 250 in another) and it counts 198 with the batch size set to 99. -- 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-3868) Remove or nullify replicate_on_write option
Remove or nullify replicate_on_write option --- Key: CASSANDRA-3868 URL: https://issues.apache.org/jira/browse/CASSANDRA-3868 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.8.0 Reporter: Brandon Williams Fix For: 1.1 My understanding from Sylvain is that setting this option to false is rather dangerous/stupid, and you should basically never do it. So 1.1 is a good time to get rid of it, or make it a no-op. -- 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-3847) Pig should throw a useful error when the destination CF doesn't exist
Pig should throw a useful error when the destination CF doesn't exist
-
Key: CASSANDRA-3847
URL: https://issues.apache.org/jira/browse/CASSANDRA-3847
Project: Cassandra
Issue Type: Bug
Components: Hadoop
Affects Versions: 0.7.0
Reporter: Brandon Williams
Assignee: Brandon Williams
Fix For: 1.0.8
When trying to store data to nonexistent CF, no good error is returned.
Instead you get a message like:
{noformat}
[main] ERROR org.apache.pig.tools.grunt.Grunt - ERROR 2042: Error in new
logical plan. Try -Dpig.usenewlogicalplan=false.
{noformat}
Which, if you follow its advice, will eventually lead you to an NPE in
initSchema.
--
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-3826) Pig cannot use output formats other than CFOF
Pig cannot use output formats other than CFOF - Key: CASSANDRA-3826 URL: https://issues.apache.org/jira/browse/CASSANDRA-3826 Project: Cassandra Issue Type: Bug Components: Hadoop Reporter: Brandon Williams Assignee: Brandon Williams Fix For: 1.0.8 Pig has ColumnFamilyOutputFormat hard coded. -- 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-3828) BulkOutputFormat shouldn't need flags to specify the output type
BulkOutputFormat shouldn't need flags to specify the output type Key: CASSANDRA-3828 URL: https://issues.apache.org/jira/browse/CASSANDRA-3828 Project: Cassandra Issue Type: Bug Components: Hadoop Reporter: Brandon Williams Assignee: Brandon Williams Fix For: 1.1 BOF currently requires the IS_SUPER boolean to be set to determine if the output CF is going to be a super or not, and would similarly use a flag to indicate counters (if there was support for that yet.) Instead, it should be able to introspect the mutations to determine what kind of columns to 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-3815) Alllow compression setting adjustment via JMX
Alllow compression setting adjustment via JMX - Key: CASSANDRA-3815 URL: https://issues.apache.org/jira/browse/CASSANDRA-3815 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Brandon Williams Assignee: Brandon Williams As the title says, let's allow enabling/disabling/setting chunk size via JMX. -- 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-3754) Add TTL and counter support to BulkOutputFormat
Add TTL and counter support to BulkOutputFormat --- Key: CASSANDRA-3754 URL: https://issues.apache.org/jira/browse/CASSANDRA-3754 Project: Cassandra Issue Type: Improvement Components: Hadoop Reporter: Brandon Williams Assignee: Brandon Williams Priority: Minor Fix For: 1.2 -- 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-3752) bulk loader no longer finds sstables
bulk loader no longer finds sstables
Key: CASSANDRA-3752
URL: https://issues.apache.org/jira/browse/CASSANDRA-3752
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1
Reporter: Brandon Williams
Fix For: 1.1
It looks like CASSANDRA-2749 broke it:
{noformat}
WARN 13:02:20,107 Invalid file 'Standard1' in data directory
/var/lib/cassandra/data/Keyspace1.
{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-3733) Once a host has been hinted to, log messages for it repeat every 10 mins even if no hints are delivered
Once a host has been hinted to, log messages for it repeat every 10 mins even
if no hints are delivered
---
Key: CASSANDRA-3733
URL: https://issues.apache.org/jira/browse/CASSANDRA-3733
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.7
Reporter: Brandon Williams
Priority: Minor
{noformat}
INFO 15:36:03,977 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:36:03,978 Finished hinted handoff of 0 rows to endpoint /10.179.111.137
INFO 15:46:31,248 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:46:31,249 Finished hinted handoff of 0 rows to endpoint /10.179.111.137
INFO 15:56:29,448 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 15:56:29,449 Finished hinted handoff of 0 rows to endpoint /10.179.111.137
INFO 16:06:09,949 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 16:06:09,950 Finished hinted handoff of 0 rows to endpoint /10.179.111.137
INFO 16:16:21,529 Started hinted handoff for token:
170141183460469231731687303715884105726 with IP: /10.179.111.137
INFO 16:16:21,530 Finished hinted handoff of 0 rows to endpoint /10.179.111.137
{noformat}
Introducing by CASSANDRA-3554. The problem is that until a compaction on hints
occurs, tombstones are present causing the isEmpty() check to be false.
--
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-3717) remove contrib/javautils
remove contrib/javautils Key: CASSANDRA-3717 URL: https://issues.apache.org/jira/browse/CASSANDRA-3717 Project: Cassandra Issue Type: Sub-task Reporter: Brandon Williams Assignee: Brandon Williams Fix For: 1.1 As far as I know only hector uses this and it doesn't really belong in our tree. Patch is 'rm -rf contrib/javautils' -- 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-3710) Add a configuration option to disable snapshots
Add a configuration option to disable snapshots --- Key: CASSANDRA-3710 URL: https://issues.apache.org/jira/browse/CASSANDRA-3710 Project: Cassandra Issue Type: New Feature Reporter: Brandon Williams Fix For: 1.0.8 Let me first say, I hate this idea. It gives cassandra the ability to permanently delete data at a large scale without any means of recovery. However, I've seen this requested multiple times, and it is in fact useful in some scenarios, such as when your application is using an embedded cassandra instance for testing and need to truncate, which without JNA will timeout more often than not. -- 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-3694) ClassCastException during hinted handoff
ClassCastException during hinted handoff
Key: CASSANDRA-3694
URL: https://issues.apache.org/jira/browse/CASSANDRA-3694
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1
Reporter: Brandon Williams
Fix For: 1.1
{noformat}
ERROR 08:51:00,200 Fatal exception in thread Thread[OptionalTasks:1,5,main]
java.lang.ClassCastException: org.apache.cassandra.dht.BigIntegerToken cannot
be cast to org.apache.cassandra.db.RowPosition
at
org.apache.cassandra.db.ColumnFamilyStore.getSequentialIterator(ColumnFamilyStore.java:1286)
at
org.apache.cassandra.db.ColumnFamilyStore.getRangeSlice(ColumnFamilyStore.java:1356)
at
org.apache.cassandra.db.HintedHandOffManager.scheduleAllDeliveries(HintedHandOffManager.java:351)
at
org.apache.cassandra.db.HintedHandOffManager.access$000(HintedHandOffManager.java:84)
at
org.apache.cassandra.db.HintedHandOffManager$1.run(HintedHandOffManager.java:119)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at
java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
{noformat}
--
This message is automatically generated by JIRA.
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-3695) Hibernating nodes that die never go away
Hibernating nodes that die never go away Key: CASSANDRA-3695 URL: https://issues.apache.org/jira/browse/CASSANDRA-3695 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.0 Reporter: Brandon Williams Assignee: Brandon Williams Title says it all. We should be able to monitor these via the gossip heartbeat like other nodes, but it's tricky since it's a dead state. -- 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-3651) Truncate shouldn't rethrow timeouts as UA
Truncate shouldn't rethrow timeouts as UA - Key: CASSANDRA-3651 URL: https://issues.apache.org/jira/browse/CASSANDRA-3651 Project: Cassandra Issue Type: Bug Components: Core Reporter: Brandon Williams Assignee: Brandon Williams Fix For: 1.0.7 Truncate is a very easy operation to timeout, but the timeouts rethrow as UnavailableException which is somewhat confusing. Instead it should throw TimedOutException. -- 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-3631) While sleeping for RING_DELAY, bootstrapping nodes do not show as joining in the ring (or at all)
While sleeping for RING_DELAY, bootstrapping nodes do not show as joining in the ring (or at all) - Key: CASSANDRA-3631 URL: https://issues.apache.org/jira/browse/CASSANDRA-3631 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.0 Reporter: Brandon Williams Assignee: Vijay Priority: Minor Fix For: 1.0.7 As the title says, the nodes do not show in the ring until they are actually in the token selection/streaming phase. This appears due to CASSANDRA-957, but now can be further exacerbated by longer sleep times for CASSANDRA-3629. -- 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-3629) Bootstrapping nodes don't ensure schema is ready before continuing
Bootstrapping nodes don't ensure schema is ready before continuing -- Key: CASSANDRA-3629 URL: https://issues.apache.org/jira/browse/CASSANDRA-3629 Project: Cassandra Issue Type: Bug Components: Core Reporter: Brandon Williams Assignee: Brandon Williams Fix For: 1.0.7 A bootstrapping node will assume that after it has slept for RING_DELAY it has all of the schema migrations and can continue the bootstrap process. However, with a large enough amount of migrations this is not sufficient and causes problems. -- 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-3602) Remove test/distributed
Remove test/distributed --- Key: CASSANDRA-3602 URL: https://issues.apache.org/jira/browse/CASSANDRA-3602 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Brandon Williams Priority: Trivial Fix For: 1.0.6, 1.1 Now that we've shifted focus to the new ccm-based distributed tests (https://github.com/riptano/cassandra-dtest) I think it's time to remove the now long-neglected distributed test cruft from our tree. -- 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-3600) Allow overriding RING_DELAY
Allow overriding RING_DELAY --- Key: CASSANDRA-3600 URL: https://issues.apache.org/jira/browse/CASSANDRA-3600 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Brandon Williams Assignee: Brandon Williams Fix For: 1.0.6 RING_DELAY is what is consuming the majority of the time in the dtests. Since these run on localhost, it's safe to reduce this to save lots of time. Also being able to change this may obviate the need for CASSANDRA-3120. -- 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-3561) Make incremental_backups setting mutable via JMX
Make incremental_backups setting mutable via JMX Key: CASSANDRA-3561 URL: https://issues.apache.org/jira/browse/CASSANDRA-3561 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Brandon Williams Fix For: 1.1 This would be more useful as in the schema as a CF-level setting, but for 1.1 let's at least make it setting it via JMX possible. -- 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-3563) Packaging should increase vm.max_map_count to accommodate leveled compaction
Packaging should increase vm.max_map_count to accommodate leveled compaction Key: CASSANDRA-3563 URL: https://issues.apache.org/jira/browse/CASSANDRA-3563 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.0 Reporter: Brandon Williams Fix For: 1.0.6 As the title says, leveled can create a lot of files and you can run into an IOError trying to mmap all of them. -- 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-3550) Relax phi threshold enforcement
Relax phi threshold enforcement --- Key: CASSANDRA-3550 URL: https://issues.apache.org/jira/browse/CASSANDRA-3550 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Brandon Williams Assignee: Brandon Williams Priority: Trivial Fix For: 1.0.6 Currently we clamp the phi threshold between 5 and 16. For distributed testing purposes, 5 slows things down. Instead let's allow values down to 1, but add a warning for anything less than 5. -- 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-3497) BloomFilter FP ratio should be configurable or size-restricted some other way
BloomFilter FP ratio should be configurable or size-restricted some other way - Key: CASSANDRA-3497 URL: https://issues.apache.org/jira/browse/CASSANDRA-3497 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Brandon Williams When you have a live dc and purely analytical dc, in many situations you can have less nodes on the analytical side, but end up getting restricted by having the BloomFilters in-memory, even though so you have absolutely no use for them. It would be nice if you could reduce this memory requirement by tuning the desired FP ratio, or even just disabling them altogether. -- 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-3489) EncryptionOptions should be instantiated
EncryptionOptions should be instantiated Key: CASSANDRA-3489 URL: https://issues.apache.org/jira/browse/CASSANDRA-3489 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.1 Reporter: Brandon Williams Assignee: Brandon Williams Priority: Minor Fix For: 1.0.4 As the title says, otherwise you get an NPE when the options are missing from the yaml. It's included in my second patch on CASSANDRA-3045 and is a one line fix. -- 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-3485) Gossiper.addSavedEndpoint should never add itself
Gossiper.addSavedEndpoint should never add itself - Key: CASSANDRA-3485 URL: https://issues.apache.org/jira/browse/CASSANDRA-3485 Project: Cassandra Issue Type: Bug Components: Core Reporter: Brandon Williams Assignee: Brandon Williams Fix For: 0.8.8 Somehow, people are running into a situation where nodes are adding themselves to the persisted ring cache. Since SS is initialized after the Gossiper and calls addSavedEndpoint on it, which inits the nodes with a generation of zero, this ends up nodes using a generation of zero and thus never being marked as alive. -- 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-3475) LoadBroadcaster never removes endpoints
LoadBroadcaster never removes endpoints --- Key: CASSANDRA-3475 URL: https://issues.apache.org/jira/browse/CASSANDRA-3475 Project: Cassandra Issue Type: Bug Components: Core Reporter: Brandon Williams Assignee: Brandon Williams Priority: Trivial As the title says. -- 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-3452) Create an 'infinite bootstrap' mode for sampling live traffic
Create an 'infinite bootstrap' mode for sampling live traffic - Key: CASSANDRA-3452 URL: https://issues.apache.org/jira/browse/CASSANDRA-3452 Project: Cassandra Issue Type: New Feature Reporter: Brandon Williams Assignee: Brandon Williams You may want to, for example, test a new compaction strategy with live traffic to see how it will fare. In this mode, the node would follow the bootstrap procedure as normal, but never fully join the ring. -- 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-3403) describe_ring topology information is wrong/incomplete
describe_ring topology information is wrong/incomplete -- Key: CASSANDRA-3403 URL: https://issues.apache.org/jira/browse/CASSANDRA-3403 Project: Cassandra Issue Type: Bug Components: Core Reporter: Brandon Williams Fix For: 1.0.1 In CASSANDRA-2882, topology information was added to describe_ring, however it asks the gossiper for the DC information, and the gossiper can only have this with a gossip-enabled snitch, which currently means the Ec2Snitch. Instead, it should be asking the snitch for the DC for each endpoint. Also, the port information should just be removed: whatever port the client has connected to in order to call describe_ring is the right port to use for all endpoints. -- 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-3395) Quorum returns incorrect results during hinted handoff
Quorum returns incorrect results during hinted handoff -- Key: CASSANDRA-3395 URL: https://issues.apache.org/jira/browse/CASSANDRA-3395 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.0 Reporter: Brandon Williams In a 3 node cluster with RF=3 and using a single coordinator, if monotonically increasing columns are inserted into a row and the latest one sliced (both at QUORUM) during HH replay occasionally this column will not be seen. -- 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-3378) Allow configuration of storage protocol socket buffer
Allow configuration of storage protocol socket buffer - Key: CASSANDRA-3378 URL: https://issues.apache.org/jira/browse/CASSANDRA-3378 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Brandon Williams Priority: Minor Fix For: 1.0.1 Similar to rpc_[send,recv]_buff_size_in_bytes, we should expose this for high latency connections. -- 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-3355) Race trying to register CFS MBean
Race trying to register CFS MBean
-
Key: CASSANDRA-3355
URL: https://issues.apache.org/jira/browse/CASSANDRA-3355
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Brandon Williams
Priority: Minor
I heard reports of this multiple times, here's an example:
{noformat}
INFO 16:08:23,672 reading saved cache
/var/lib/cassandra/saved_caches/spider-InterfaceDailyCompressed-KeyCache
INFO 16:08:23,995 Opening
/var/lib/cassandra/data/spider/InterfaceDailyCompressed-g-63
INFO 16:08:24,253 Opening
/var/lib/cassandra/data/spider/InterfaceDailyCompressed-g-75
INFO 16:08:24,422 Opening
/var/lib/cassandra/data/spider/InterfaceDailyCompressed-g-113
INFO 16:08:24,443 Opening
/var/lib/cassandra/data/spider/InterfaceDailyCompressed-g-36
INFO 16:08:24,756 Opening
/var/lib/cassandra/data/spider/InterfaceDailyCompressed-g-102
INFO 16:08:24,789 Opening
/var/lib/cassandra/data/spider/InterfaceDailyCompressed-g-58
ERROR 16:08:25,105 Exception encountered during startup.
java.lang.RuntimeException: javax.management.InstanceAlreadyExistsException:
org.apache.cassandra.db:type=ColumnFamilies,keyspace=spider,columnfamily=InterfaceDailyCompressed
at
org.apache.cassandra.db.ColumnFamilyStore.init(ColumnFamilyStore.java:303)
at
org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:465)
at
org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:435)
at org.apache.cassandra.db.Table.initCf(Table.java:369)
at org.apache.cassandra.db.Table.init(Table.java:306)
at org.apache.cassandra.db.Table.open(Table.java:111)
at
org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:187)
at
org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:341)
at
org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:97)
Caused by: javax.management.InstanceAlreadyExistsException:
org.apache.cassandra.db:type=ColumnFamilies,keyspace=spider,columnfamily=InterfaceDailyCompressed
at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:453)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.internal_addObject(DefaultMBeanServerInterceptor.java:1484)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:963)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:917)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:312)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:482)
at
org.apache.cassandra.db.ColumnFamilyStore.init(ColumnFamilyStore.java:299)
... 8 more
Exception encountered during startup.
java.lang.RuntimeException: javax.management.InstanceAlreadyExistsException:
org.apache.cassandra.db:type=ColumnFamilies,keyspace=spider,columnfamily=InterfaceDailyCompressed
at
org.apache.cassandra.db.ColumnFamilyStore.init(ColumnFamilyStore.java:303)
at
org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:465)
at
org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:435)
at org.apache.cassandra.db.Table.initCf(Table.java:369)
at org.apache.cassandra.db.Table.init(Table.java:306)
at org.apache.cassandra.db.Table.open(Table.java:111)
at
org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:187)
at
org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:341)
at
org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:97)
Caused by: javax.management.InstanceAlreadyExistsException:
org.apache.cassandra.db:type=ColumnFamilies,keyspace=spider,columnfamily=InterfaceDailyCompressed
at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:453)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.internal_addObject(DefaultMBeanServerInterceptor.java:1484)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:963)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:917)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:312)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:482)
at
org.apache.cassandra.db.ColumnFamilyStore.init(ColumnFamilyStore.java:299)
... 8 more
{noformat}
This wouldn't be too big of a deal, except it's actually
[jira] [Created] (CASSANDRA-3346) HsHa broken in trunk
HsHa broken in trunk
Key: CASSANDRA-3346
URL: https://issues.apache.org/jira/browse/CASSANDRA-3346
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Brandon Williams
{noformat}
ERROR 09:10:21,781 Exception encountered during startup
java.lang.IllegalArgumentException
at
java.util.concurrent.ThreadPoolExecutor.init(ThreadPoolExecutor.java:589)
at
java.util.concurrent.ThreadPoolExecutor.init(ThreadPoolExecutor.java:514)
at
org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.init(DebuggableThreadPoolExecutor.java:90)
at
org.apache.cassandra.concurrent.JMXEnabledThreadPoolExecutor.init(JMXEnabledThreadPoolExecutor.java:76)
at
org.apache.cassandra.thrift.CassandraDaemon$ThriftServer.init(CassandraDaemon.java:192)
at
org.apache.cassandra.thrift.CassandraDaemon.startServer(CassandraDaemon.java:75)
at
org.apache.cassandra.service.AbstractCassandraDaemon.startRPCServer(AbstractCassandraDaemon.java:281)
at
org.apache.cassandra.service.AbstractCassandraDaemon.start(AbstractCassandraDaemon.java:253)
at
org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:350)
at
org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:106)
{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-3337) Create a 'killtoken' command
Create a 'killtoken' command Key: CASSANDRA-3337 URL: https://issues.apache.org/jira/browse/CASSANDRA-3337 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Brandon Williams Assignee: Brandon Williams Fix For: 1.0.1 Sometimes you just want a token gone: no re-replication, nothing, just excise it. -- 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-3335) ThreadPoolExecutor creates threads a non-daemon and will block on shutdown by default
ThreadPoolExecutor creates threads a non-daemon and will block on shutdown by default - Key: CASSANDRA-3335 URL: https://issues.apache.org/jira/browse/CASSANDRA-3335 Project: Cassandra Issue Type: Bug Components: Core Reporter: Brandon Williams Priority: Minor This is most obviously visible in OptionalTasks which should not block shutdown, but often does. -- 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-3308) Add compaction_thread_priority back
Add compaction_thread_priority back --- Key: CASSANDRA-3308 URL: https://issues.apache.org/jira/browse/CASSANDRA-3308 Project: Cassandra Issue Type: Bug Reporter: Brandon Williams Fix For: 1.0.0 In CASSANDRA-3104, this was removed with the following reasoning: bq. compaction_throughput_mb_per_sec is a more effective throttle on compaction. This turns out to be false in the majority of deployments. In many (if not most) situations, compaction is actually CPU bound, not IO bound, so multithreaded compaction is generally helpful, but the priority needs to be lowered in order to prevent it from stealing CPU used for reads/writes. Compaction is always CPU bound on both real hardware (sw raid0 with two SATA disks) and on a rackspace cloud server (though my understanding is they are back by a raid10 array underneath) however I suspect even a single drive is fast enough to handle the ~20MB/s that compaction is currently performing when unthrottled. -- 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-3273) FailureDetector can take a very long time to mark a host down
FailureDetector can take a very long time to mark a host down - Key: CASSANDRA-3273 URL: https://issues.apache.org/jira/browse/CASSANDRA-3273 Project: Cassandra Issue Type: Bug Components: API Reporter: Brandon Williams Assignee: Brandon Williams There are two ways to trigger this: * Bring a node up very briefly in a mixed-version cluster and then terminate it * Bring a node up, terminate it for a very long time, then bring it back up and take it down again In the first case, what can happen is a very short interval arrival time is recorded by the versioning logic which requires reconnecting and can happen very quickly. This can easily be solved by rejecting any intervals within a reasonable bound, for instance the gossiper interval. The second instance is harder to solve, because what is happening is that an extremely large interval is recorded, which the time the node was left dead the first time. This throws off the mean of the intervals and causes it to take a much longer time to mark it down the second time. -- 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
