[jira] [Commented] (CASSANDRA-3664) [patch] fix some obvious javadoc issues generated via ant javadoc
[ https://issues.apache.org/jira/browse/CASSANDRA-3664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13175895#comment-13175895 ] Hudson commented on CASSANDRA-3664: --- Integrated in Cassandra #1269 (See [https://builds.apache.org/job/Cassandra/1269/]) fix javadoc problems patch by Dave Brosius; reviewed by jbellis for CASSANDRA-3664 jbellis : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1224680 Files : * /cassandra/trunk/src/java/org/apache/cassandra/db/RowIteratorFactory.java * /cassandra/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java * /cassandra/trunk/src/java/org/apache/cassandra/locator/AbstractReplicationStrategy.java * /cassandra/trunk/src/java/org/apache/cassandra/scheduler/IRequestScheduler.java * /cassandra/trunk/src/java/org/apache/cassandra/service/CassandraDaemon.java * /cassandra/trunk/src/java/org/apache/cassandra/service/StorageService.java * /cassandra/trunk/src/java/org/apache/cassandra/utils/BloomFilterSerializer.java [patch] fix some obvious javadoc issues generated via ant javadoc - Key: CASSANDRA-3664 URL: https://issues.apache.org/jira/browse/CASSANDRA-3664 Project: Cassandra Issue Type: Improvement Affects Versions: 1.0.6 Reporter: Dave Brosius Assignee: Dave Brosius Priority: Trivial Fix For: 1.1 Attachments: jd.diff, jd2.diff -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3651) Truncate shouldn't rethrow timeouts as UA
[ https://issues.apache.org/jira/browse/CASSANDRA-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13174916#comment-13174916 ] Hudson commented on CASSANDRA-3651: --- Integrated in Cassandra #1264 (See [https://builds.apache.org/job/Cassandra/1264/]) Truncate throws TOE on timeout instead of UA. Patch by brandonwilliams, reviewed by jbellis for CASSANDRA-3651 brandonwilliams : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1222340 Files : * /cassandra/trunk/interface/cassandra.thrift * /cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java * /cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Constants.java * /cassandra/trunk/src/java/org/apache/cassandra/thrift/CassandraServer.java 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.1 Attachments: 0001-Update-thrift-definition.txt, 0002-truncate-throws-TOE-on-timeout.txt 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] [Commented] (CASSANDRA-3661) Re-introduce timeout debug messages in CassandraServer
[
https://issues.apache.org/jira/browse/CASSANDRA-3661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13175004#comment-13175004
]
Hudson commented on CASSANDRA-3661:
---
Integrated in Cassandra-0.8 #421 (See
[https://builds.apache.org/job/Cassandra-0.8/421/])
Re-introduce timeout debug messages in CassandraServer.
Patch by brandonwilliams, reviewed by jbellis for CASSANDRA-3661
brandonwilliams :
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1222372
Files :
*
/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/thrift/CassandraServer.java
Re-introduce timeout debug messages in CassandraServer
--
Key: CASSANDRA-3661
URL: https://issues.apache.org/jira/browse/CASSANDRA-3661
Project: Cassandra
Issue Type: Improvement
Components: API
Affects Versions: 0.8.0
Reporter: Jonathan Ellis
Assignee: Brandon Williams
Priority: Trivial
Labels: thrift
Fix For: 0.8.10, 1.0.7
Attachments: 3661.txt
In 0.7 we log at debug when returning TOE back to the client:
{code}
. catch (TimeoutException e)
{
logger.debug(... timed out);
throw new TimedOutException();
}
{code}
This is primarily useful when reading through debug logs to make it obvious
when StorageProxy gave up waiting and cleared its callbacks.
At some point this got removed from 0.8+. (Or possibly never got correctly
merged upwards.) Let's fix this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3452) Create an 'infinite bootstrap' mode for sampling live traffic
[ https://issues.apache.org/jira/browse/CASSANDRA-3452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13175202#comment-13175202 ] Hudson commented on CASSANDRA-3452: --- Integrated in Cassandra #1266 (See [https://builds.apache.org/job/Cassandra/1266/]) Add 'write survey' mode that bootstraps but does not join. Patch by brandonwilliams, reviewed by jbellis for CASSANDRA-3452 brandonwilliams : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1222425 Files : * /cassandra/trunk/src/java/org/apache/cassandra/service/StorageService.java 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 Fix For: 1.1 Attachments: 0001-Ability-to-set-compaction-strategy-via-mbean.txt, 0002-Allow-survey-only-mode-after-bootstrapping.txt 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] [Commented] (CASSANDRA-3658) Fix smallish problems find by FindBugs
[ https://issues.apache.org/jira/browse/CASSANDRA-3658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13175203#comment-13175203 ] Hudson commented on CASSANDRA-3658: --- Integrated in Cassandra #1266 (See [https://builds.apache.org/job/Cassandra/1266/]) Fix minor issues reported by FindBugs patch by slebresne; reviewed by jbellis for CASSANDRA-3658 slebresne : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1222476 Files : * /cassandra/trunk/CHANGES.txt * /cassandra/trunk/src/java/org/apache/cassandra/cli/CliClient.java * /cassandra/trunk/src/java/org/apache/cassandra/config/ReplicationStrategy.java * /cassandra/trunk/src/java/org/apache/cassandra/db/ArrayBackedSortedColumns.java * /cassandra/trunk/src/java/org/apache/cassandra/db/ColumnFamily.java * /cassandra/trunk/src/java/org/apache/cassandra/db/ExpiringColumn.java * /cassandra/trunk/src/java/org/apache/cassandra/db/RowIteratorFactory.java * /cassandra/trunk/src/java/org/apache/cassandra/db/compaction/SizeTieredCompactionStrategy.java * /cassandra/trunk/src/java/org/apache/cassandra/db/filter/QueryFilter.java * /cassandra/trunk/src/java/org/apache/cassandra/db/marshal/AbstractType.java * /cassandra/trunk/src/java/org/apache/cassandra/db/marshal/DynamicCompositeType.java * /cassandra/trunk/src/java/org/apache/cassandra/db/marshal/ReversedType.java * /cassandra/trunk/src/java/org/apache/cassandra/dht/LocalToken.java * /cassandra/trunk/src/java/org/apache/cassandra/dht/Token.java * /cassandra/trunk/src/java/org/apache/cassandra/io/compress/CompressionMetadata.java * /cassandra/trunk/src/java/org/apache/cassandra/io/sstable/SSTableLoader.java * /cassandra/trunk/src/java/org/apache/cassandra/locator/PropertyFileSnitch.java * /cassandra/trunk/src/java/org/apache/cassandra/net/ProtocolHeader.java * /cassandra/trunk/src/java/org/apache/cassandra/service/AntiEntropyService.java * /cassandra/trunk/src/java/org/apache/cassandra/streaming/FileStreamTask.java * /cassandra/trunk/src/java/org/apache/cassandra/utils/EstimatedHistogram.java * /cassandra/trunk/src/java/org/apache/cassandra/utils/FBUtilities.java * /cassandra/trunk/src/java/org/apache/cassandra/utils/NodeId.java Fix smallish problems find by FindBugs -- Key: CASSANDRA-3658 URL: https://issues.apache.org/jira/browse/CASSANDRA-3658 Project: Cassandra Issue Type: Bug Components: Core Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Labels: fingbugs Fix For: 1.1 Attachments: 0001-Respect-Future-semantic.patch, 0002-Avoid-race-when-reloading-snitch-file.patch, 0003-use-static-inner-class-when-possible.patch, 0004-Remove-dead-code.patch, 0005-Protect-against-signed-byte-extension.patch, 0006-Add-hashCode-method-when-equals-is-overriden.patch, 0007-Inverse-argument-of-compare-instead-of-negating-to-a.patch, 0008-stop-pretending-Token-is-Serializable-LocalToken-is-.patch, 0009-remove-useless-assert-that-is-always-true.patch, 0010-Add-equals-and-hashCode-to-Expiring-column.patch I've just run (the newly released) FindBugs 2 out of curiosity. Attaching a number of patches related to issue raised by it. There is nothing major at all so all patches are against trunk. I've tried keep each issue to it's own patch with a self describing title. It far from covers all FindBugs alerts, but it's a picky tool so I've tried to address only what felt at least vaguely useful. Those are still mostly nits (only patch 2 is probably an actual bug). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3656) GC can take 0 ms
[ https://issues.apache.org/jira/browse/CASSANDRA-3656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13175211#comment-13175211 ] Hudson commented on CASSANDRA-3656: --- Integrated in Cassandra-0.8 #423 (See [https://builds.apache.org/job/Cassandra-0.8/423/]) avoid logging (harmless) exception when GC takes 1ms patch by jbellis; reviewed by brandonwilliams for CASSANDRA-3656 jbellis : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1222440 Files : * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/GCInspector.java GC can take 0 ms Key: CASSANDRA-3656 URL: https://issues.apache.org/jira/browse/CASSANDRA-3656 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.9, 0.8.7 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Trivial Fix For: 0.8.10, 1.0.7 Attachments: 3656.txt -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3619) Use a separate writer thread for the SSTableSimpleUnsortedWriter
[ https://issues.apache.org/jira/browse/CASSANDRA-3619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13172172#comment-13172172 ] Hudson commented on CASSANDRA-3619: --- Integrated in Cassandra #1259 (See [https://builds.apache.org/job/Cassandra/1259/]) Use separate writer thread in SSTableSimpleUnsortedWriter patch by slebresne; reviewed by yukim for CASSANDRA-3619 slebresne : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1220662 Files : * /cassandra/trunk/CHANGES.txt * /cassandra/trunk/src/java/org/apache/cassandra/io/sstable/SSTableSimpleUnsortedWriter.java Use a separate writer thread for the SSTableSimpleUnsortedWriter Key: CASSANDRA-3619 URL: https://issues.apache.org/jira/browse/CASSANDRA-3619 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 0.8.1 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.1 Attachments: 0001-Add-separate-writer-thread.patch Currently SSTableSimpleUnsortedWriter doesn't use any threading. This means that the thread using it is blocked while the buffered data is written on disk and that nothing is written on disk while data is added. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3632) using an ant builder in Eclipse is painful
[
https://issues.apache.org/jira/browse/CASSANDRA-3632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13172422#comment-13172422
]
Hudson commented on CASSANDRA-3632:
---
Integrated in Cassandra #1260 (See
[https://builds.apache.org/job/Cassandra/1260/])
remove ant builder; restore java builder
Patch by eevans; reviewed by Rick Shaw for CASSANDRA-3632
eevans : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1220838
Files :
* /cassandra/trunk/build.xml
using an ant builder in Eclipse is painful
--
Key: CASSANDRA-3632
URL: https://issues.apache.org/jira/browse/CASSANDRA-3632
Project: Cassandra
Issue Type: Bug
Components: Packaging, Tools
Affects Versions: 1.0.6
Reporter: Eric Evans
Assignee: Eric Evans
Priority: Minor
Attachments:
v1-0001-CASSANDRA-3632-remove-ant-builder-restore-java-builder.txt
The {{generate-eclipse-files}} target creates project files that use an Ant
builder. Besides being painfully slow (I've had the runs stack up behind
frequent saves), many of Eclipses errors and warnings do not show unless an
internal builder is used.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2475) Prepared statements
[ https://issues.apache.org/jira/browse/CASSANDRA-2475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13172423#comment-13172423 ] Hudson commented on CASSANDRA-2475: --- Integrated in Cassandra #1260 (See [https://builds.apache.org/job/Cassandra/1260/]) clean up Term ctors Patch by eevans; reviewed by Rick Shaw for CASSANDRA-2475 index bind markers using parser Patch by eevans; reviewed by Rick Shaw for CASSANDRA-2475 properly report number of markers in a statement Patch by eevans; reviewed by Rick Shaw for CASSANDRA-2475 eevans : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1220843 Files : * /cassandra/trunk/src/java/org/apache/cassandra/cql/Term.java eevans : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1220840 Files : * /cassandra/trunk/src/java/org/apache/cassandra/cql/CQLStatement.java * /cassandra/trunk/src/java/org/apache/cassandra/cql/Cql.g * /cassandra/trunk/src/java/org/apache/cassandra/cql/QueryProcessor.java * /cassandra/trunk/src/java/org/apache/cassandra/cql/Term.java eevans : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1220839 Files : * /cassandra/trunk/src/java/org/apache/cassandra/cql/QueryProcessor.java Prepared statements --- Key: CASSANDRA-2475 URL: https://issues.apache.org/jira/browse/CASSANDRA-2475 Project: Cassandra Issue Type: New Feature Components: API, Core Affects Versions: 1.0.5 Reporter: Eric Evans Assignee: Rick Shaw Priority: Minor Labels: cql Fix For: 1.1 Attachments: 2475-v1.patch, 2475-v2.patch, 2475-v3.1.patch, 2475-v3.2-Thrift.patch, v1-0001-CASSANDRA-2475-prepared-statement-patch.txt, v1-0002-regenerated-thrift-java.txt, v10-0001-CASSANDRA-2475-properly-report-number-of-markers-in-a-.txt, v10-0002-index-bind-markers-using-parser.txt, v10-0003-clean-up-Term-ctors.txt, v2-0001-CASSANDRA-2475-rickshaw-2475-v3.1.patch.txt, v2-0002-rickshaw-2475-v3.2-Thrift.patch-w-changes.txt, v2-0003-eevans-increment-thrift-version-by-1-not-3.txt, v2-0004-eevans-misc-cleanups.txt, v2-0005-eevans-refactor-for-better-encapsulation-of-prepare.txt, v2-0006-eevans-log-queries-at-TRACE.txt, v2-0007-use-an-LRU-map-for-storage-of-prepared-statements.txt -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3327) Support TimeUUID in CassandraStorage
[
https://issues.apache.org/jira/browse/CASSANDRA-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13172654#comment-13172654
]
Hudson commented on CASSANDRA-3327:
---
Integrated in Cassandra-0.8 #420 (See
[https://builds.apache.org/job/Cassandra-0.8/420/])
TimeUUID support in CassandraStorage.
Patch by brandonwilliams, reviewed by Rick Branson for CASSANDRA-3327
brandonwilliams :
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1220926
Files :
*
/cassandra/branches/cassandra-0.8/contrib/pig/src/java/org/apache/cassandra/hadoop/pig/CassandraStorage.java
Support TimeUUID in CassandraStorage
Key: CASSANDRA-3327
URL: https://issues.apache.org/jira/browse/CASSANDRA-3327
Project: Cassandra
Issue Type: Bug
Components: Contrib
Affects Versions: 0.8.7
Environment: Cassandra 0.8.6 Build #348 (CASSANDRA-2777 +
CASSANDRA-2810)
Reporter: Manuel Kreutz
Assignee: Brandon Williams
Labels: pig
Fix For: 0.8.10, 1.0.7
Attachments: 3327-v2.txt, 3327.txt
Cassandra CLI:
{code}
grunt raw = LOAD 'cassandra://TEST/CF'
USING CassandraStorage()
AS (
key:chararray,
columns:bag {
column:tuple(
name,
value
)
});
grunt describe raw;
raw: {key: chararray,columns: {(name: bytearray,value: bytearray)}}
log_test =
FOREACH raw
GENERATE
(CHARARRAY) key,
flatten(columns);
grunt DUMP log_test;
{code}
Returns:
{code}
org.apache.pig.impl.logicalLayer.FrontendException: ERROR 1066: Unable to
open iterator for alias log_test. Backend error : Unexpected data type
java.util.UUID found in stream. Note only standard Pig type is supported when
you output from UDF/LoadFunc
at org.apache.pig.PigServer.openIterator(PigServer.java:890)
at
org.apache.pig.tools.grunt.GruntParser.processDump(GruntParser.java:655)
at
org.apache.pig.tools.pigscript.parser.PigScriptParser.parse(PigScriptParser.java:303)
at
org.apache.pig.tools.grunt.GruntParser.parseStopOnError(GruntParser.java:188)
at
org.apache.pig.tools.grunt.GruntParser.parseStopOnError(GruntParser.java:164)
at org.apache.pig.tools.grunt.Grunt.run(Grunt.java:67)
at org.apache.pig.Main.run(Main.java:487)
at org.apache.pig.Main.main(Main.java:108)
Caused by: java.lang.RuntimeException: Unexpected data type java.util.UUID
found in stream. Note only standard Pig type is supported when you output
from UDF/LoadFunc
at
org.apache.pig.data.BinInterSedes.writeDatum(BinInterSedes.java:478)
at
org.apache.pig.data.BinInterSedes.writeTuple(BinInterSedes.java:542)
at
org.apache.pig.data.BinInterSedes.writeDatum(BinInterSedes.java:357)
at
org.apache.pig.impl.io.InterRecordWriter.write(InterRecordWriter.java:73)
at org.apache.pig.impl.io.InterStorage.putNext(InterStorage.java:87)
at
org.apache.pig.backend.hadoop.executionengine.mapReduceLayer.PigOutputFormat$PigRecordWriter.write(PigOutputFormat.java:138)
at
org.apache.pig.backend.hadoop.executionengine.mapReduceLayer.PigOutputFormat$PigRecordWriter.write(PigOutputFormat.java:97)
at
org.apache.hadoop.mapred.MapTask$NewDirectOutputCollector.write(MapTask.java:498)
at
org.apache.hadoop.mapreduce.TaskInputOutputContext.write(TaskInputOutputContext.java:80)
at
org.apache.pig.backend.hadoop.executionengine.mapReduceLayer.PigMapOnly$Map.collect(PigMapOnly.java:48)
at
org.apache.pig.backend.hadoop.executionengine.mapReduceLayer.PigMapBase.runPipeline(PigMapBase.java:263)
at
org.apache.pig.backend.hadoop.executionengine.mapReduceLayer.PigMapBase.map(PigMapBase.java:256)
at
org.apache.pig.backend.hadoop.executionengine.mapReduceLayer.PigMapBase.map(PigMapBase.java:58)
at org.apache.hadoop.mapreduce.Mapper.run(Mapper.java:144)
at org.apache.hadoop.mapred.MapTask.runNewMapper(MapTask.java:621)
at org.apache.hadoop.mapred.MapTask.run(MapTask.java:305)
{code}
According to driftx on IRC the setTupleValue function in CassandraStorage
needs to handle the uuid case and cast it to a DataByteArray.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2475) Prepared statements
[ https://issues.apache.org/jira/browse/CASSANDRA-2475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13170360#comment-13170360 ] Hudson commented on CASSANDRA-2475: --- Integrated in Cassandra #1257 (See [https://builds.apache.org/job/Cassandra/1257/]) bump maximum cached prepared statements to 10,000 (from 50) (and fix Map so that it is actually LRU) Patch by evans for CASSANDRA-2475 eevans : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1214803 Files : * /cassandra/trunk/src/java/org/apache/cassandra/service/ClientState.java Prepared statements --- Key: CASSANDRA-2475 URL: https://issues.apache.org/jira/browse/CASSANDRA-2475 Project: Cassandra Issue Type: New Feature Components: API, Core Affects Versions: 1.0.5 Reporter: Eric Evans Assignee: Rick Shaw Priority: Minor Labels: cql Fix For: 1.1 Attachments: 2475-v1.patch, 2475-v2.patch, 2475-v3.1.patch, 2475-v3.2-Thrift.patch, v1-0001-CASSANDRA-2475-prepared-statement-patch.txt, v1-0002-regenerated-thrift-java.txt, v2-0001-CASSANDRA-2475-rickshaw-2475-v3.1.patch.txt, v2-0002-rickshaw-2475-v3.2-Thrift.patch-w-changes.txt, v2-0003-eevans-increment-thrift-version-by-1-not-3.txt, v2-0004-eevans-misc-cleanups.txt, v2-0005-eevans-refactor-for-better-encapsulation-of-prepare.txt, v2-0006-eevans-log-queries-at-TRACE.txt, v2-0007-use-an-LRU-map-for-storage-of-prepared-statements.txt -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3626) Nodes can get stuck in UP state forever, despite being DOWN
[ https://issues.apache.org/jira/browse/CASSANDRA-3626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13170535#comment-13170535 ] Hudson commented on CASSANDRA-3626: --- Integrated in Cassandra-0.8 #419 (See [https://builds.apache.org/job/Cassandra-0.8/419/]) Prevent new nodes from thinking down nodes are up forever. Patch by brandonwilliams, reviewed by Peter Schuller for CASSANDRA-3626 brandonwilliams : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1214916 Files : * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/gms/Gossiper.java Nodes can get stuck in UP state forever, despite being DOWN --- Key: CASSANDRA-3626 URL: https://issues.apache.org/jira/browse/CASSANDRA-3626 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.8, 1.0.5 Reporter: Peter Schuller Assignee: Brandon Williams Fix For: 0.8.10, 1.0.7 Attachments: 3626.txt This is a proposed phrasing for an upstream ticket named Newly discovered nodes that are down get stuck in UP state forever (will edit w/ feedback until done): We have a observed a problem with gossip which, when you are bootstrapping a new node (or replacing using the replace_token support), any node in the cluster which is Down at the time the node is started, will be assumed to be Up and then *never ever* flapped back to Down until you restart the node. This has at least two implications to replacing or bootstrapping new nodes when there are nodes down in the ring: * If the new node happens to select a node listed as (UP but in reality is DOWN) as a stream source, streaming will sit there hanging forever. * If that doesn't happen (by picking another host), it will instead finish bootstrapping correctly, and begin servicing requests all the while thinking DOWN nodes are UP, and thus routing requests to them, generating timeouts. The way to get out of this is to restart the node(s) that you bootstrapped. I have tested and confirmed the symptom (that the bootstrapped node things other nodes are Up) using a fairly recent 1.0. The main debugging effort happened on 0.8 however, so all details below refer to 0.8 but are probably similar in 1.0. Steps to reproduce: * Bring up a cluster of = 3 nodes. *Ensure RF is N*, so that the cluster is operative with one node removed. * Pick two random nodes A, and B. Shut them *both* off. * Wait for everyone to realize they are both off (for good measure). * Now, take node A and nuke it's data directories and re-start it, such that it comes up w/ normal bootstrap (or use replace_token; didn't test that but should not affect it). * Watch how node A starts up, all the while believing node B is down, even though all other nodes in the cluster agree that B is down and B is in fact still turned off. The mechanism by which it initially goes into Up state is that the node receives a gossip response from any other node in the cluster, and GossipDigestAck2VerbHandler.doVerb() calls Gossiper.applyStateLocally(). Gossiper.applyStateLocally() doesn't have any local endpoint state for the cluster, so the else statement at the end (it's a new node) gets triggered and handleMajorStateChange() is called. handleMajorStateChange() always calls markAlive(), unless the state is a dead state (but dead here does not mean not up, but refers to joining/hibernate etc). So at this point the node is up in the mind of the node you just bootstrapped. Now, in each gossip round doStatusCheck() is called, which iterates over all nodes (including the one falsly Up) and among other things, calls FailureDetector.interpret() on each node. FailureDetector.interpret() is meant to update its sense of Phi for the node, and potentially convict it. However there is a short-circuit at the top, whereby if we do not yet have any arrival window for the node, we simply return immediately. Arrival intervals are only added as a result of a FailureDetector.report() call, which never happens in this case because the initial endpoint state we added, which came from a remote node that was up, had the latest version of the gossip state (so Gossiper.reportFailureDetector() will never call report()). The result is that the node can never ever be convicted. Now, let's ignore for a moment the problem that a node that is actually Down will be thought to be Up temporarily for a little while. That is sub-optimal, but let's aim for a fix to the more serious problem in this ticket - which is that is stays up forever. Considered solutions: * When interpret() gets called and there is no arrival window, we could add a faked arrival window
[jira] [Commented] (CASSANDRA-2475) Prepared statements
[ https://issues.apache.org/jira/browse/CASSANDRA-2475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13169820#comment-13169820 ] Hudson commented on CASSANDRA-2475: --- Integrated in Cassandra #1256 (See [https://builds.apache.org/job/Cassandra/1256/]) use an LRU map for storage of prepared statements Patch by eevans; reviewed by Rick Shaw for CASSANDRA-2475 log CQL queries at TRACE Patch by eevans; reviewed by Rick Shaw for CASSANDRA-2475 refactor for better encapsulation of prepare() Patch by eevans; reviewed by Rick Shaw for CASSANDRA-2475 review-related code-style fixes and cleanups Patch by eevans; reviewed by Rick Shaw for CASSANDRA-2475 compiler generated thrift code for prepared statements Patch by Rick Shaw; reviewed by eevans for CASSANDRA-2475 CQL support for prepared statements Patch by Rick Shaw; reviewed by eevans for CASSANDRA-2475 eevans : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1214527 Files : * /cassandra/trunk/src/java/org/apache/cassandra/service/ClientState.java * /cassandra/trunk/src/java/org/apache/cassandra/thrift/CassandraServer.java eevans : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1214526 Files : * /cassandra/trunk/src/java/org/apache/cassandra/cql/QueryProcessor.java eevans : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1214525 Files : * /cassandra/trunk/src/java/org/apache/cassandra/cql/QueryProcessor.java * /cassandra/trunk/src/java/org/apache/cassandra/thrift/CassandraServer.java eevans : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1214523 Files : * /cassandra/trunk/src/java/org/apache/cassandra/cql/DeleteStatement.java * /cassandra/trunk/src/java/org/apache/cassandra/cql/QueryProcessor.java * /cassandra/trunk/src/java/org/apache/cassandra/cql/SelectExpression.java * /cassandra/trunk/src/java/org/apache/cassandra/cql/SelectStatement.java * /cassandra/trunk/src/java/org/apache/cassandra/cql/Term.java * /cassandra/trunk/src/java/org/apache/cassandra/cql/WhereClause.java * /cassandra/trunk/src/java/org/apache/cassandra/thrift/CassandraServer.java eevans : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1214521 Files : * /cassandra/trunk/interface/cassandra.thrift * /cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java * /cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Constants.java * /cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/CqlPreparedResult.java eevans : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1214520 Files : * /cassandra/trunk/interface/cassandra.thrift * /cassandra/trunk/src/java/org/apache/cassandra/cql/AbstractModification.java * /cassandra/trunk/src/java/org/apache/cassandra/cql/BatchStatement.java * /cassandra/trunk/src/java/org/apache/cassandra/cql/CQLStatement.java * /cassandra/trunk/src/java/org/apache/cassandra/cql/Cql.g * /cassandra/trunk/src/java/org/apache/cassandra/cql/CreateColumnFamilyStatement.java * /cassandra/trunk/src/java/org/apache/cassandra/cql/DeleteStatement.java * /cassandra/trunk/src/java/org/apache/cassandra/cql/QueryProcessor.java * /cassandra/trunk/src/java/org/apache/cassandra/cql/SelectExpression.java * /cassandra/trunk/src/java/org/apache/cassandra/cql/SelectStatement.java * /cassandra/trunk/src/java/org/apache/cassandra/cql/Term.java * /cassandra/trunk/src/java/org/apache/cassandra/cql/UpdateStatement.java * /cassandra/trunk/src/java/org/apache/cassandra/cql/WhereClause.java * /cassandra/trunk/src/java/org/apache/cassandra/service/ClientState.java * /cassandra/trunk/src/java/org/apache/cassandra/thrift/CassandraServer.java Prepared statements --- Key: CASSANDRA-2475 URL: https://issues.apache.org/jira/browse/CASSANDRA-2475 Project: Cassandra Issue Type: New Feature Components: API, Core Affects Versions: 1.0.5 Reporter: Eric Evans Assignee: Rick Shaw Priority: Minor Labels: cql Fix For: 1.1 Attachments: 2475-v1.patch, 2475-v2.patch, 2475-v3.1.patch, 2475-v3.2-Thrift.patch, v1-0001-CASSANDRA-2475-prepared-statement-patch.txt, v1-0002-regenerated-thrift-java.txt, v2-0001-CASSANDRA-2475-rickshaw-2475-v3.1.patch.txt, v2-0002-rickshaw-2475-v3.2-Thrift.patch-w-changes.txt, v2-0003-eevans-increment-thrift-version-by-1-not-3.txt, v2-0004-eevans-misc-cleanups.txt, v2-0005-eevans-refactor-for-better-encapsulation-of-prepare.txt, v2-0006-eevans-log-queries-at-TRACE.txt, v2-0007-use-an-LRU-map-for-storage-of-prepared-statements.txt -- 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
[jira] [Commented] (CASSANDRA-3622) clean up openbitset
[ https://issues.apache.org/jira/browse/CASSANDRA-3622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13169052#comment-13169052 ] Hudson commented on CASSANDRA-3622: --- Integrated in Cassandra #1255 (See [https://builds.apache.org/job/Cassandra/1255/]) clean up OpenBitSet patch by jbellis; reviewed by slebresne for CASSANDRA-3622 jbellis : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1214034 Files : * /cassandra/trunk/src/java/org/apache/cassandra/utils/BloomFilter.java * /cassandra/trunk/src/java/org/apache/cassandra/utils/obs/OpenBitSet.java clean up openbitset --- Key: CASSANDRA-3622 URL: https://issues.apache.org/jira/browse/CASSANDRA-3622 Project: Cassandra Issue Type: Task Components: Core Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 1.1 Attachments: 3622-v2.txt, 3622.txt Our OpenBitSet no longer supports expanding the set post-construction. Should update documentation to reflect 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] [Commented] (CASSANDRA-3485) Gossiper.addSavedEndpoint should never add itself
[ https://issues.apache.org/jira/browse/CASSANDRA-3485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13166833#comment-13166833 ] Hudson commented on CASSANDRA-3485: --- Integrated in Cassandra-0.8 #416 (See [https://builds.apache.org/job/Cassandra-0.8/416/]) Prevent gossiper from adding itself to saved endpoints. Patch by brandonwilliams reviewed by Paul Cannon for CASSANDRA-3485. brandonwilliams : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1212624 Files : * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/SystemTable.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/gms/Gossiper.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/StorageService.java 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 Affects Versions: 0.7 beta 3 Reporter: Brandon Williams Assignee: Brandon Williams Fix For: 0.8.9, 1.0.6 Attachments: 3485.txt 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 with 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] [Commented] (CASSANDRA-3476) Allow user to override jvm options picked by cassandra-env.sh
[ https://issues.apache.org/jira/browse/CASSANDRA-3476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13166953#comment-13166953 ] Hudson commented on CASSANDRA-3476: --- Integrated in Cassandra #1251 (See [https://builds.apache.org/job/Cassandra/1251/]) add support for JVM_EXTRA_OPTS env variable to cassandra-env.sh patch by Radim Kolar; reviewed by Paul Cannon for CASSANDRA-3476 jbellis : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1212843 Files : * /cassandra/trunk/conf/cassandra-env.sh Allow user to override jvm options picked by cassandra-env.sh - Key: CASSANDRA-3476 URL: https://issues.apache.org/jira/browse/CASSANDRA-3476 Project: Cassandra Issue Type: Improvement Reporter: Radim Kolar Assignee: Radim Kolar Priority: Minor Labels: lhf Fix For: 1.1 Attachments: 3476.patch.txt, patch-env currently user have $JVM_OPTS - they are used before automagically generated ops. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3580) Don't assume the Table instance has been open when dropping a keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-3580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13166969#comment-13166969 ] Hudson commented on CASSANDRA-3580: --- Integrated in Cassandra-0.8 #417 (See [https://builds.apache.org/job/Cassandra-0.8/417/]) remove invalid assertion that table was opened before dropping it patch by slebresne; reviewed by jbellis for CASSANDRA-3580 jbellis : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1212849 Files : * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/migration/DropKeyspace.java Don't assume the Table instance has been open when dropping a keyspace -- Key: CASSANDRA-3580 URL: https://issues.apache.org/jira/browse/CASSANDRA-3580 Project: Cassandra Issue Type: Bug Affects Versions: 0.8.0 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Trivial Fix For: 0.8.9, 1.0.6 Attachments: 0001-Super-awesome-fix.patch DropKeyspace assumes that the Table had been open (rather, it checks that Table.clear() don't return null). It has been seen however that in the case of a fat client (the sstableloader in that case, but it would be true for any fat client) the Table may not have been open. Let's just remove that assertion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3598) Index Scan's will span across multiple DC's
[ https://issues.apache.org/jira/browse/CASSANDRA-3598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13166445#comment-13166445 ] Hudson commented on CASSANDRA-3598: --- Integrated in Cassandra-0.8 #414 (See [https://builds.apache.org/job/Cassandra-0.8/414/]) range and index scans now only send requests to enough replicas to satisfy requested CL + RR patch by Vijay and jbellis for CASSANDRA-3598 jbellis : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1212552 Files : * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/StorageProxy.java Index Scan's will span across multiple DC's --- Key: CASSANDRA-3598 URL: https://issues.apache.org/jira/browse/CASSANDRA-3598 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.0 Reporter: Vijay Assignee: Vijay Priority: Minor Fix For: 0.7.4, 0.8.9, 1.0.6 Attachments: 0001-super-simple-patch-3598.patch Looks like we send requests to all the nodes provided by StorageService.instance.getLiveNaturalEndpoints(keyspace, range.right); We dont filter it based on blockedFor (Consistency levels). In a multi DC setup this will cause unnecessary load on the other DC. And even within a DC we might query more nodes than needed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2189) json2sstable fails due to OutOfMemory
[ https://issues.apache.org/jira/browse/CASSANDRA-2189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13165349#comment-13165349 ] Hudson commented on CASSANDRA-2189: --- Integrated in Cassandra-0.8 #413 (See [https://builds.apache.org/job/Cassandra-0.8/413/]) turn off string interning in json2sstable, take 2 patch by jbellis; tested by George Ciubotaru for CASSANDRA-2189 jbellis : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1211976 Files : * /cassandra/branches/cassandra-0.8 * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/tools/SSTableImport.java json2sstable fails due to OutOfMemory - Key: CASSANDRA-2189 URL: https://issues.apache.org/jira/browse/CASSANDRA-2189 Project: Cassandra Issue Type: Bug Components: Tools Environment: linux Reporter: Shotaro Kamio Assignee: Jonathan Ellis Priority: Minor Fix For: 0.8.9, 1.0.6 Attachments: 2189-2.txt, 2189.txt Original Estimate: 1h Remaining Estimate: 1h I have a json file created with sstable2json for a column family of super column type. Its size is about 1.9GB. (It's a dump of all keys because I cannot find out how to specify keys to dump in sstable2json.) When I tried to create sstable from the json file, it failed with OutOfMemoryError as follows. WARN 00:31:58,595 Schema definitions were defined both locally and in cassandra.yaml. Definitions in cassandra.yaml were ignored. Exception in thread main java.lang.OutOfMemoryError: PermGen space at java.lang.String.intern(Native Method) at org.codehaus.jackson.util.InternCache.intern(InternCache.java:40) at org.codehaus.jackson.sym.BytesToNameCanonicalizer.addName(BytesToNameCanonicalizer.java:471) at org.codehaus.jackson.impl.Utf8StreamParser.addName(Utf8StreamParser.java:893) at org.codehaus.jackson.impl.Utf8StreamParser.findName(Utf8StreamParser.java:773) at org.codehaus.jackson.impl.Utf8StreamParser.parseLongFieldName(Utf8StreamParser.java:379) at org.codehaus.jackson.impl.Utf8StreamParser.parseMediumFieldName(Utf8StreamParser.java:347) at org.codehaus.jackson.impl.Utf8StreamParser._parseFieldName(Utf8StreamParser.java:304) at org.codehaus.jackson.impl.Utf8StreamParser.nextToken(Utf8StreamParser.java:140) at org.codehaus.jackson.map.deser.UntypedObjectDeserializer.mapObject(UntypedObjectDeserializer.java:93) at org.codehaus.jackson.map.deser.UntypedObjectDeserializer.deserialize(UntypedObjectDeserializer.java:65) at org.codehaus.jackson.map.deser.MapDeserializer._readAndBind(MapDeserializer.java:197) at org.codehaus.jackson.map.deser.MapDeserializer.deserialize(MapDeserializer.java:145) at org.codehaus.jackson.map.deser.MapDeserializer.deserialize(MapDeserializer.java:23) at org.codehaus.jackson.map.ObjectMapper._readValue(ObjectMapper.java:1261) at org.codehaus.jackson.map.ObjectMapper.readValue(ObjectMapper.java:517) at org.codehaus.jackson.JsonParser.readValueAs(JsonParser.java:897) at org.apache.cassandra.tools.SSTableImport.importUnsorted(SSTableImport.java:208) at org.apache.cassandra.tools.SSTableImport.importJson(SSTableImport.java:197) at org.apache.cassandra.tools.SSTableImport.main(SSTableImport.java:421) So, what I had to is that split the json file with split command and modify them to be correct json file. Create sstable for each small json files. Could you change json2sstable to avoid OutOfMemory? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3545) Fix very low Secondary Index performance
[ https://issues.apache.org/jira/browse/CASSANDRA-3545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13165407#comment-13165407 ] Hudson commented on CASSANDRA-3545: --- Integrated in Cassandra #1248 (See [https://builds.apache.org/job/Cassandra/1248/]) Improve memtable slice iteration performance patch by slebresne; reviewed by jbellis for CASSANDRA-3545 slebresne : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1211999 Files : * /cassandra/trunk/CHANGES.txt * /cassandra/trunk/src/java/org/apache/cassandra/db/AbstractColumnContainer.java * /cassandra/trunk/src/java/org/apache/cassandra/db/ArrayBackedSortedColumns.java * /cassandra/trunk/src/java/org/apache/cassandra/db/CollationController.java * /cassandra/trunk/src/java/org/apache/cassandra/db/ColumnFamilyStore.java * /cassandra/trunk/src/java/org/apache/cassandra/db/ISortedColumns.java * /cassandra/trunk/src/java/org/apache/cassandra/db/Memtable.java * /cassandra/trunk/src/java/org/apache/cassandra/db/RowIteratorFactory.java * /cassandra/trunk/src/java/org/apache/cassandra/db/ThreadSafeSortedColumns.java * /cassandra/trunk/src/java/org/apache/cassandra/db/TreeMapBackedSortedColumns.java * /cassandra/trunk/src/java/org/apache/cassandra/db/filter/IFilter.java * /cassandra/trunk/src/java/org/apache/cassandra/db/filter/NamesQueryFilter.java * /cassandra/trunk/src/java/org/apache/cassandra/db/filter/QueryFilter.java * /cassandra/trunk/src/java/org/apache/cassandra/db/filter/SliceQueryFilter.java * /cassandra/trunk/src/java/org/apache/cassandra/db/index/keys/KeysSearcher.java * /cassandra/trunk/src/java/org/apache/cassandra/service/RowRepairResolver.java * /cassandra/trunk/test/unit/org/apache/cassandra/db/ArrayBackedSortedColumnsTest.java Fix very low Secondary Index performance Key: CASSANDRA-3545 URL: https://issues.apache.org/jira/browse/CASSANDRA-3545 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.0 Reporter: Evgeny Ryabitskiy Assignee: Sylvain Lebresne Fix For: 1.0.6 Attachments: 0001-3545.patch, 0002-cleanup.patch While performing index search + value filtering over large Index Row ( ~100k keys per index value) with chunks (size of 512-1024 keys) search time is about 8-12 seconds, which is very very low. After profiling I got this picture: 60% of search time is calculating MD5 hash with MessageDigester (Of cause it is because of RundomPartitioner). 33% of search time (half of all MD5 hash calculating time) is double calculating of MD5 for comparing two row keys while rotating Index row to startKey (when performing search query for next chunk). I see several performance improvements: 1) Use good algorithm to search startKey in sorted collection, that is faster then iteration over all keys. This solution is on first place because it simple, need only local code changes and should solve problem (increase search in multiple times). 2) Don't calculate MD5 hash for startKey every time. It's optimal to compute it once (so search will be twice faster). Also need local code changes. 3) Think about something faster that MD5 for hashing (like TigerRandomPartitioner with Tiger/128 hash). Need research and maybe this research was done. 4) Don't use Tokens (with MD5 hash for RandomPartitioner) for comparing and sorting keys in index rows. In index rows, keys can be stored and compared with simple Byte Comparator. This solution requires huge code changes. I'm going to start from first solution. Next improvements can be done with next tickets. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3582) UserInterruptedException is poorly encapsulated
[ https://issues.apache.org/jira/browse/CASSANDRA-3582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13165602#comment-13165602 ] Hudson commented on CASSANDRA-3582: --- Integrated in Cassandra #1249 (See [https://builds.apache.org/job/Cassandra/1249/]) improve UserInterruptedException encapsulation (and renamed to CompactionInterruptedException) patch by jbellis; reviewed by slebresne for CASSANDRA-3582 jbellis : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1212092 Files : * /cassandra/trunk/CHANGES.txt * /cassandra/trunk/src/java/org/apache/cassandra/concurrent/DebuggableThreadPoolExecutor.java * /cassandra/trunk/src/java/org/apache/cassandra/db/compaction/CompactionInterruptedException.java * /cassandra/trunk/src/java/org/apache/cassandra/db/compaction/CompactionManager.java * /cassandra/trunk/src/java/org/apache/cassandra/db/compaction/CompactionTask.java * /cassandra/trunk/src/java/org/apache/cassandra/db/compaction/UserInterruptedException.java * /cassandra/trunk/src/java/org/apache/cassandra/db/index/SecondaryIndexBuilder.java UserInterruptedException is poorly encapsulated --- Key: CASSANDRA-3582 URL: https://issues.apache.org/jira/browse/CASSANDRA-3582 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Labels: compaction Fix For: 1.1 Attachments: 3582-v2.txt, 3582.txt -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3577) TimeoutException When using QuorumEach or ALL consistency on Multi-DC
[ https://issues.apache.org/jira/browse/CASSANDRA-3577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13165603#comment-13165603 ] Hudson commented on CASSANDRA-3577: --- Integrated in Cassandra #1249 (See [https://builds.apache.org/job/Cassandra/1249/]) multi-dc replication optimization supporting CL ONE patch by Vijay and jbellis for CASSANDRA-3577 jbellis : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1212088 Files : * /cassandra/trunk/CHANGES.txt * /cassandra/trunk/src/java/org/apache/cassandra/db/RowMutationVerbHandler.java * /cassandra/trunk/src/java/org/apache/cassandra/net/MessagingService.java * /cassandra/trunk/src/java/org/apache/cassandra/service/StorageProxy.java TimeoutException When using QuorumEach or ALL consistency on Multi-DC - Key: CASSANDRA-3577 URL: https://issues.apache.org/jira/browse/CASSANDRA-3577 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.8 Environment: JVM Reporter: Vijay Assignee: Vijay Fix For: 0.8.9, 1.1 Attachments: 0001-Mutation-Optimization-for-MultiDC-v2.patch, 0001-Mutation-Optimization-for-MultiDC.patch, 0001-removing-mutation-MultiDC-optimization.patch, 3577-v3.txt, 3577.txt Currently we have 1) StorageProxy.sendMessages() sending messages to the first node in the other DC... 2) A node in the other DC will remove the ForwardHeader and sendRR (Adding a MessageID to the Queue). 3) The receiving node receives the mutation, updates and sends the response to the Original Co-ordinator. 4) Co-Ordinator now checks for the MessageID (which it never had) All the Quorum_Each updates fail in the co-ordinator, this issue started showing up after CASSANDRA-3472 the code was introduced in CASSANDRA-2138 . Simple Fix is to remove the optimization in 0.8 and fix it in 1.x because it seems to me like it needs a change to the Message service version. Possible Solution: We might want send the message ID's to be used by the all the nodes in other DC (Which is currently generated by the node which receives the Forward request see: (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] [Commented] (CASSANDRA-3541) Support timeuuid column names
[ https://issues.apache.org/jira/browse/CASSANDRA-3541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13164543#comment-13164543 ] Hudson commented on CASSANDRA-3541: --- Integrated in Cassandra #1243 (See [https://builds.apache.org/job/Cassandra/1243/]) Update to support TimeUUIDType (CASSANDRA-3541) Patch by eevans; reviewed by Pavel Yaskevich for CASSANDRA-2268 eevans : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1211522 Files : * /cassandra/trunk/tools/stress/src/org/apache/cassandra/stress/operations/CqlInserter.java Support timeuuid column names - Key: CASSANDRA-3541 URL: https://issues.apache.org/jira/browse/CASSANDRA-3541 Project: Cassandra Issue Type: New Feature Components: Tools Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Priority: Minor Fix For: 1.0.6 Attachments: CASSANDRA-3541-proper-type-paser-error-handling.patch, CASSANDRA-3541.patch Real-world Cassandra applications often use wide rows to denormalize queries into. Most often, this means they do a lot of appending to existing rows, with few overwrites. An easy way to add this to Stress would be to allow specifying timeuuid column names (which will be inherently sequential, or nearly so). For forwards-compatibility, we could add a --comparator option that only supports the existing Ascii type and the proposed UUID type, to start with. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2268) CQL-enabled stress.java
[ https://issues.apache.org/jira/browse/CASSANDRA-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13164542#comment-13164542 ] Hudson commented on CASSANDRA-2268: --- Integrated in Cassandra #1243 (See [https://builds.apache.org/job/Cassandra/1243/]) Update to support TimeUUIDType (CASSANDRA-3541) Patch by eevans; reviewed by Pavel Yaskevich for CASSANDRA-2268 optional CQL query support Patch by eevans; reviewed by Pavel Yaskevich for CASSANDRA-2268 CASSANDRA-2268 add stress source folder (eclipse) Patch by eevans; reviewed by Pavel Yaskevich for CASSANDRA-2268 eevans : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1211522 Files : * /cassandra/trunk/tools/stress/src/org/apache/cassandra/stress/operations/CqlInserter.java eevans : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1211521 Files : * /cassandra/trunk/tools/stress/src/org/apache/cassandra/stress/Session.java * /cassandra/trunk/tools/stress/src/org/apache/cassandra/stress/StressAction.java * /cassandra/trunk/tools/stress/src/org/apache/cassandra/stress/operations/CqlCounterAdder.java * /cassandra/trunk/tools/stress/src/org/apache/cassandra/stress/operations/CqlCounterGetter.java * /cassandra/trunk/tools/stress/src/org/apache/cassandra/stress/operations/CqlIndexedRangeSlicer.java * /cassandra/trunk/tools/stress/src/org/apache/cassandra/stress/operations/CqlInserter.java * /cassandra/trunk/tools/stress/src/org/apache/cassandra/stress/operations/CqlMultiGetter.java * /cassandra/trunk/tools/stress/src/org/apache/cassandra/stress/operations/CqlRangeSlicer.java * /cassandra/trunk/tools/stress/src/org/apache/cassandra/stress/operations/CqlReader.java * /cassandra/trunk/tools/stress/src/org/apache/cassandra/stress/util/Operation.java eevans : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1211520 Files : * /cassandra/trunk/build.xml CQL-enabled stress.java --- Key: CASSANDRA-2268 URL: https://issues.apache.org/jira/browse/CASSANDRA-2268 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Eric Evans Assignee: Eric Evans Priority: Minor Labels: cql Fix For: 1.0.6 Attachments: 0001-2268-wip.patch, v1-0001-CASSANDRA-2268-add-stress-source-folder-eclipse.txt, v1-0002-optional-CQL-query-support.txt, v2-0001-CASSANDRA-2268-add-stress-source-folder-eclipse.txt, v2-0002-optional-CQL-query-support.txt, v3-0001-CASSANDRA-2268-add-stress-source-folder-eclipse.txt, v3-0002-optional-CQL-query-support.txt, v3-0003-Update-to-support-TimeUUIDType-CASSANDRA-3541.txt, v4-0001-CASSANDRA-2268-add-stress-source-folder-eclipse.txt, v4-0002-optional-CQL-query-support.txt, v4-0003-Update-to-support-TimeUUIDType-CASSANDRA-3541.txt It would be great if stress.java had a CQL mode. For making the inevitable RPC-CQL comparisons, but also as a basis for measuring optimizations, and spotting performance regressions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3422) Can create a Column Family with comparator CounterColumnType which is subsequently unusable
[ https://issues.apache.org/jira/browse/CASSANDRA-3422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13164572#comment-13164572 ] Hudson commented on CASSANDRA-3422: --- Integrated in Cassandra-0.8 #411 (See [https://builds.apache.org/job/Cassandra-0.8/411/]) Detect misuses of CounterColumnType patch by slebresne; reviewed by jbellis for CASSANDRA-3422 slebresne : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1211486 Files : * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/config/CFMetaData.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/cql/CreateColumnFamilyStatement.java Can create a Column Family with comparator CounterColumnType which is subsequently unusable --- Key: CASSANDRA-3422 URL: https://issues.apache.org/jira/browse/CASSANDRA-3422 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.0 Reporter: Kelley Reynolds Assignee: Sylvain Lebresne Priority: Minor Fix For: 0.8.9, 1.0.6 Attachments: 3422-v2.patch, 3422.patch It's probably the case that this shouldn't be allowed at all but one is currently allowed to create a Column Family with comparator CounterColumnType which then appears unusable. CREATE COLUMNFAMILY comparator_cf_counter (id text PRIMARY KEY) WITH comparator=CounterColumnType # Fails UPDATE comparator_cf_counter SET 1=1 + 1 WHERE id='test_key' Error = invalid operation for non commutative columnfamily comparator_cf_counter -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3577) TimeoutException When using QuorumEach or ALL consistency on Multi-DC
[ https://issues.apache.org/jira/browse/CASSANDRA-3577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13163615#comment-13163615 ] Hudson commented on CASSANDRA-3577: --- Integrated in Cassandra-0.8 #409 (See [https://builds.apache.org/job/Cassandra-0.8/409/]) remove nonlocal DC write optimization patch by Vijay; reviewed by jbellis for CASSANDRA-3577 jbellis : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1210902 Files : * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/StorageProxy.java TimeoutException When using QuorumEach or ALL consistency on Multi-DC - Key: CASSANDRA-3577 URL: https://issues.apache.org/jira/browse/CASSANDRA-3577 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.8 Environment: JVM Reporter: Vijay Assignee: Vijay Fix For: 0.8.9 Attachments: 0001-removing-mutation-MultiDC-optimization.patch, 3577.txt Currently we have 1) StorageProxy.sendMessages() sending messages to the first node in the other DC... 2) A node in the other DC will remove the ForwardHeader and sendRR (Adding a MessageID to the Queue). 3) The receiving node receives the mutation, updates and sends the response to the Original Co-ordinator. 4) Co-Ordinator now checks for the MessageID (which it never had) All the Quorum_Each updates fail in the co-ordinator, this issue started showing up after CASSANDRA-3472 the code was introduced in CASSANDRA-2138 . Simple Fix is to remove the optimization in 0.8 and fix it in 1.x because it seems to me like it needs a change to the Message service version. Possible Solution: We might want send the message ID's to be used by the all the nodes in other DC (Which is currently generated by the node which receives the Forward request see: (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] [Commented] (CASSANDRA-3574) AssertionError in DK
[
https://issues.apache.org/jira/browse/CASSANDRA-3574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13163728#comment-13163728
]
Hudson commented on CASSANDRA-3574:
---
Integrated in Cassandra #1240 (See
[https://builds.apache.org/job/Cassandra/1240/])
Fix assertion error in DK
patch by slebresne; reviewed by jbellis for CASSANDRA-3574
slebresne :
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1211030
Files :
* /cassandra/trunk/CHANGES.txt
* /cassandra/trunk/src/java/org/apache/cassandra/cql/QueryProcessor.java
AssertionError in DK
Key: CASSANDRA-3574
URL: https://issues.apache.org/jira/browse/CASSANDRA-3574
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1
Reporter: Brandon Williams
Assignee: Sylvain Lebresne
Fix For: 1.1
Attachments: 3574.patch
When running the dtests:
{noformat}
ERROR [pool-2-thread-1] 2011-12-05 16:22:53,940 Cassandra.java (line 4082)
Internal error processing execute_cql_query
java.lang.AssertionError
at org.apache.cassandra.db.DecoratedKey.init(DecoratedKey.java:56)
at
org.apache.cassandra.dht.RandomPartitioner.decorateKey(RandomPartitioner.java:47)
at
org.apache.cassandra.cql.QueryProcessor.multiRangeSlice(QueryProcessor.java:161)
at
org.apache.cassandra.cql.QueryProcessor.process(QueryProcessor.java:549)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1249)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.process(Cassandra.java:4072)
at
org.apache.cassandra.thrift.Cassandra$Processor.process(Cassandra.java:2889)
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:662)
{noformat}
I suspect CASSANDRA-1034 is to blame.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3494) Streaming is mono-threaded (the bulk loader too by extension)
[
https://issues.apache.org/jira/browse/CASSANDRA-3494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13163312#comment-13163312
]
Hudson commented on CASSANDRA-3494:
---
Integrated in Cassandra #1238 (See
[https://builds.apache.org/job/Cassandra/1238/])
multithreaded streaming
patch by Peter Schuller; reviewed by yukim for CASSANDRA-3494
jbellis :
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1210748
Files :
* /cassandra/trunk/CHANGES.txt
*
/cassandra/trunk/src/java/org/apache/cassandra/concurrent/DebuggableThreadPoolExecutor.java
* /cassandra/trunk/src/java/org/apache/cassandra/net/MessagingService.java
* /cassandra/trunk/src/java/org/apache/cassandra/streaming/FileStreamTask.java
Streaming is mono-threaded (the bulk loader too by extension)
-
Key: CASSANDRA-3494
URL: https://issues.apache.org/jira/browse/CASSANDRA-3494
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 0.8.0
Reporter: Sylvain Lebresne
Assignee: Peter Schuller
Priority: Minor
Fix For: 1.1
Attachments: CASSANDRA-3494-0.8-prelim.txt, CASSANDRA-3494-1.0.txt
The streamExecutor is define as:
{noformat}
streamExecutor_ = new DebuggableThreadPoolExecutor(Streaming,
Thread.MIN_PRIORITY);
{noformat}
In the meantime, in DebuggableThreadPoolExecutor.java:
{noformat}
public DebuggableThreadPoolExecutor(String threadPoolName, int priority)
{
this(1, Integer.MAX_VALUE, TimeUnit.SECONDS, new
LinkedBlockingQueueRunnable(), new NamedThreadFactory(threadPoolName,
priority));
}
{noformat}
In other word, since the core pool size is 1 and the queue unbounded, tasks
will always queued and the executor is essentially mono-threaded.
This is clearly not necessary since we already have stream throttling
nowadays. And it could be a limiting factor in the case of the bulk loader.
Besides, I would venture that this maybe was not the intention, because
putting the max core size to MAX_VALUE would suggest that the intention was
to spawn threads on demand.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3538) Remove columns shadowed by a deleted container even when we cannot purge
[ https://issues.apache.org/jira/browse/CASSANDRA-3538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13161708#comment-13161708 ] Hudson commented on CASSANDRA-3538: --- Integrated in Cassandra #1231 (See [https://builds.apache.org/job/Cassandra/1231/]) Remove columns shadowed by a deleted container even when we cannot purge patch by slebresne; reviewed by jbellis for CASSANDRA-3538 slebresne : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1209530 Files : * /cassandra/trunk/CHANGES.txt * /cassandra/trunk/src/java/org/apache/cassandra/db/compaction/PrecompactedRow.java Remove columns shadowed by a deleted container even when we cannot purge Key: CASSANDRA-3538 URL: https://issues.apache.org/jira/browse/CASSANDRA-3538 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Trivial Fix For: 1.1 Attachments: 3538.patch During compaction, if shouldPurge == false, we don't do anything with the column family. It is however ok to remove columns for with their container is deleted with a timestamp greater than their own. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3556) nodetool info reports inaccurate datacenter/rack for localhost
[ https://issues.apache.org/jira/browse/CASSANDRA-3556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13161770#comment-13161770 ] Hudson commented on CASSANDRA-3556: --- Integrated in Cassandra-0.8 #408 (See [https://builds.apache.org/job/Cassandra-0.8/408/]) use cannonical host for local node in nodetool info patch by Rick Branson; reviewed by jbellis for CASSANDRA-3556 jbellis : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1209608 Files : * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/tools/NodeProbe.java nodetool info reports inaccurate datacenter/rack for localhost -- Key: CASSANDRA-3556 URL: https://issues.apache.org/jira/browse/CASSANDRA-3556 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.8.1 Reporter: Rick Branson Assignee: Rick Branson Priority: Minor Fix For: 0.8.9, 1.0.6 Attachments: 3556-v2.txt, 3556.txt The datacenter rack information provided by 'nodetool info' is incorrect when using 'nodetool -h localhost info'. This is because the IP address passed to the EndpointSnitch to determine the datacenter rack is sourced from the host parameter provided to nodetool and not the actual endpoint address used in 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] [Commented] (CASSANDRA-3561) Make incremental_backups setting mutable via JMX
[ https://issues.apache.org/jira/browse/CASSANDRA-3561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13161798#comment-13161798 ] Hudson commented on CASSANDRA-3561: --- Integrated in Cassandra #1232 (See [https://builds.apache.org/job/Cassandra/1232/]) JMX-enabled incremental_backups setting. Patch by brandonwilliams reviewed by jbellis for CASSANDRA-3561 brandonwilliams : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1209622 Files : * /cassandra/trunk/src/java/org/apache/cassandra/config/DatabaseDescriptor.java * /cassandra/trunk/src/java/org/apache/cassandra/db/DataTracker.java * /cassandra/trunk/src/java/org/apache/cassandra/service/StorageService.java * /cassandra/trunk/src/java/org/apache/cassandra/service/StorageServiceMBean.java 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 Assignee: Brandon Williams Priority: Trivial Fix For: 1.1 Attachments: 3561.txt 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] [Commented] (CASSANDRA-3543) Commit Log Allocator deadlock after first start with empty commitlog directory
[
https://issues.apache.org/jira/browse/CASSANDRA-3543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13161914#comment-13161914
]
Hudson commented on CASSANDRA-3543:
---
Integrated in Cassandra #1234 (See
[https://builds.apache.org/job/Cassandra/1234/])
enableReserveSegmentCreation even when there is nothing to replay
patch by Rick Branson; reviewed by jbellis for CASSANDRA-3543
jbellis :
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1209724
Files :
* /cassandra/trunk/CHANGES.txt
* /cassandra/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLog.java
Commit Log Allocator deadlock after first start with empty commitlog directory
--
Key: CASSANDRA-3543
URL: https://issues.apache.org/jira/browse/CASSANDRA-3543
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1
Reporter: Brandon Williams
Assignee: Rick Branson
Fix For: 1.1
Attachments: 3543.txt, hung_stack.txt
While testing CASSANDRA-3541 at some point stress completely timed out. I
proceeded to shut the cluster down and 2/3 JVMs hang infinitely. After a
while, one of them logged:
{noformat}
WARN 19:07:50,133 Some hints were not written before shutdown. This is not
supposed to happen. You should (a) run repair, and (b) file a bug report
{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] [Commented] (CASSANDRA-3557) Commit Log segments are not recycled
[ https://issues.apache.org/jira/browse/CASSANDRA-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13161971#comment-13161971 ] Hudson commented on CASSANDRA-3557: --- Integrated in Cassandra #1235 (See [https://builds.apache.org/job/Cassandra/1235/]) fix commitlog segment recycling patch by Rick Branson; reviewed by jbellis for CASSANDRA-3557 jbellis : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1209779 Files : * /cassandra/trunk/CHANGES.txt * /cassandra/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLog.java * /cassandra/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLogAllocator.java * /cassandra/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java * /cassandra/trunk/test/unit/org/apache/cassandra/SchemaLoader.java Commit Log segments are not recycled Key: CASSANDRA-3557 URL: https://issues.apache.org/jira/browse/CASSANDRA-3557 Project: Cassandra Issue Type: Bug Affects Versions: 1.1 Reporter: Rick Branson Assignee: Rick Branson Fix For: 1.1 Attachments: 3557.txt Cassandra never recycles segments created after recovery. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3567) remove unmaintained redhat packaging
[ https://issues.apache.org/jira/browse/CASSANDRA-3567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13162063#comment-13162063 ] Hudson commented on CASSANDRA-3567: --- Integrated in Cassandra #1236 (See [https://builds.apache.org/job/Cassandra/1236/]) r/m redhat package for CASSANDRA-3567 jbellis : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1209837 Files : * /cassandra/trunk/CHANGES.txt * /cassandra/trunk/redhat remove unmaintained redhat packaging Key: CASSANDRA-3567 URL: https://issues.apache.org/jira/browse/CASSANDRA-3567 Project: Cassandra Issue Type: Task Components: Packaging Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 1.1 The redhat package hasn't been changed since it was updated for 0.7.0 over a year ago, and nobody noticed until Paul did for CASSANDRA-3458. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-1034) Remove assumption that Key to Token is one-to-one
[ https://issues.apache.org/jira/browse/CASSANDRA-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13160764#comment-13160764 ] Hudson commented on CASSANDRA-1034: --- Integrated in Cassandra #1229 (See [https://builds.apache.org/job/Cassandra/1229/]) remove assumption that key and token are in bijection patch by slebresne; reviewed by jbellis for CASSANDRA-1034 slebresne : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1208993 Files : * /cassandra/trunk/CHANGES.txt * /cassandra/trunk/src/java/org/apache/cassandra/client/RingCache.java * /cassandra/trunk/src/java/org/apache/cassandra/config/DatabaseDescriptor.java * /cassandra/trunk/src/java/org/apache/cassandra/cql/QueryProcessor.java * /cassandra/trunk/src/java/org/apache/cassandra/db/ColumnFamilyStore.java * /cassandra/trunk/src/java/org/apache/cassandra/db/DecoratedKey.java * /cassandra/trunk/src/java/org/apache/cassandra/db/HintedHandOffManager.java * /cassandra/trunk/src/java/org/apache/cassandra/db/IndexScanCommand.java * /cassandra/trunk/src/java/org/apache/cassandra/db/Memtable.java * /cassandra/trunk/src/java/org/apache/cassandra/db/RangeSliceCommand.java * /cassandra/trunk/src/java/org/apache/cassandra/db/RowIteratorFactory.java * /cassandra/trunk/src/java/org/apache/cassandra/db/RowPosition.java * /cassandra/trunk/src/java/org/apache/cassandra/db/compaction/CompactionManager.java * /cassandra/trunk/src/java/org/apache/cassandra/db/compaction/LeveledManifest.java * /cassandra/trunk/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java * /cassandra/trunk/src/java/org/apache/cassandra/db/index/SecondaryIndexSearcher.java * /cassandra/trunk/src/java/org/apache/cassandra/db/index/keys/KeysSearcher.java * /cassandra/trunk/src/java/org/apache/cassandra/db/marshal/LocalByPartionerType.java * /cassandra/trunk/src/java/org/apache/cassandra/dht/AbstractBounds.java * /cassandra/trunk/src/java/org/apache/cassandra/dht/AbstractByteOrderedPartitioner.java * /cassandra/trunk/src/java/org/apache/cassandra/dht/AbstractPartitioner.java * /cassandra/trunk/src/java/org/apache/cassandra/dht/BootStrapper.java * /cassandra/trunk/src/java/org/apache/cassandra/dht/Bounds.java * /cassandra/trunk/src/java/org/apache/cassandra/dht/IPartitioner.java * /cassandra/trunk/src/java/org/apache/cassandra/dht/LocalPartitioner.java * /cassandra/trunk/src/java/org/apache/cassandra/dht/OrderPreservingPartitioner.java * /cassandra/trunk/src/java/org/apache/cassandra/dht/RandomPartitioner.java * /cassandra/trunk/src/java/org/apache/cassandra/dht/Range.java * /cassandra/trunk/src/java/org/apache/cassandra/dht/RingPosition.java * /cassandra/trunk/src/java/org/apache/cassandra/dht/Token.java * /cassandra/trunk/src/java/org/apache/cassandra/hadoop/ColumnFamilyInputFormat.java * /cassandra/trunk/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordWriter.java * /cassandra/trunk/src/java/org/apache/cassandra/io/sstable/IndexSummary.java * /cassandra/trunk/src/java/org/apache/cassandra/io/sstable/SSTableBoundedScanner.java * /cassandra/trunk/src/java/org/apache/cassandra/io/sstable/SSTableLoader.java * /cassandra/trunk/src/java/org/apache/cassandra/io/sstable/SSTableReader.java * /cassandra/trunk/src/java/org/apache/cassandra/io/sstable/SSTableScanner.java * /cassandra/trunk/src/java/org/apache/cassandra/locator/AbstractReplicationStrategy.java * /cassandra/trunk/src/java/org/apache/cassandra/locator/TokenMetadata.java * /cassandra/trunk/src/java/org/apache/cassandra/net/MessagingService.java * /cassandra/trunk/src/java/org/apache/cassandra/service/AntiEntropyService.java * /cassandra/trunk/src/java/org/apache/cassandra/service/StorageProxy.java * /cassandra/trunk/src/java/org/apache/cassandra/service/StorageService.java * /cassandra/trunk/src/java/org/apache/cassandra/service/StorageServiceMBean.java * /cassandra/trunk/src/java/org/apache/cassandra/streaming/StreamIn.java * /cassandra/trunk/src/java/org/apache/cassandra/streaming/StreamOut.java * /cassandra/trunk/src/java/org/apache/cassandra/streaming/StreamRequestMessage.java * /cassandra/trunk/src/java/org/apache/cassandra/streaming/StreamingRepairTask.java * /cassandra/trunk/src/java/org/apache/cassandra/thrift/CassandraServer.java * /cassandra/trunk/src/java/org/apache/cassandra/thrift/ThriftValidation.java * /cassandra/trunk/src/java/org/apache/cassandra/tools/BulkLoader.java * /cassandra/trunk/src/java/org/apache/cassandra/utils/FBUtilities.java * /cassandra/trunk/src/java/org/apache/cassandra/utils/MerkleTree.java * /cassandra/trunk/test/unit/org/apache/cassandra/Util.java * /cassandra/trunk/test/unit/org/apache/cassandra/db/CleanupTest.java * /cassandra/trunk/test/unit/org/apache/cassandra/db/ColumnFamilyStoreTest.java * /cassandra/trunk/test/unit/org/apache/cassandra/db/KeyCollisionTest.java * /cassandra/trunk/test/unit/org/apache/cassandra/db/SerializationsTest.java *
[jira] [Commented] (CASSANDRA-3045) Update ColumnFamilyOutputFormat to use new bulkload API
[ https://issues.apache.org/jira/browse/CASSANDRA-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13160193#comment-13160193 ] Hudson commented on CASSANDRA-3045: --- Integrated in Cassandra #1228 (See [https://builds.apache.org/job/Cassandra/1228/]) Bulk loader is no longer a fat client, hadoop bulk loader output format. Patch by brandonwilliams, reviewed by Yuki Morishita for CASSANDRA-3045 brandonwilliams : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1208499 Files : * /cassandra/trunk/CHANGES.txt * /cassandra/trunk/src/java/org/apache/cassandra/config/Config.java * /cassandra/trunk/src/java/org/apache/cassandra/config/DatabaseDescriptor.java * /cassandra/trunk/src/java/org/apache/cassandra/hadoop/BulkOutputFormat.java * /cassandra/trunk/src/java/org/apache/cassandra/hadoop/BulkRecordWriter.java * /cassandra/trunk/src/java/org/apache/cassandra/io/sstable/SSTableLoader.java * /cassandra/trunk/src/java/org/apache/cassandra/net/Header.java * /cassandra/trunk/src/java/org/apache/cassandra/net/Message.java * /cassandra/trunk/src/java/org/apache/cassandra/net/OutboundTcpConnection.java * /cassandra/trunk/src/java/org/apache/cassandra/streaming/FileStreamTask.java * /cassandra/trunk/src/java/org/apache/cassandra/streaming/IncomingStreamReader.java * /cassandra/trunk/src/java/org/apache/cassandra/streaming/StreamInSession.java * /cassandra/trunk/src/java/org/apache/cassandra/streaming/StreamReplyVerbHandler.java * /cassandra/trunk/src/java/org/apache/cassandra/tools/BulkLoader.java Update ColumnFamilyOutputFormat to use new bulkload API --- Key: CASSANDRA-3045 URL: https://issues.apache.org/jira/browse/CASSANDRA-3045 Project: Cassandra Issue Type: Improvement Components: Hadoop Reporter: Jonathan Ellis Assignee: Brandon Williams Priority: Minor Fix For: 1.1 Attachments: 0001-Remove-gossip-SS-requirement-from-BulkLoader.txt, 0002-Allow-DD-loading-without-yaml.txt, 0003-hadoop-output-support-for-bulk-loading.txt The bulk loading interface added in CASSANDRA-1278 is a great fit for Hadoop jobs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3520) Unit test are hanging on 0.8 branch
[ https://issues.apache.org/jira/browse/CASSANDRA-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13158506#comment-13158506 ] Hudson commented on CASSANDRA-3520: --- Integrated in Cassandra-0.8 #407 (See [https://builds.apache.org/job/Cassandra-0.8/407/]) Shutdown CL after having flushed non-durable CF patch by slebresne; reviewed by jbellis for CASSANDRA-3520 slebresne : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1207262 Files : * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/StorageService.java Unit test are hanging on 0.8 branch --- Key: CASSANDRA-3520 URL: https://issues.apache.org/jira/browse/CASSANDRA-3520 Project: Cassandra Issue Type: Bug Components: Tests Environment: Linux Reporter: Sylvain Lebresne Fix For: 0.8.8 Attachments: 0001-Use-durable-writes-for-system-ks.patch, 3520.patch As the summary says, the unit test on current 0.8 are just hanging after CliTest (it's apparently not the case on windows, but it is on Linux and MacOSX). Not sure what's going on, but what I can tell is that it's enough to run CliTest to have it hang after the test successfully pass (i.e, JUnit just wait indefinitely for the VM to exit). Even weirder, it seems that it is the counter increment in the CliTest that make it hang, if you comment those statement, it stop hanging. However, nothing seems to go wrong with the increment itself (the test passes) and it doesn't even trigger anything (typically sendToHintedEndpoint is not called because there is only one node). Looking at the stack when the VM is hanging (attached), there is nothing specific to counters in there, and nothing that struck me at odd (but I could miss something). There do is a few thrift thread running (CASSANDRA-3335), but why would that only be a problem for the tests in that situation is a mystery to me. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3530) Header class not thread safe, but mutated by multiple threads
[ https://issues.apache.org/jira/browse/CASSANDRA-3530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13157073#comment-13157073 ] Hudson commented on CASSANDRA-3530: --- Integrated in Cassandra-0.8 #404 (See [https://builds.apache.org/job/Cassandra-0.8/404/]) avoid race in OutboundTcpConnection in multi-DC setups patch by jbellis; reviewed by slebresne for CASSANDRA-3530 slebresne : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1206098 Files : * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/RowMutationVerbHandler.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/net/Header.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/net/Message.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/StorageProxy.java Header class not thread safe, but mutated by multiple threads - Key: CASSANDRA-3530 URL: https://issues.apache.org/jira/browse/CASSANDRA-3530 Project: Cassandra Issue Type: Bug Affects Versions: 0.8.0 Reporter: Sean Bridges Assignee: Jonathan Ellis Fix For: 0.8.8, 1.0.4 Attachments: 3530-0.8.txt, 3530-v2.txt, CASSANDRA-3530.patch With Cassandra 1.0.3 we are getting exceptions like, Fatal exception in thread Thread[WRITE-/xx.xx.xx.xx,5,main]java.util.ConcurrentModificationException at java.util.Hashtable$Enumerator.next(Unknown Source) at org.apache.cassandra.net.Header.serializedSize(Header.java:97) at org.apache.cassandra.net.OutboundTcpConnection.messageLength(OutboundTcpConnection.java:164) at org.apache.cassandra.net.OutboundTcpConnection.write(OutboundTcpConnection.java:154) at org.apache.cassandra.net.OutboundTcpConnection.writeConnected(OutboundTcpConnection.java:115) at org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:94) and, ERROR [WRITE-/xx.xx.xx.xx] 2011-11-24 22:08:28,981 AbstractCassandraDaemon.java (line 133) Fatal exception in thread Thread[WRITE-/10.30.12.79,5,main]java.lang.NullPointerException at org.apache.cassandra.net.Header.serializedSize(Header.java:101) at org.apache.cassandra.net.OutboundTcpConnection.messageLength(OutboundTcpConnection.java:164) at org.apache.cassandra.net.OutboundTcpConnection.write(OutboundTcpConnection.java:154) at org.apache.cassandra.net.OutboundTcpConnection.writeConnected(OutboundTcpConnection.java:115) at org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:94) It looks like Header is not thread safe, but the same header instance is modified concurrently while being sent to several threads in StorageProxy.sendMessages. This bug eventually causes the node to OOM, as it kills the OutboundTcpConnection thread, which means nothing is dequeing from queue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3520) Unit test are hanging on 0.8 branch
[ https://issues.apache.org/jira/browse/CASSANDRA-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13157248#comment-13157248 ] Hudson commented on CASSANDRA-3520: --- Integrated in Cassandra-0.8 #406 (See [https://builds.apache.org/job/Cassandra-0.8/406/]) set system keyspace back to durable_writes patch by slebresne; reviewed by jbellis for CASSANDRA-3520 jbellis : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1206257 Files : * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/config/KSMetaData.java Unit test are hanging on 0.8 branch --- Key: CASSANDRA-3520 URL: https://issues.apache.org/jira/browse/CASSANDRA-3520 Project: Cassandra Issue Type: Bug Components: Tests Environment: Linux Reporter: Sylvain Lebresne Fix For: 0.8.8 Attachments: 0001-Use-durable-writes-for-system-ks.patch As the summary says, the unit test on current 0.8 are just hanging after CliTest (it's apparently not the case on windows, but it is on Linux and MacOSX). Not sure what's going on, but what I can tell is that it's enough to run CliTest to have it hang after the test successfully pass (i.e, JUnit just wait indefinitely for the VM to exit). Even weirder, it seems that it is the counter increment in the CliTest that make it hang, if you comment those statement, it stop hanging. However, nothing seems to go wrong with the increment itself (the test passes) and it doesn't even trigger anything (typically sendToHintedEndpoint is not called because there is only one node). Looking at the stack when the VM is hanging (attached), there is nothing specific to counters in there, and nothing that struck me at odd (but I could miss something). There do is a few thrift thread running (CASSANDRA-3335), but why would that only be a problem for the tests in that situation is a mystery to me. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3514) CounterColumnFamily Compaction error (ArrayIndexOutOfBoundsException)
[ https://issues.apache.org/jira/browse/CASSANDRA-3514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13155745#comment-13155745 ] Hudson commented on CASSANDRA-3514: --- Integrated in Cassandra-0.8 #402 (See [https://builds.apache.org/job/Cassandra-0.8/402/]) Fix array out of bounds error in counter shard removal patch by slebresne; reviewed by yukim for CASSANDRA-3514 slebresne : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1205316 Files : * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/context/CounterContext.java * /cassandra/branches/cassandra-0.8/test/unit/org/apache/cassandra/db/context/CounterContextTest.java CounterColumnFamily Compaction error (ArrayIndexOutOfBoundsException) -- Key: CASSANDRA-3514 URL: https://issues.apache.org/jira/browse/CASSANDRA-3514 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.3 Reporter: Eric Falcao Assignee: Sylvain Lebresne Labels: compaction Fix For: 0.8.8, 1.0.4 Attachments: 3514.patch On a single node, I'm seeing the following error when trying to compact a CounterColumnFamily. This appears to have started with version 1.0.3. nodetool -h localhost compact TRProd MetricsAllTime Error occured during compaction java.util.concurrent.ExecutionException: java.lang.ArrayIndexOutOfBoundsException at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222) at java.util.concurrent.FutureTask.get(FutureTask.java:83) at org.apache.cassandra.db.compaction.CompactionManager.performMaximal(CompactionManager.java:250) at org.apache.cassandra.db.ColumnFamilyStore.forceMajorCompaction(ColumnFamilyStore.java:1471) at org.apache.cassandra.service.StorageService.forceTableCompaction(StorageService.java:1523) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:93) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:27) at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208) at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:120) at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:262) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1427) at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1265) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1360) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:788) at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305) at sun.rmi.transport.Transport$1.run(Transport.java:159) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:155) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Caused by: java.lang.ArrayIndexOutOfBoundsException at org.apache.cassandra.utils.ByteBufferUtil.arrayCopy(ByteBufferUtil.java:292) at org.apache.cassandra.db.context.CounterContext$ContextState.copyTo(CounterContext.java:792) at org.apache.cassandra.db.context.CounterContext.removeOldShards(CounterContext.java:709) at
[jira] [Commented] (CASSANDRA-2786) After a minor compaction, deleted key-slices are visible again
[ https://issues.apache.org/jira/browse/CASSANDRA-2786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13155948#comment-13155948 ] Hudson commented on CASSANDRA-2786: --- Integrated in Cassandra-0.8 #403 (See [https://builds.apache.org/job/Cassandra-0.8/403/]) avoid dropping tombstones when they might still be needed to shadow data in another sstable patch by slebresne and jbellis for CASSANDRA-2786 jbellis : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1205452 Files : * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/EchoedRow.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/compaction/CompactionController.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/compaction/LazilyCompactedRow.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/compaction/PrecompactedRow.java * /cassandra/branches/cassandra-0.8/test/unit/org/apache/cassandra/SchemaLoader.java * /cassandra/branches/cassandra-0.8/test/unit/org/apache/cassandra/db/compaction/CompactionsTest.java After a minor compaction, deleted key-slices are visible again -- Key: CASSANDRA-2786 URL: https://issues.apache.org/jira/browse/CASSANDRA-2786 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.0, 0.8.7 Environment: Reproduced on single Cassandra node (CentOS 5.5) Reproduced on single Cassandra node (Windows Server 2008) Reporter: rene kochen Assignee: Sylvain Lebresne Fix For: 0.8.8 Attachments: 0001-Fix-wrong-purge-of-deleted-cf.patch, 2786_part2.patch, 2786_part3-v2.txt, 2786_part3.patch, CassandraIssue.zip, CassandraIssueJava.zip After a minor compaction, deleted key-slices are visible again. Steps to reproduce: 1) Insert a row named test. 2) Insert 50 rows. During this step, row test is included in a major compaction: file-1, file-2, file-3 and file-4 compacted to file-5 (includes test). 3) Delete row named test. 4) Insert 50 rows. During this step, row test is included in a minor compaction: file-6, file-7, file-8 and file-9 compacted to file-10 (should include tombstoned test). After step 4, row test is live again. Test environment: Single node with empty database. Standard configured super-column-family (I see this behavior with several gc_grace settings (big and small values): create column family Customers with column_type = 'Super' and comparator = 'BytesType; In Cassandra 0.7.6 I observe the expected behavior, i.e. after step 4, the row is still deleted. I've included a .NET program to reproduce the problem. I will add a Java version later on. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3519) ConcurrentModificationException in FailureDetector
[
https://issues.apache.org/jira/browse/CASSANDRA-3519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13155039#comment-13155039
]
Hudson commented on CASSANDRA-3519:
---
Integrated in Cassandra-0.8 #400 (See
[https://builds.apache.org/job/Cassandra-0.8/400/])
Fix ConcurrentModificationException in FailureDetector
patch by amorton; reviewed by slebresne for CASSANDRA-3519
slebresne :
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1204884
Files :
* /cassandra/branches/cassandra-0.8/CHANGES.txt
*
/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/gms/FailureDetector.java
ConcurrentModificationException in FailureDetector
--
Key: CASSANDRA-3519
URL: https://issues.apache.org/jira/browse/CASSANDRA-3519
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.8.7
Environment: Free BSD 8.2
/java -version
java version 1.6.0_07
Diablo Java(TM) SE Runtime Environment (build 1.6.0_07-b02)
Diablo Java HotSpot(TM) 64-Bit Server VM (build 10.0-b23, mixed mode)
Reporter: Aaron Morton
Assignee: Aaron Morton
Priority: Minor
Fix For: 0.8.8, 1.0.4
Attachments: 3519.patch
Noticed in a 2 DC cluster, error was on node in DC 2 streaming to a node in
DC 1.
{code:java}
INFO [GossipTasks:1] 2011-11-20 18:36:05,153 Gossiper.java (line 759)
InetAddress /10.6.130.70 is now dead.
ERROR [GossipTasks:1] 2011-11-20 18:36:25,252 StreamOutSession.java (line
232) StreamOutSession /10.6.130.70 failed because {} died or was
restarted/removed
ERROR [AntiEntropySessions:21] 2011-11-20 18:36:25,252
AntiEntropyService.java (line 688) [repair
#7fb5b1b0-11f1-11e1--baed0a2090fe] session completed with the following
err
or
java.io.IOException: Endpoint /10.6.130.70 died
at
org.apache.cassandra.service.AntiEntropyService$RepairSession.failedNode(AntiEntropyService.java:725)
at
org.apache.cassandra.service.AntiEntropyService$RepairSession.convict(AntiEntropyService.java:762)
at
org.apache.cassandra.gms.FailureDetector.interpret(FailureDetector.java:192)
at org.apache.cassandra.gms.Gossiper.doStatusCheck(Gossiper.java:559)
at org.apache.cassandra.gms.Gossiper.access$700(Gossiper.java:62)
at org.apache.cassandra.gms.Gossiper$GossipTask.run(Gossiper.java:167)
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:181)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)
ERROR [GossipTasks:1] 2011-11-20 18:36:25,256 Gossiper.java (line 172) Gossip
error
java.util.ConcurrentModificationException
at
java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
at java.util.AbstractList$Itr.next(AbstractList.java:343)
at
org.apache.cassandra.gms.FailureDetector.interpret(FailureDetector.java:190)
at org.apache.cassandra.gms.Gossiper.doStatusCheck(Gossiper.java:559)
at org.apache.cassandra.gms.Gossiper.access$700(Gossiper.java:62)
at org.apache.cassandra.gms.Gossiper$GossipTask.run(Gossiper.java:167)
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:181)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)
ERROR [AntiEntropySessions:21] 2011-11-20
[jira] [Commented] (CASSANDRA-3411) Pre-allocated, Recycled Commitlog Segment Files
[ https://issues.apache.org/jira/browse/CASSANDRA-3411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13155561#comment-13155561 ] Hudson commented on CASSANDRA-3411: --- Integrated in Cassandra #1217 (See [https://builds.apache.org/job/Cassandra/1217/]) Recycle commitlog segments for improved performance patch by Rick Branson and jbellis for CASSANDRA-3411 jbellis : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1205203 Files : * /cassandra/trunk/CHANGES.txt * /cassandra/trunk/NEWS.txt * /cassandra/trunk/src/java/org/apache/cassandra/db/RowMutation.java * /cassandra/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLog.java * /cassandra/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLogAllocator.java * /cassandra/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java * /cassandra/trunk/src/java/org/apache/cassandra/service/AbstractCassandraDaemon.java * /cassandra/trunk/test/unit/org/apache/cassandra/db/CommitLogTest.java * /cassandra/trunk/test/unit/org/apache/cassandra/db/RecoveryManager2Test.java * /cassandra/trunk/test/unit/org/apache/cassandra/db/RecoveryManager3Test.java * /cassandra/trunk/test/unit/org/apache/cassandra/db/RecoveryManagerTest.java * /cassandra/trunk/test/unit/org/apache/cassandra/db/RecoveryManagerTruncateTest.java Pre-allocated, Recycled Commitlog Segment Files --- Key: CASSANDRA-3411 URL: https://issues.apache.org/jira/browse/CASSANDRA-3411 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Rick Branson Assignee: Rick Branson Priority: Minor Labels: commitlog Fix For: 1.1 Attachments: 001-pre-allocated-recycled-commitlog-segment-files-CASSANDRA-3411.patch, 003-pre-allocated-recycled-commitlog-segment-files-CASSANDRA-3411.patch, 004-pre-allocated-recycled-commitlog-segment-files-CASSANDRA-3411.patch, 006-pre-allocated-recycled-commitlog-segment-files-CASSANDRA-3411.patch, 3411-cleaned.txt, 3411-v5.txt, 3411-v6-retry.txt, 3411-v7.txt, 3411-v8.txt An approach for improving commitlog performance is to pre-allocate the full 128MB segment files and reuse them once all the mutations have been flushed. Pre-allocation allows writes to be performed without modifying the file size metadata, and should (in theory) allow the filesystem to allocate a contiguous block of space for the file. Recycling the segment files prevents the overhead of pre-allocation from impacting overall performance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2407) Compaction thread should try to empty a bucket before moving on
[
https://issues.apache.org/jira/browse/CASSANDRA-2407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13152979#comment-13152979
]
Hudson commented on CASSANDRA-2407:
---
Integrated in Cassandra #1213 (See
[https://builds.apache.org/job/Cassandra/1213/])
update size-tiered compaction to prioritize small tiers
patch by jbellis; reviewed by slebresne for CASSANDRA-2407
jbellis :
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1203729
Files :
* /cassandra/trunk/CHANGES.txt
* /cassandra/trunk/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
* /cassandra/trunk/src/java/org/apache/cassandra/db/DataTracker.java
*
/cassandra/trunk/src/java/org/apache/cassandra/db/compaction/AbstractCompactionStrategy.java
*
/cassandra/trunk/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
*
/cassandra/trunk/src/java/org/apache/cassandra/db/compaction/LeveledCompactionStrategy.java
*
/cassandra/trunk/src/java/org/apache/cassandra/db/compaction/SizeTieredCompactionStrategy.java
*
/cassandra/trunk/test/unit/org/apache/cassandra/db/compaction/CompactionsTest.java
Compaction thread should try to empty a bucket before moving on
---
Key: CASSANDRA-2407
URL: https://issues.apache.org/jira/browse/CASSANDRA-2407
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Stu Hood
Assignee: Jonathan Ellis
Priority: Minor
Labels: compaction
Fix For: 1.1
Attachments: 2407-v2.txt, 2407-v3.txt, 2407-v4.txt, 2407.txt
As suggested by Aaron Morton
[(1)|https://issues.apache.org/jira/browse/CASSANDRA-2191?focusedCommentId=13010077page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13010077],
a compaction thread should attempt to empty a bucket before moving on to a
larger bucket. This would change the submitMinorIfNeeded {{for}} loop into a
while loop that regenerated the buckets and started from the bottom after
each successful compaction.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3503) IncomingStreamReader uses socket.getRemoteSocketAddress() which might be diffrent than FB.getBroadcastAddress()
[ https://issues.apache.org/jira/browse/CASSANDRA-3503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13152449#comment-13152449 ] Hudson commented on CASSANDRA-3503: --- Integrated in Cassandra #1212 (See [https://builds.apache.org/job/Cassandra/1212/]) Streaming uses BroadcastAddress instead of the remote socket. Patch by Vijay, reviewed by brandonwilliams for CASSANDRA-3503 brandonwilliams : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1203394 Files : * /cassandra/trunk/src/java/org/apache/cassandra/streaming/IncomingStreamReader.java * /cassandra/trunk/src/java/org/apache/cassandra/streaming/StreamHeader.java IncomingStreamReader uses socket.getRemoteSocketAddress() which might be diffrent than FB.getBroadcastAddress() --- Key: CASSANDRA-3503 URL: https://issues.apache.org/jira/browse/CASSANDRA-3503 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1 Environment: JVM Reporter: Vijay Assignee: Vijay Priority: Minor Fix For: 1.1 Attachments: 0001-fixing-the-bca-lookup-for-streaming-v2.patch, 0001-fixing-the-bca-lookup-for-streaming.patch We can add BCA to the streaming so the receiver can use this to StreamInSession.get(bca, sid) Currently this causes the repairs to hang when the bca is diffrent than LocalAddress. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3186) nodetool should not NPE when rack/dc info is not yet available
[ https://issues.apache.org/jira/browse/CASSANDRA-3186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13151657#comment-13151657 ] Hudson commented on CASSANDRA-3186: --- Integrated in Cassandra-0.8 #399 (See [https://builds.apache.org/job/Cassandra-0.8/399/]) Set default rack/dc in ec2snitch to avoid NPEs. Patch by Alex Araujo, reviewed by brandonwilliams for CASSANDRA-3186. brandonwilliams : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1202892 Files : * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/locator/Ec2Snitch.java nodetool should not NPE when rack/dc info is not yet available -- Key: CASSANDRA-3186 URL: https://issues.apache.org/jira/browse/CASSANDRA-3186 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.1 Reporter: Brandon Williams Assignee: Brandon Williams Priority: Minor Labels: lhf Fix For: 0.8.8 Attachments: cassandra-0.8-3186.txt As the title says. What happens is the persisted ring is loaded, but if those nodes are down and you're using a snitch like ec2 that gets rack/dc info from gossip, nodetool NPEs instead of showing that the node is down. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3434) Explore using Guava (or guava inspired) faster bytes comparison
[ https://issues.apache.org/jira/browse/CASSANDRA-3434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13149664#comment-13149664 ] Hudson commented on CASSANDRA-3434: --- Integrated in Cassandra #1206 (See [https://builds.apache.org/job/Cassandra/1206/]) Use (Guava inspired) faster bytes comparison patch by slebresne; reviewed by jbellis for CASSANDRA-3434 slebresne : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1201726 Files : * /cassandra/trunk/CHANGES.txt * /cassandra/trunk/src/java/org/apache/cassandra/utils/ByteBufferUtil.java * /cassandra/trunk/src/java/org/apache/cassandra/utils/FBUtilities.java * /cassandra/trunk/test/unit/org/apache/cassandra/db/marshal/ReversedTypeTest.java * /cassandra/trunk/test/unit/org/apache/cassandra/dht/RangeTest.java Explore using Guava (or guava inspired) faster bytes comparison --- Key: CASSANDRA-3434 URL: https://issues.apache.org/jira/browse/CASSANDRA-3434 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.1 Attachments: 3434.patch Guava uses un.misc.Unsafe to do a faster byte arrays comparison (on long at a time) as noted in HADOOP-7761. We should probably look into 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] [Commented] (CASSANDRA-2855) Skip rows with empty columns when slicing entire row
[ https://issues.apache.org/jira/browse/CASSANDRA-2855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13148007#comment-13148007 ] Hudson commented on CASSANDRA-2855: --- Integrated in Cassandra-0.8 #398 (See [https://builds.apache.org/job/Cassandra-0.8/398/]) Skip empty rows when entire row is requested, redux. Patch by tjake, reviewed by brandonwilliams for CASSANDRA-2855 brandonwilliams : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1200471 Files : * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java Skip rows with empty columns when slicing entire row Key: CASSANDRA-2855 URL: https://issues.apache.org/jira/browse/CASSANDRA-2855 Project: Cassandra Issue Type: Improvement Components: API Reporter: Jeremy Hanna Assignee: T Jake Luciani Priority: Minor Labels: hadoop Fix For: 0.8.8 Attachments: 2855-v2.txt, 2855-v3.txt, 2855-v4.txt, 2855-v5.txt, v1-0001-CASSANDRA-2855-ignore-ghosts-when-no-predicate-specifi.txt We have been finding that range ghosts appear in results from Hadoop via Pig. This could also happen if rows don't have data for the slice predicate that is given. This leads to having to do a painful amount of defensive checking on the Pig side, especially in the case of range ghosts. We would like to add an option to skip rows that have no column values in it. That functionality existed before in core Cassandra but was removed because of the performance penalty of that checking. However with Hadoop support in the RecordReader, that is batch oriented anyway, so individual row reading performance isn't as much of an issue. Also we would make it an optional config parameter for each job anyway, so people wouldn't have to incur that penalty if they are confident that there won't be those empty rows or they don't care. It could be parameter cassandra.skip.empty.rows and be true/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] [Commented] (CASSANDRA-3450) maybeInit in ColumnFamilyRecordReader can cause rows to be empty but not null
[
https://issues.apache.org/jira/browse/CASSANDRA-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13146375#comment-13146375
]
Hudson commented on CASSANDRA-3450:
---
Integrated in Cassandra-0.8 #395 (See
[https://builds.apache.org/job/Cassandra-0.8/395/])
Revert CASSANDRA-3450
jake : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1199242
Files :
* /cassandra/branches/cassandra-0.8/CHANGES.txt
*
/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java
maybeInit in ColumnFamilyRecordReader can cause rows to be empty but not null
-
Key: CASSANDRA-3450
URL: https://issues.apache.org/jira/browse/CASSANDRA-3450
Project: Cassandra
Issue Type: Bug
Components: Hadoop
Affects Versions: 0.8.7, 1.0.1
Reporter: Lanny Ripple
Assignee: Lanny Ripple
Fix For: 0.8.8, 1.0.3
Attachments: v1-0001-CASSANDRA-3450.txt
1) In {{ColumnFamilyRecordReader}} {{isPredicateEmpty}} needs bracing to
correctly place the {{else if}} to the properly controlling {{if}}.
1a) {{isPredicateEmpty}} should use an || in the getSlice_range predicate
rather than .
2) In {{ColumnFamilyRecordReader}} {{computeNext()}} calls {{maybeInit()}}
and then if {{ros}} is not null it is indexed into. {{maybeInit()}} could
fetch new data, determine the associated slice predicate is empty, and end up
removing all the rows if all columns turned out to be empty. There is no
check for {{rows.isEmpty()}} after the possible removal of all rows.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2855) Skip rows with empty columns when slicing entire row
[ https://issues.apache.org/jira/browse/CASSANDRA-2855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13146376#comment-13146376 ] Hudson commented on CASSANDRA-2855: --- Integrated in Cassandra-0.8 #395 (See [https://builds.apache.org/job/Cassandra-0.8/395/]) Revert CASSANDRA-2855 jake : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1199245 Files : * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java Skip rows with empty columns when slicing entire row Key: CASSANDRA-2855 URL: https://issues.apache.org/jira/browse/CASSANDRA-2855 Project: Cassandra Issue Type: Improvement Components: API Reporter: Jeremy Hanna Assignee: Jeremy Hanna Priority: Minor Labels: hadoop Fix For: 0.8.8 Attachments: 2855-v2.txt, 2855-v3.txt, 2855-v4.txt, 2855-v5.txt We have been finding that range ghosts appear in results from Hadoop via Pig. This could also happen if rows don't have data for the slice predicate that is given. This leads to having to do a painful amount of defensive checking on the Pig side, especially in the case of range ghosts. We would like to add an option to skip rows that have no column values in it. That functionality existed before in core Cassandra but was removed because of the performance penalty of that checking. However with Hadoop support in the RecordReader, that is batch oriented anyway, so individual row reading performance isn't as much of an issue. Also we would make it an optional config parameter for each job anyway, so people wouldn't have to incur that penalty if they are confident that there won't be those empty rows or they don't care. It could be parameter cassandra.skip.empty.rows and be true/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] [Commented] (CASSANDRA-3472) Actually uses efficient cross DC writes
[
https://issues.apache.org/jira/browse/CASSANDRA-3472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13146446#comment-13146446
]
Hudson commented on CASSANDRA-3472:
---
Integrated in Cassandra-0.8 #396 (See
[https://builds.apache.org/job/Cassandra-0.8/396/])
Fix bug preventing the use of efficient cross-DC writes
patch by slebresne; reviewed by jbellis for CASSANDRA-3472
slebresne :
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1199284
Files :
* /cassandra/branches/cassandra-0.8/CHANGES.txt
*
/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/StorageProxy.java
*
/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/StorageService.java
Actually uses efficient cross DC writes
---
Key: CASSANDRA-3472
URL: https://issues.apache.org/jira/browse/CASSANDRA-3472
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.7.1
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 0.8.8, 1.0.3
Attachments: 3472.patch
CASSANDRA-2138 introduced the following code:
{noformat}
if (dataCenter.equals(localDataCenter) ||
StorageService.instance.useEfficientCrossDCWrites())
{
// direct writes to local DC or old Cassadra versions
for (InetAddress destination : messages.getValue())
MessagingService.instance().sendRR(message, destination, handler);
}
else
{
// Non-local DC. First endpoint in list is the destination for this group
{noformat}
A 'not' is missing on that useEfficientCrossDCWrites call (which does return
true for any version = 0.7.1).
A simple fix would be to add the missing !, but as said a comment, all this
code should have been removed in 0.8 since it was detecting nodes before
0.7.1, but direct upgrade from pre-0.7.1 to 0.8+ is not supported. So let's
just completely remove that code now.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3178) Counter shard merging is not thread safe
[ https://issues.apache.org/jira/browse/CASSANDRA-3178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145576#comment-13145576 ] Hudson commented on CASSANDRA-3178: --- Integrated in Cassandra-0.8 #394 (See [https://builds.apache.org/job/Cassandra-0.8/394/]) patch by slebresne; reviewed by yukim for CASSANDRA-3178 slebresne : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1198725 Files : * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/config/CFMetaData.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/ColumnFamilyStore.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/CounterColumn.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/CounterMutation.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/Memtable.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/compaction/CompactionController.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/compaction/LazilyCompactedRow.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/compaction/PrecompactedRow.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/context/CounterContext.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/StorageProxy.java * /cassandra/branches/cassandra-0.8/test/unit/org/apache/cassandra/db/CounterMutationTest.java * /cassandra/branches/cassandra-0.8/test/unit/org/apache/cassandra/db/context/CounterContextTest.java Counter shard merging is not thread safe Key: CASSANDRA-3178 URL: https://issues.apache.org/jira/browse/CASSANDRA-3178 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.5 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Labels: counters Fix For: 0.8.8, 1.0.3 Attachments: 0001-Move-shard-merging-completely-to-compaction-1.0.patch, 0001-Move-shard-merging-completely-to-compaction-v2.patch, 0001-Move-shard-merging-completely-to-compaction.patch, 0002-Simplify-improve-shard-merging-code-1.0.patch, 0002-Simplify-improve-shard-merging-code-v2.patch, 0002-Simplify-improve-shard-merging-code.patch The first part of the counter shard merging process is done during counter replication. This was done there because it requires that all replica are made aware of the merging (we could only rely on nodetool repair for that but that seems much too fragile, it's better as just a safety net). However this part isn't thread safe as multiple threads can do the merging for the same shard at the same time (which shouldn't really corrupt the counter value per se, but result in an incorrect context). Synchronizing that part of the code would be very costly in term of performance, so instance I propose to move the part of the shard merging done during replication to compaction. It's a better place anyway. The only downside is that it means compaction will sometime send mutations to other node as a side effect, which doesn't feel very clean but is probably not a big deal either. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3410) inconsistent rejection of CL.ANY on reads
[ https://issues.apache.org/jira/browse/CASSANDRA-3410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145676#comment-13145676 ] Hudson commented on CASSANDRA-3410: --- Integrated in Cassandra #1191 (See [https://builds.apache.org/job/Cassandra/1191/]) reject CL.ANY range scans as well as single/multi-row gets patch by jbellis; reviewed by slebresne for CASSANDRA-3410 jbellis : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1198828 Files : * /cassandra/trunk/NEWS.txt * /cassandra/trunk/src/java/org/apache/cassandra/service/ReadCallback.java * /cassandra/trunk/src/java/org/apache/cassandra/thrift/CassandraServer.java * /cassandra/trunk/src/java/org/apache/cassandra/thrift/ThriftValidation.java inconsistent rejection of CL.ANY on reads - Key: CASSANDRA-3410 URL: https://issues.apache.org/jira/browse/CASSANDRA-3410 Project: Cassandra Issue Type: Bug Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 1.1 Attachments: 3410.txt -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3450) maybeInit in ColumnFamilyRecordReader can cause rows to be empty but not null
[
https://issues.apache.org/jira/browse/CASSANDRA-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13144470#comment-13144470
]
Hudson commented on CASSANDRA-3450:
---
Integrated in Cassandra-0.8 #393 (See
[https://builds.apache.org/job/Cassandra-0.8/393/])
Fix empty row filtering and check if there are no rows returned.
Patch by Lanny Ripple, reviewed by brandonwilliams for CASSANDRA-3450
brandonwilliams :
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1197786
Files :
* /cassandra/branches/cassandra-0.8/CHANGES.txt
*
/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java
maybeInit in ColumnFamilyRecordReader can cause rows to be empty but not null
-
Key: CASSANDRA-3450
URL: https://issues.apache.org/jira/browse/CASSANDRA-3450
Project: Cassandra
Issue Type: Bug
Components: Hadoop
Affects Versions: 0.8.7, 1.0.1
Reporter: Lanny Ripple
Assignee: Lanny Ripple
Fix For: 0.8.8, 1.0.3
Attachments: v1-0001-CASSANDRA-3450.txt
1) In {{ColumnFamilyRecordReader}} {{isPredicateEmpty}} needs bracing to
correctly place the {{else if}} to the properly controlling {{if}}.
1a) {{isPredicateEmpty}} should use an || in the getSlice_range predicate
rather than .
2) In {{ColumnFamilyRecordReader}} {{computeNext()}} calls {{maybeInit()}}
and then if {{ros}} is not null it is indexed into. {{maybeInit()}} could
fetch new data, determine the associated slice predicate is empty, and end up
removing all the rows if all columns turned out to be empty. There is no
check for {{rows.isEmpty()}} after the possible removal of all rows.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3415) show schema fails
[
https://issues.apache.org/jira/browse/CASSANDRA-3415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13142973#comment-13142973
]
Hudson commented on CASSANDRA-3415:
---
Integrated in Cassandra-0.8 #392 (See
[https://builds.apache.org/job/Cassandra-0.8/392/])
fix displaying cfdef entries for super columnfamilies
patch by jbellis for CASSANDRA-3415
jbellis :
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1196956
Files :
* /cassandra/branches/cassandra-0.8/CHANGES.txt
*
/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/cli/CliClient.java
show schema fails
-
Key: CASSANDRA-3415
URL: https://issues.apache.org/jira/browse/CASSANDRA-3415
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 0.8.4
Environment: freebsd
Reporter: Radim Kolar
Assignee: Jonathan Ellis
Priority: Minor
Fix For: 0.8.8, 1.0.2
following command breaks show schema cli command with error A long is
exactly 8 bytes: 5
create column family resultcache with column_type = 'Super' and comparator =
'LongType' and key_validation_class = 'UTF8Type' and subcomparator =
'AsciiType' and replicate_on_write = false and rows_cached = 700 and
keys_cached = 3 and key_cache_save_period = 0 and column_metadata = [
{column_name: id, validation_class: LongType}, {column_name: name,
validation_class: 'AsciiType'}, {column_name: crc32, validation_class:
LongType}, {column_name: size, validation_class: LongType} ];
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3116) Compactions can (seriously) delay schema migrations
[ https://issues.apache.org/jira/browse/CASSANDRA-3116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13140328#comment-13140328 ] Hudson commented on CASSANDRA-3116: --- Integrated in Cassandra #1177 (See [https://builds.apache.org/job/Cassandra/1177/]) replace compactionlock use in schema migration by checking CFS.isInvalidD patch by jbellis; reviewed by slebresne for CASSANDRA-3116 jbellis : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1195542 Files : * /cassandra/trunk/CHANGES.txt * /cassandra/trunk/src/java/org/apache/cassandra/db/ColumnFamilyStore.java * /cassandra/trunk/src/java/org/apache/cassandra/db/DataTracker.java * /cassandra/trunk/src/java/org/apache/cassandra/db/Memtable.java * /cassandra/trunk/src/java/org/apache/cassandra/db/Table.java * /cassandra/trunk/src/java/org/apache/cassandra/db/compaction/CompactionManager.java * /cassandra/trunk/src/java/org/apache/cassandra/db/index/SecondaryIndex.java * /cassandra/trunk/src/java/org/apache/cassandra/db/index/SecondaryIndexManager.java * /cassandra/trunk/src/java/org/apache/cassandra/db/index/keys/KeysIndex.java * /cassandra/trunk/src/java/org/apache/cassandra/db/migration/DropColumnFamily.java * /cassandra/trunk/src/java/org/apache/cassandra/db/migration/DropKeyspace.java * /cassandra/trunk/src/java/org/apache/cassandra/io/sstable/SSTableReader.java * /cassandra/trunk/test/unit/org/apache/cassandra/db/KeyCacheTest.java * /cassandra/trunk/test/unit/org/apache/cassandra/db/compaction/CompactionsTest.java * /cassandra/trunk/test/unit/org/apache/cassandra/streaming/StreamingTransferTest.java Compactions can (seriously) delay schema migrations --- Key: CASSANDRA-3116 URL: https://issues.apache.org/jira/browse/CASSANDRA-3116 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.0 Reporter: Eric Evans Assignee: Jonathan Ellis Labels: compaction Fix For: 1.1 Attachments: 3116-v2.txt, 3116-v3.txt, 3116.txt A compaction lock is acquired when dropping keyspaces or column families which will cause the schema migration to block if a compaction is in progress. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3399) Truncate disregards running compactions when deleting sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-3399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13140722#comment-13140722 ] Hudson commented on CASSANDRA-3399: --- Integrated in Cassandra-0.8 #391 (See [https://builds.apache.org/job/Cassandra-0.8/391/]) acquire compactionlock during truncate patch by jbellis; reviewed by slebresne for CASSANDRA-3399 jbellis : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1195695 Files : * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/compaction/CompactionManager.java Truncate disregards running compactions when deleting sstables -- Key: CASSANDRA-3399 URL: https://issues.apache.org/jira/browse/CASSANDRA-3399 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.0 Reporter: Sylvain Lebresne Assignee: Jonathan Ellis Fix For: 0.8.8, 1.0.2 Attachments: 3399.txt All truncation do is `cfs.markCompacted(truncatedSSTables)` without holding any lock or anything. Which have the effect of actually deleting sstables that may be compacting. More precisely there is three problems: # It removes those compacting sstables from the current set of active sstables for the cfs. But when they are done compacting, DataTracker.replaceCompactedSSTables() will be called and it assumes that the compacted sstable are parts of the current set of active sstables. In other words, we'll get an exception looking like the one of CASSANDRA-3306. # The result of the compaction will be added as a new active sstable (actually no, because the code will throw an exception before because of the preceding point, but that's something we should probably deal with). # Currently, compaction don't 'acquire references' on SSTR. That's because the code assumes we won't compact twice the same sstable and that compaction is the only mean to delete an sstable. With these two assumption, acquiring references is not necessary, but truncate break that first assumption. As for solution, I see two possibilities: # make the compaction lock be per-cf instead of global (which I think is easy and a good idea anyway) and grab the write lock to do the markCompacted call. The big downside is that truncation will potentially take much longer. # had two phases: mark the sstable that are not compacting as compacted and set the dataTracker as 'truncated at', and let it deal with the other sstable when their compaction is done. A bit like what is proposed for CASSANDRA-3116 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3405) Row cache provider reported wrong in cassandra-cli
[ https://issues.apache.org/jira/browse/CASSANDRA-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13139767#comment-13139767 ] Hudson commented on CASSANDRA-3405: --- Integrated in Cassandra-0.8 #390 (See [https://builds.apache.org/job/Cassandra-0.8/390/]) CFMetaData.convertToThrift method to set RowCacheProvider patch by Marcus Eriksson; reviewed by Pavel Yaskevich for CASSANDRA-3405 xedin : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1195218 Files : * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/config/CFMetaData.java Row cache provider reported wrong in cassandra-cli -- Key: CASSANDRA-3405 URL: https://issues.apache.org/jira/browse/CASSANDRA-3405 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.7 Reporter: Marcus Eriksson Assignee: Marcus Eriksson Priority: Minor Fix For: 0.8.8 Attachments: 3405.patch When doing show schema; in the CLI, the row_cache_provider is reported as ConcurrentLinkedHashCacheProvider while it really is SerializingCacheProvider Same goes for describe keyspace (after CASSANDRA-3384) on the 0.8 branch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3414) Not possible to change row_cache_provider on existing cf
[ https://issues.apache.org/jira/browse/CASSANDRA-3414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13138437#comment-13138437 ] Hudson commented on CASSANDRA-3414: --- Integrated in Cassandra-0.8 #389 (See [https://builds.apache.org/job/Cassandra-0.8/389/]) fix updating CF row_cache_provider patch by Marcus Eriksson; reviewed by jbellis for CASSANDRA-3414 jbellis : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1190282 Files : * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/config/CFMetaData.java Not possible to change row_cache_provider on existing cf Key: CASSANDRA-3414 URL: https://issues.apache.org/jira/browse/CASSANDRA-3414 Project: Cassandra Issue Type: Bug Affects Versions: 0.8.0 Reporter: Marcus Eriksson Assignee: Marcus Eriksson Priority: Minor Fix For: 0.8.8 Attachments: 3414.patch row_cache_provider is not possible to change using update column family xyz with row_cache_provider='something' in 0.8 It does work in 1.0.0 Reason is that the field is not added to the avro record, patch attached fixes 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] [Commented] (CASSANDRA-3420) test run from ant
[ https://issues.apache.org/jira/browse/CASSANDRA-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13139108#comment-13139108 ] Hudson commented on CASSANDRA-3420: --- Integrated in Cassandra #1176 (See [https://builds.apache.org/job/Cassandra/1176/]) run cassandra from ant Patch by eevans; reviewed by jbellis for CASSANDRA-3420 eevans : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1190745 Files : * /cassandra/trunk/build.xml test run from ant - Key: CASSANDRA-3420 URL: https://issues.apache.org/jira/browse/CASSANDRA-3420 Project: Cassandra Issue Type: Improvement Components: Core, Tests Affects Versions: 1.0.0 Reporter: Eric Evans Assignee: Eric Evans Priority: Minor Attachments: v1-0001-CASSANDRA-3420-run-cassandra-from-ant.txt, v2-0001-CASSANDRA-3420-run-cassandra-from-ant.txt We have everything all setup to run a test node on localhost:9170, why not create an ant target to do that? Patch to follow. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3400) ConcurrentModificationException during nodetool repair
[ https://issues.apache.org/jira/browse/CASSANDRA-3400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13135297#comment-13135297 ] Hudson commented on CASSANDRA-3400: --- Integrated in Cassandra-0.8 #388 (See [https://builds.apache.org/job/Cassandra-0.8/388/]) Fix race in AntiEntropyService patch by slebresne; reviewed by jbellis for CASSANDRA-3400 slebresne : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1188740 Files : * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/AntiEntropyService.java ConcurrentModificationException during nodetool repair -- Key: CASSANDRA-3400 URL: https://issues.apache.org/jira/browse/CASSANDRA-3400 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.7, 1.0.0 Environment: Suse Enterprise linux 11.4 Reporter: Scott Fines Assignee: Sylvain Lebresne Priority: Minor Fix For: 0.8.8, 1.0.1 Attachments: 3400.patch When running a nodetool repair, the following exception can be thrown: ERROR [AntiEntropySessions:12] 2011-10-24 11:17:52,154 AbstractCassandraDaemon.java (line 139) Fatal exception in thread Thread[AntiEntropySessions:12,5,RMI Runtime] java.lang.RuntimeException: java.util.ConcurrentModificationException at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:34) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Caused by: java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793) at java.util.HashMap$KeyIterator.next(HashMap.java:828) at org.apache.cassandra.service.AntiEntropyService$RepairSession$RepairJob.sendTreeRequests(AntiEntropyService.java:784) at org.apache.cassandra.service.AntiEntropyService$RepairSession.runMayThrow(AntiEntropyService.java:680) at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) ... 6 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3390) ReadResponseSerializer.serializedSize() calculation is wrong
[
https://issues.apache.org/jira/browse/CASSANDRA-3390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13134613#comment-13134613
]
Hudson commented on CASSANDRA-3390:
---
Integrated in Cassandra-0.8 #387 (See
[https://builds.apache.org/job/Cassandra-0.8/387/])
remove incorrect optimization from slice read path
patch by jbellis; reviewed by slebresne for CASSANDRA-3390
jbellis :
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1188353
Files :
* /cassandra/branches/cassandra-0.8/CHANGES.txt
*
/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
ReadResponseSerializer.serializedSize() calculation is wrong
Key: CASSANDRA-3390
URL: https://issues.apache.org/jira/browse/CASSANDRA-3390
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.0.1
Reporter: Yang Yang
Assignee: Jonathan Ellis
Fix For: 0.8.8, 1.0.1
Attachments: 3390.patch, 3390.txt
in ReadResponse.java
the following code
public long serializedSize(ReadResponse response, int version)
{
int size = DBConstants.intSize;
size += (response.isDigestQuery() ? response.digest() :
ByteBufferUtil.EMPTY_BYTE_BUFFER).remaining();
size += DBConstants.boolSize;
if (response.isDigestQuery())
size += response.digest().remaining();
else
size += Row.serializer().serializedSize(response.row(), version);
return size;
}
adds the digest size 2 times
this triggers assertion error in at least ReadVerbHandler
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3369) AssertionError when adding a node and doing repair, repair hangs
[
https://issues.apache.org/jira/browse/CASSANDRA-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13132769#comment-13132769
]
Hudson commented on CASSANDRA-3369:
---
Integrated in Cassandra-0.8 #384 (See
[https://builds.apache.org/job/Cassandra-0.8/384/])
fix assertion error during repair with ordered partitioners
patch by slebresne; reviewed by jbellis for CASSANDRA-3369
slebresne :
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1187333
Files :
* /cassandra/branches/cassandra-0.8/CHANGES.txt
*
/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/io/sstable/SSTableReader.java
*
/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/AntiEntropyService.java
AssertionError when adding a node and doing repair, repair hangs
Key: CASSANDRA-3369
URL: https://issues.apache.org/jira/browse/CASSANDRA-3369
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.8.7, 1.0.0
Environment: Ubuntu Linux amd64, 1.0.0-rc2
Reporter: Christian Spriegel
Assignee: Sylvain Lebresne
Fix For: 0.8.8, 1.0.1
Attachments: 3369.patch, NODE1_cassandra.yaml, NODE1_system.log,
NODE2_cassandra.yaml, NODE2_system.log
Hi again,
I was playing aroung with Cassandra 1.0.0-rc2 and got an AssertionError. The
cluster I set up was two cassandra nodes on one laptop using different
127.0.0.* loopback devices. Both nodes have separate folders on the harddisk.
Here is what I did:
1. Started node1 and inserted some data into it using a simple singlethreaded
testprogram (uses hector 0.8.0-2):
127.0.0.1 datacenter1 rack1 Up Normal 583.55 MB
100.00% Token(bytes[63e5b6995466cd3221cba16646ae19ed])
2. I started another node, node 2 = 127.0.0.2:
127.0.0.2 datacenter1 rack1 Up Normal 147.57 KB 50.00%
Token(bytes[4d6ccfeaa8bb59551751a2816fde9343])
127.0.0.1 datacenter1 rack1 Up Normal 583.55 MB 50.00%
Token(bytes[63e5b6995466cd3221cba16646ae19ed])
3. I triggered a nodetool -h 127.0.0.1 repair on the first node that had
the data from my test.
This repair does not seem to ever end. The nodetool is hanging now but my
computer is idle. I get an AssertionError on the first node:
java.lang.AssertionError
at
org.apache.cassandra.service.AntiEntropyService$Validator.prepare(AntiEntropyService.java:283)
at
org.apache.cassandra.db.compaction.CompactionManager.doValidationCompaction(CompactionManager.java:825)
at
org.apache.cassandra.db.compaction.CompactionManager.access$600(CompactionManager.java:63)
at
org.apache.cassandra.db.compaction.CompactionManager$6.call(CompactionManager.java:432)
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)
Update: I dont know if it is important but here is the schema of my test:
create keyspace Test with placement_strategy =
'org.apache.cassandra.locator.SimpleStrategy' and strategy_options =
{replication_factor:2};
CREATE COLUMN FAMILY Response WITH key_validation_class=BytesType AND
compression_options={sstable_compression:DeflateCompressor};
kind regards,
Christian
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3391) CFM.toAvro() incorrectly serialises key_validation_class defn
[
https://issues.apache.org/jira/browse/CASSANDRA-3391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13132770#comment-13132770
]
Hudson commented on CASSANDRA-3391:
---
Integrated in Cassandra-0.8 #384 (See
[https://builds.apache.org/job/Cassandra-0.8/384/])
Correctly serialize key_validation_class for avro
patch by amorton; reviewed by slebresne for CASSANDRA-3391
slebresne :
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1187339
Files :
* /cassandra/branches/cassandra-0.8/CHANGES.txt
*
/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/config/CFMetaData.java
CFM.toAvro() incorrectly serialises key_validation_class defn
-
Key: CASSANDRA-3391
URL: https://issues.apache.org/jira/browse/CASSANDRA-3391
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.0
Reporter: Aaron Morton
Assignee: Aaron Morton
Priority: Minor
Fix For: 0.8.8, 1.0.1
Attachments: 0001-3391-fix.patch
see http://www.mail-archive.com/user@cassandra.apache.org/msg18132.html
Repo with
{code}
create keyspace Stats with placement_strategy =
'org.apache.cassandra.locator.SimpleStrategy' and
strategy_options={replication_factor:1};
use Stats;
create column family Sample_Stats with
default_validation_class=CounterColumnType
and key_validation_class='CompositeType(UTF8Type,UTF8Type)'
and comparator='CompositeType(UTF8Type, UTF8Type)'
and replicate_on_write=true;
[default@Stats] describe cluster;
Cluster Information:
Snitch: org.apache.cassandra.locator.SimpleSnitch
Partitioner: org.apache.cassandra.dht.RandomPartitioner
Schema versions:
1d39bbf0-fb60-11e0--242d50cf1ffd: [127.0.0.1]
{code}
Stop and restart the node
{code:java}
ERROR 10:12:22,729 Exception encountered during startup
java.lang.RuntimeException: Could not inflate CFMetaData for {keyspace:
Stats, name: Sample_Stats, column_type: Standard,
comparator_type:
org.apache.cassandra.db.marshal.CompositeType(org.apache.cassandra.db.marshal.UTF8Type,org.apache.cassandra.db.marshal.UTF8Type),
subcomparator_type: null, comment: , row_cache_size: 0.0,
key_cache_size: 20.0, read_repair_chance: 1.0, replicate_on_write:
true, gc_grace_seconds: 864000, default_validation_class:
org.apache.cassandra.db.marshal.CounterColumnType, key_validation_class:
org.apache.cassandra.db.marshal.CompositeType, min_compaction_threshold:
4, max_compaction_threshold: 32, row_cache_save_period_in_seconds: 0,
key_cache_save_period_in_seconds: 14400, row_cache_keys_to_save:
2147483647, merge_shards_chance: 0.1, id: 1000, column_metadata: [],
row_cache_provider:
org.apache.cassandra.cache.ConcurrentLinkedHashCacheProvider, key_alias:
null, compaction_strategy:
org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy,
compaction_strategy_options: {}, compression_options: {}}
at org.apache.cassandra.config.CFMetaData.fromAvro(CFMetaData.java:362)
at org.apache.cassandra.config.KSMetaData.fromAvro(KSMetaData.java:193)
at org.apache.cassandra.db.DefsTable.loadFromStorage(DefsTable.java:99)
at
org.apache.cassandra.config.DatabaseDescriptor.loadSchemas(DatabaseDescriptor.java:502)
at
org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:161)
at
org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:337)
at
org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:106)
Caused by: org.apache.cassandra.config.ConfigurationException: Invalid
definition for comparator org.apache.cassandra.db.marshal.CompositeType.
at
org.apache.cassandra.db.marshal.TypeParser.getRawAbstractType(TypeParser.java:319)
at
org.apache.cassandra.db.marshal.TypeParser.getAbstractType(TypeParser.java:247)
at org.apache.cassandra.db.marshal.TypeParser.parse(TypeParser.java:83)
at org.apache.cassandra.db.marshal.TypeParser.parse(TypeParser.java:92)
at org.apache.cassandra.config.CFMetaData.fromAvro(CFMetaData.java:358)
... 6 more
Caused by: org.apache.cassandra.config.ConfigurationException: Nonsensical
empty parameter list for CompositeType
at
org.apache.cassandra.db.marshal.CompositeType.getInstance(CompositeType.java:67)
at
org.apache.cassandra.db.marshal.CompositeType.getInstance(CompositeType.java:61)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at
[jira] [Commented] (CASSANDRA-3394) AssertionError in PrecompactedRow.write via CommutativeRowIndexer during bootstrap
[
https://issues.apache.org/jira/browse/CASSANDRA-3394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13133009#comment-13133009
]
Hudson commented on CASSANDRA-3394:
---
Integrated in Cassandra-0.8 #385 (See
[https://builds.apache.org/job/Cassandra-0.8/385/])
Don't expire counter tombstones after streaming
patch by slebresne; reviewed by jbellis for CASSANDRA-3394
slebresne :
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1187477
Files :
* /cassandra/branches/cassandra-0.8/CHANGES.txt
*
/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/io/sstable/SSTableWriter.java
AssertionError in PrecompactedRow.write via CommutativeRowIndexer during
bootstrap
--
Key: CASSANDRA-3394
URL: https://issues.apache.org/jira/browse/CASSANDRA-3394
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.8.7
Reporter: paul cannon
Assignee: Sylvain Lebresne
Fix For: 0.8.8, 1.0.1
Attachments:
0001-Don-t-expire-tombstones-in-CommutativeRowIndexer.patch
{noformat}
ERROR [CompactionExecutor:5] 2011-10-21 15:48:16,138
AbstractCassandraDaemon.java (line 139) Fatal exception in thread
Thread[CompactionExecutor:5,1,main]
java.lang.AssertionError
at
org.apache.cassandra.db.compaction.PrecompactedRow.write(PrecompactedRow.java:107)
at
org.apache.cassandra.io.sstable.SSTableWriter$CommutativeRowIndexer.doIndexing(SSTableWriter.java:514)
at
org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.index(SSTableWriter.java:359)
at
org.apache.cassandra.io.sstable.SSTableWriter$Builder.build(SSTableWriter.java:314)
at
org.apache.cassandra.db.compaction.CompactionManager$9.call(CompactionManager.java:1118)
at
org.apache.cassandra.db.compaction.CompactionManager$9.call(CompactionManager.java:1109)
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)
{noformat}
{{sylvain The bug is that the compacted row was gcing *every* tombstones
instead of none.}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3386) Avoid lock contention in hint rows
[ https://issues.apache.org/jira/browse/CASSANDRA-3386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13131714#comment-13131714 ] Hudson commented on CASSANDRA-3386: --- Integrated in Cassandra-0.8 #383 (See [https://builds.apache.org/job/Cassandra-0.8/383/]) avoid locking on update when no indexes are involved patch by jbellis; reviewed by slebrense for CASSANDRA-3386 jbellis : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1186803 Files : * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/Table.java Avoid lock contention in hint rows -- Key: CASSANDRA-3386 URL: https://issues.apache.org/jira/browse/CASSANDRA-3386 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.0 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Fix For: 0.8.8, 1.0.1 Attachments: 3386.txt As pointed out by Yang in CASSANDRA-3385, hint writes are keyed by target IP, to make replay efficient. However, this means that we'll hit a lot of lock contention in table.apply where we synchronize for potential index updates. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3292) creating column family sets durable_writes to true
[ https://issues.apache.org/jira/browse/CASSANDRA-3292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13130415#comment-13130415 ] Hudson commented on CASSANDRA-3292: --- Integrated in Cassandra-0.8 #380 (See [https://builds.apache.org/job/Cassandra-0.8/380/]) finish fixing changing durable_writes keyspace option during CF creation patch by jbellis; reviewed by pyaskevich for CASSANDRA-3292 add KSM.systemKeyspace and cloneWith methods patch by jbellis; reviewed by pyaskevich for CASSANDRA-3292 jbellis : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1185963 Files : * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/config/DatabaseDescriptor.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/config/KSMetaData.java * /cassandra/branches/cassandra-0.8/test/unit/org/apache/cassandra/SchemaLoader.java * /cassandra/branches/cassandra-0.8/test/unit/org/apache/cassandra/config/DatabaseDescriptorTest.java * /cassandra/branches/cassandra-0.8/test/unit/org/apache/cassandra/db/DefsTest.java jbellis : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1185961 Files : * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/config/DatabaseDescriptor.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/config/KSMetaData.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/migration/AddColumnFamily.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/migration/DropColumnFamily.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/migration/UpdateKeyspace.java creating column family sets durable_writes to true -- Key: CASSANDRA-3292 URL: https://issues.apache.org/jira/browse/CASSANDRA-3292 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.5 Reporter: Radim Kolar Assignee: Jonathan Ellis Priority: Minor Labels: schema Fix For: 0.8.8 Attachments: 0001-r-m-rename-migrations.patch, 0002-clean-up-KSM.durableWrites.patch, 0003-cloneWith.patch, 0004-update-tests-to-use-KSM.testMetadata.patch [default@rapidshare] describe keyspace rapidshare; Keyspace: rapidshare: Replication Strategy: org.apache.cassandra.locator.NetworkTopologyStrategy Durable Writes: *false* Options: [datacenter1:1] Column Families: [default@rapidshare] create column family t1; 1ba19300-ebfa-11e0--34912694d0bf Waiting for schema agreement... ... schemas agree across the cluster [default@rapidshare] describe keyspace rapidshare; Keyspace: rapidshare: Replication Strategy: org.apache.cassandra.locator.NetworkTopologyStrategy Durable Writes: *true* Options: [datacenter1:1] Column Families: ColumnFamily: t1 Key Validation Class: org.apache.cassandra.db.marshal.BytesType Default column value validator: org.apache.cassandra.db.marshal.BytesType Columns sorted by: org.apache.cassandra.db.marshal.BytesType Row cache size / save period in seconds: 0.0/0 Key cache size / save period in seconds: 20.0/14400 Memtable thresholds: 0.0281249997/1440/6 (millions of ops/minutes/MB) GC grace seconds: 864000 Compaction min/max thresholds: 4/32 Read repair chance: 1.0 Replicate on write: true Built indexes: [] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3377) correct dropped messages logging
[ https://issues.apache.org/jira/browse/CASSANDRA-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13130640#comment-13130640 ] Hudson commented on CASSANDRA-3377: --- Integrated in Cassandra-0.8 #381 (See [https://builds.apache.org/job/Cassandra-0.8/381/]) correct dropped messages logging patch by jbellis; reviewed by brandonwilliams for CASSANDRA-3377 jbellis : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1186204 Files : * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/net/MessagingService.java correct dropped messages logging Key: CASSANDRA-3377 URL: https://issues.apache.org/jira/browse/CASSANDRA-3377 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.4 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Labels: logging Fix For: 0.8.8, 1.0.1 Attachments: 3377.txt CASSANDRA-3004 switched MessagingService back to logging only recent dropped messages instead of server lifetime totals, but the log message was not updated. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3384) it would be nice if describe keyspace in cli shows Cache Provider
[ https://issues.apache.org/jira/browse/CASSANDRA-3384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13131157#comment-13131157 ] Hudson commented on CASSANDRA-3384: --- Integrated in Cassandra-0.8 #382 (See [https://builds.apache.org/job/Cassandra-0.8/382/]) CLI `describe keyspace ks` to show Row Cache Provider patch by Pavel Yaskevich; reviewed by Brandon Williams for CASSANDRA-3384 xedin : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1186429 Files : * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/cli/CliClient.java it would be nice if describe keyspace in cli shows Cache Provider - Key: CASSANDRA-3384 URL: https://issues.apache.org/jira/browse/CASSANDRA-3384 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.8.4 Environment: JVM on Linux Reporter: Vijay Assignee: Pavel Yaskevich Priority: Minor Labels: lhf Fix For: 0.8.8, 1.0.1 Attachments: CASSANDRA-3384.patch Describe keyspace in the cli doesn't show the cache provider it would be nice to show it to verify the settings. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3272) READ Operation with CL=EACH_QUORUM succeed when a DC is down (RF=3)
[
https://issues.apache.org/jira/browse/CASSANDRA-3272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13129798#comment-13129798
]
Hudson commented on CASSANDRA-3272:
---
Integrated in Cassandra #1160 (See
[https://builds.apache.org/job/Cassandra/1160/])
EACH_QUORUM is only supported for writes
patch by jbellis; reviewed by slebresne for CASSANDRA-3272
jbellis :
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1185669
Files :
* /cassandra/trunk/CHANGES.txt
* /cassandra/trunk/NEWS.txt
* /cassandra/trunk/src/java/org/apache/cassandra/cql/QueryProcessor.java
* /cassandra/trunk/src/java/org/apache/cassandra/thrift/CassandraServer.java
* /cassandra/trunk/src/java/org/apache/cassandra/thrift/RequestType.java
* /cassandra/trunk/src/java/org/apache/cassandra/thrift/ThriftValidation.java
READ Operation with CL=EACH_QUORUM succeed when a DC is down (RF=3)
---
Key: CASSANDRA-3272
URL: https://issues.apache.org/jira/browse/CASSANDRA-3272
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.7.0
Reporter: Jackson Chung
Assignee: Jonathan Ellis
Priority: Minor
Fix For: 1.1
Attachments: 3272-v2.txt, 3272.txt
READ EACH_QUORUM:Returns the record with the most recent timestamp once
a quorum of replicas in each data center of the cluster has responded.
In other words, if a DC is down and the QUORUM could not be reached on that
DC, read should fail.
test case:
- Cassandra version 0.8.6:
INFO [main] 2011-09-28 22:26:24,297 StorageService.java (line 371) Cassandra
version: 0.8.6
- 6-node cluster with 2 DC and 3 node each. RF=3 in each DC:
[default@Keyspace3] describe keyspace;
Keyspace: Keyspace3:
Replication Strategy: org.apache.cassandra.locator.NetworkTopologyStrategy
Durable Writes: true
Options: [DC2:3, DC1:3]
Column Families:
ColumnFamily: test
Key Validation Class: org.apache.cassandra.db.marshal.BytesType
Default column value validator: org.apache.cassandra.db.marshal.BytesType
Columns sorted by: org.apache.cassandra.db.marshal.BytesType
Row cache size / save period in seconds: 0.0/0
Key cache size / save period in seconds: 20.0/14400
Memtable thresholds: 1.0875/1440/232 (millions of ops/minutes/MB)
GC grace seconds: 864000
Compaction min/max thresholds: 4/32
Read repair chance: 1.0
Replicate on write: true
Built indexes: []
all nodes are up, insert a row:
$ nodetool -h localhost ring
Address DC Rack Status State Load Owns Token
141784319550391026443072753096570088106
10.34.79.179 DC1 RAC1 Up Normal 11.13 KB 16.67% 0
10.34.70.163 DC2 RAC1 Up Normal 11.14 KB 16.67%
28356863910078205288614550619314017621
10.35.81.147 DC1 RAC1 Up Normal 11.14 KB 16.67%
56713727820156410577229101238628035242
10.84.233.170 DC2 RAC1 Up Normal 11.14 KB 16.67%
85070591730234615865843651857942052864
10.195.201.236 DC1 RAC1 Up Normal 11.14 KB 16.67%
113427455640312821154458202477256070485
10.118.147.73 DC2 RAC1 Up Normal 11.14 KB 16.67%
141784319550391026443072753096570088106
- insert a value
[default@Keyspace3] set
test[utf8('test-key-1')][utf8('test-col')]=utf8('test-value');
Value inserted.
sanity check (cli connects to a node in DC1) :
[default@Keyspace3] consistencylevel as EACH_QUORUM;
Consistency level is set to 'EACH_QUORUM'.
[default@Keyspace3] get test[utf8('test-key-1')];
= (column=746573742d636f6c, value=test-value, timestamp=1317249361722000)
Returned 1 results
shut down DC2:
$ nodetool -h localhost ring
Address DC RackStatus State LoadOwns
Token
141784319550391026443072753096570088106
10.34.79.179DC1 RAC1Up Normal 51.86 KB16.67%
0
10.34.70.163DC2 RAC1Down Normal 51.88 KB16.67%
28356863910078205288614550619314017621
10.35.81.147DC1 RAC1Up Normal 47.5 KB 16.67%
56713727820156410577229101238628035242
10.84.233.170 DC2 RAC1Down Normal 51.88 KB16.67%
85070591730234615865843651857942052864
10.195.201.236 DC1 RAC1Up Normal 47.5 KB 16.67%
113427455640312821154458202477256070485
10.118.147.73 DC2 RAC1Down Normal 51.88 KB16.67%
141784319550391026443072753096570088106
[default@Keyspace3] get test[utf8('test-key-1')];
= (column=746573742d636f6c, value=746573742d76616c7565,
timestamp=1317249361722000)
Returned 1 results.
tried with pycassaShell:
[jira] [Commented] (CASSANDRA-3292) creating column family sets durable_writes to true
[ https://issues.apache.org/jira/browse/CASSANDRA-3292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13129907#comment-13129907 ] Hudson commented on CASSANDRA-3292: --- Integrated in Cassandra-0.8 #377 (See [https://builds.apache.org/job/Cassandra-0.8/377/]) r/m obsolete CF/KS rename code patch by jbellis; reviewed by pyaskevich for CASSANDRA-3292 jbellis : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1185761 Files : * /cassandra/branches/cassandra-0.8/src/avro/internode.genavro * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/Table.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/migration/RenameColumnFamily.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/migration/RenameKeyspace.java * /cassandra/branches/cassandra-0.8/test/unit/org/apache/cassandra/db/DefsTest.java creating column family sets durable_writes to true -- Key: CASSANDRA-3292 URL: https://issues.apache.org/jira/browse/CASSANDRA-3292 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.5 Reporter: Radim Kolar Assignee: Jonathan Ellis Priority: Minor Labels: schema Fix For: 0.8.8 Attachments: 0001-r-m-rename-migrations.patch, 0002-clean-up-KSM.durableWrites.patch, 0003-cloneWith.patch, 0004-update-tests-to-use-KSM.testMetadata.patch [default@rapidshare] describe keyspace rapidshare; Keyspace: rapidshare: Replication Strategy: org.apache.cassandra.locator.NetworkTopologyStrategy Durable Writes: *false* Options: [datacenter1:1] Column Families: [default@rapidshare] create column family t1; 1ba19300-ebfa-11e0--34912694d0bf Waiting for schema agreement... ... schemas agree across the cluster [default@rapidshare] describe keyspace rapidshare; Keyspace: rapidshare: Replication Strategy: org.apache.cassandra.locator.NetworkTopologyStrategy Durable Writes: *true* Options: [datacenter1:1] Column Families: ColumnFamily: t1 Key Validation Class: org.apache.cassandra.db.marshal.BytesType Default column value validator: org.apache.cassandra.db.marshal.BytesType Columns sorted by: org.apache.cassandra.db.marshal.BytesType Row cache size / save period in seconds: 0.0/0 Key cache size / save period in seconds: 20.0/14400 Memtable thresholds: 0.0281249997/1440/6 (millions of ops/minutes/MB) GC grace seconds: 864000 Compaction min/max thresholds: 4/32 Read repair chance: 1.0 Replicate on write: true Built indexes: [] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3170) Schema versions output should be on separate lines for separate versions
[ https://issues.apache.org/jira/browse/CASSANDRA-3170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13130119#comment-13130119 ] Hudson commented on CASSANDRA-3170: --- Integrated in Cassandra-0.8 #378 (See [https://builds.apache.org/job/Cassandra-0.8/378/]) CLI `describe cluster;` output should be on separate lines for separate versions patch by Pavel Yaskevich; reviewed by Brandon Williams for CASSANDRA-3170 xedin : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1185907 Files : * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/cli/CliClient.java Schema versions output should be on separate lines for separate versions Key: CASSANDRA-3170 URL: https://issues.apache.org/jira/browse/CASSANDRA-3170 Project: Cassandra Issue Type: Improvement Reporter: Jeremy Hanna Assignee: Pavel Yaskevich Priority: Minor Labels: cli, lhf Fix For: 0.8.8 Attachments: CASSANDRA-3170.patch On the CLI if you do a 'describe cluster;' it would be really nice to have different versions on different lines or some way to call out multiple versions more. Right now it's a UUID with a list of nodes for one, but with multiple versions, it's on the same line - another UUID and another list of nodes. That's hard to distinguish between one version and multiple versions at a glance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3366) CQL: Internal application error specifying 'using consistency ...' in lower case; must be upper case
[ https://issues.apache.org/jira/browse/CASSANDRA-3366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13128790#comment-13128790 ] Hudson commented on CASSANDRA-3366: --- Integrated in Cassandra-0.8 #376 (See [https://builds.apache.org/job/Cassandra-0.8/376/]) (CQL) Fix internal application error specifying 'using consistency ...' in lower case patch by Pavel Yaskevich; reviewed by Jonathan Ellis for CASSANDRA-3366 xedin : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1185091 Files : * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/cql/Cql.g CQL: Internal application error specifying 'using consistency ...' in lower case; must be upper case Key: CASSANDRA-3366 URL: https://issues.apache.org/jira/browse/CASSANDRA-3366 Project: Cassandra Issue Type: Improvement Components: API Affects Versions: 1.0.0 Reporter: Cathy Daw Assignee: Pavel Yaskevich Priority: Trivial Labels: cql Fix For: 1.0.1 Attachments: CASSANDRA-3366.patch Robin hit this error, so I think he would consider it to be a usability issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3126) unable to remove column metadata via CLI
[
https://issues.apache.org/jira/browse/CASSANDRA-3126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13128282#comment-13128282
]
Hudson commented on CASSANDRA-3126:
---
Integrated in Cassandra-0.8 #375 (See
[https://builds.apache.org/job/Cassandra-0.8/375/])
Fix completely removing column metadata using CLI
patch by Pavel Yaskevich; reviewed by Jonathan Ellis for CASSANDRA-3126
xedin : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1183681
Files :
* /cassandra/branches/cassandra-0.8/CHANGES.txt
* /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/cli/Cli.g
*
/cassandra/branches/cassandra-0.8/test/unit/org/apache/cassandra/cli/CliTest.java
unable to remove column metadata via CLI
Key: CASSANDRA-3126
URL: https://issues.apache.org/jira/browse/CASSANDRA-3126
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 0.7.0
Reporter: Radim Kolar
Assignee: Pavel Yaskevich
Priority: Minor
Labels: cassandra-cli
Fix For: 0.8.8
Attachments: CASSANDRA-3126.patch
I cant find way how to remove all columns definitions without CF
import/export.
[default@int4] update column family sipdb with column_metadata = [];
Syntax error at position 51: required (...)+ loop did not match anything at
input ']'
[default@int4] update column family sipdb with column_metadata = [{}];
Command not found: `update column family sipdb with column_metadata = [{}];`.
Type 'help;' or '?' for help.
[default@int4]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3344) Compaction throttling can be too slow
[ https://issues.apache.org/jira/browse/CASSANDRA-3344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13127388#comment-13127388 ] Hudson commented on CASSANDRA-3344: --- Integrated in Cassandra-0.8 #372 (See [https://builds.apache.org/job/Cassandra-0.8/372/]) Only count compaction as active (for throttling) once the compaction lock has been acquired. patch by Fabien Rousseau and slebresne; reviewed by jbellis for CASSANDRA-3344 slebresne : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1183241 Files : * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/compaction/CompactionManager.java Compaction throttling can be too slow - Key: CASSANDRA-3344 URL: https://issues.apache.org/jira/browse/CASSANDRA-3344 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.0 Reporter: Fabien Rousseau Assignee: Sylvain Lebresne Priority: Minor Fix For: 0.8.8, 1.0.1 Attachments: 001-CASSANDRA-3344.patch, 3344.patch, 3344_v2.patch Compaction throttling needs to know how many active compactions are running (to divide bandwith for each active compaction). The way active compaction is counted can be broken because it counts the number of active threads in the executor BUT the thread starts by acquiring a lock. If the lock can't be acquired immediately : the thread is seen as active but does not participate in IO operations. The case can happen when major compaction are triggered (major compaction acquire a write lock, while minor compactions acquire a read lock). Having compaction througput to 16Mb/s, we observed is the following (two times) : - only 1 active compaction (a long one for a few hours) starting at 16Mb/s, then after some time running at 2Mb/s, thus taking a very long time to complete - many pending compactions Using JMX and monitoring the stack trace of the compaction threads showed that : - 1 thread was effectively compacting - 1 thread was waiting to acquire the write lock (due to a major compaction) - 6 threads were waiting to acquire the read lock (probably due to the thread above trying to acquire the write lock) Attached is a proposed patch (very simple, not yet tested) which counts only active compactions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3214) Make CFIF use rpc_endpoint prior to trying endpoint
[ https://issues.apache.org/jira/browse/CASSANDRA-3214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13127868#comment-13127868 ] Hudson commented on CASSANDRA-3214: --- Integrated in Cassandra-0.8 #373 (See [https://builds.apache.org/job/Cassandra-0.8/373/]) Make CFIF use rpc_endpoint prior to trying endpoint. Patch by Eldon Stegall and Scott Fines, reviewed by brandonwilliams for CASSANDRA-3214 brandonwilliams : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1183489 Files : * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/hadoop/ColumnFamilyInputFormat.java Make CFIF use rpc_endpoint prior to trying endpoint --- Key: CASSANDRA-3214 URL: https://issues.apache.org/jira/browse/CASSANDRA-3214 Project: Cassandra Issue Type: Improvement Components: Hadoop Affects Versions: 0.8.6 Environment: Hadoop 0.20 / Cassandra 0.8.5 / Ubuntu 10.04 / Reporter: Eldon Stegall Assignee: Eldon Stegall Priority: Minor Fix For: 0.8.8 Attachments: CASSANDRA-3214-make-cfif-use-rpc-endpoints-v1.txt, CASSANDRA-3214.patch Following up on CASSANDRA-3187 , we probably need to attempt to use the rpc_endpoint address first, and then fall back to the gossip endpoint if we don't get what we want. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3342) cassandra-cli allows setting min_compaction_threshold to 1
[
https://issues.apache.org/jira/browse/CASSANDRA-3342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13127914#comment-13127914
]
Hudson commented on CASSANDRA-3342:
---
Integrated in Cassandra-0.8 #374 (See
[https://builds.apache.org/job/Cassandra-0.8/374/])
ColumnFamily min_compaction_threshold should be = 2
patch by Pavel Yaskevich; reviewed by Brandon Williams for CASSANDRA-3342
xedin : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1183510
Files :
* /cassandra/branches/cassandra-0.8/CHANGES.txt
*
/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/thrift/ThriftValidation.java
cassandra-cli allows setting min_compaction_threshold to 1
--
Key: CASSANDRA-3342
URL: https://issues.apache.org/jira/browse/CASSANDRA-3342
Project: Cassandra
Issue Type: Bug
Components: Tools
Environment: Linux 2.6.32-131.6.1.el6.x86_64 #1 SMP Mon Jun 20
14:15:38 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux (RHEL 6)
Reporter: Jason Baker
Assignee: Pavel Yaskevich
Fix For: 0.8.8, 1.0.1
Attachments: CASSANDRA-3342.patch
{{
[root@Apture] update column family MagicLinks with min_compaction_threshold=1
and max_compaction_threshold=20;
b98e3b80-f3a3-11e0--76abb4a6dbbf
Waiting for schema agreement...
... schemas agree across the cluster
}}
I'm told that a min_compaction_threshold of 1 is nonsensical. I had a spell
where my servers stopped doing compactions. Once I upped the
min_compaction_threshold, they started compacting again. I'm unable to
confirm for sure that this was the case.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3185) Unify support across different map/reduce related classes for comma seperated list of hosts for initial thrift port connection.
[ https://issues.apache.org/jira/browse/CASSANDRA-3185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13127916#comment-13127916 ] Hudson commented on CASSANDRA-3185: --- Integrated in Cassandra-0.8 #374 (See [https://builds.apache.org/job/Cassandra-0.8/374/]) Unify hadoop support for accept CDL for initial thrift address Patch by Eldon Stegall, reviewed by brandonwilliams for CASSANDRA-3185 brandonwilliams : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1183506 Files : * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/contrib/pig/src/java/org/apache/cassandra/hadoop/pig/CassandraStorage.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/client/RingCache.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/hadoop/ColumnFamilyInputFormat.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordWriter.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/hadoop/ConfigHelper.java * /cassandra/branches/cassandra-0.8/test/distributed/org/apache/cassandra/TestBase.java * /cassandra/branches/cassandra-0.8/test/unit/org/apache/cassandra/client/TestRingCache.java Unify support across different map/reduce related classes for comma seperated list of hosts for initial thrift port connection. --- Key: CASSANDRA-3185 URL: https://issues.apache.org/jira/browse/CASSANDRA-3185 Project: Cassandra Issue Type: Improvement Components: Hadoop Affects Versions: 0.8.0 Environment: Hadoop-0.20+pig-0.8 Reporter: Eldon Stegall Assignee: Eldon Stegall Priority: Minor Fix For: 0.8.8 Attachments: unify-comma-seperated-hadoop-initial-thrift-connection-v4.patch Unify support across different map/reduce related classes for comma seperated list of hosts for initial thrift port connection. Column family input format already had support for this since CASSANDRA-2807, and RingCache did it the same way, but it was coded seperately. This JIRA should add pig support, and abstract a common method to iterate over these seeds. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3280) Pig Storage Handler: Add =0.8.1 types, Guess right type for Key in Schema
[
https://issues.apache.org/jira/browse/CASSANDRA-3280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13127915#comment-13127915
]
Hudson commented on CASSANDRA-3280:
---
Integrated in Cassandra-0.8 #374 (See
[https://builds.apache.org/job/Cassandra-0.8/374/])
Add 0.8+ types and key validation type to pig schema.
Patch by Steeve Morin, reviewed by brandonwilliams for CASSANDRA-3280
brandonwilliams :
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1183518
Files :
* /cassandra/branches/cassandra-0.8/CHANGES.txt
*
/cassandra/branches/cassandra-0.8/contrib/pig/src/java/org/apache/cassandra/hadoop/pig/CassandraStorage.java
Pig Storage Handler: Add =0.8.1 types, Guess right type for Key in Schema
--
Key: CASSANDRA-3280
URL: https://issues.apache.org/jira/browse/CASSANDRA-3280
Project: Cassandra
Issue Type: Improvement
Components: Hadoop
Affects Versions: 0.8.1
Reporter: Steeve Morin
Labels: patch
Fix For: 0.8.8
Attachments: new_types_and_key_type.txt, new_types_and_key_type_v2.txt
Various patches in the Pig Storage Handler:
- correctly guess the right Pig type for the Row Key
- add support for FloatType, DoubleType, -UUIDType (as String) and DateType
(as time epoch)- (removed in v2 because it would break when storing data back
in Cassandra)
- add support to specify correct type comparator in SlicePredicate
*SlicePredicate comparator:*
For instance:
{quote}
{{raw = LOAD
'cassandra://ks/cf?slice_start=2.5slice_end=5.3comparator=DoubleType' USING
CassandraStorage() AS ();}}
{quote}
It's an optional parameter. If it's not present, it will default to
BytesType. Which mean you must use hex strings.
Hence {{slice_start=00slice_end=FF}} isn't the same as
{{slice_start=00slice_end=FFcomparator=AsciiType}} !
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3357) SSTableImport/Export don't handle tombstone well if value validation != BytesType
[ https://issues.apache.org/jira/browse/CASSANDRA-3357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13126738#comment-13126738 ] Hudson commented on CASSANDRA-3357: --- Integrated in Cassandra-0.8 #369 (See [https://builds.apache.org/job/Cassandra-0.8/369/]) Fix handling of tombstone by SSTableExport/Import when validation != BytesType patch by slebresne; reviewed by jbellis for CASSANDRA-3357 slebresne : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1182950 Files : * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/tools/SSTableExport.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/tools/SSTableImport.java SSTableImport/Export don't handle tombstone well if value validation != BytesType - Key: CASSANDRA-3357 URL: https://issues.apache.org/jira/browse/CASSANDRA-3357 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.8.7 Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Trivial Fix For: 0.8.8 Attachments: 3357.patch SSTableImport/Export use the value validator even on tomstone, but for those the value is the local deletion time, so this don't necessarily validate (with UTF8Type for instance) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3358) 2GB row size limit in ColumnIndex offset calculation
[ https://issues.apache.org/jira/browse/CASSANDRA-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13126748#comment-13126748 ] Hudson commented on CASSANDRA-3358: --- Integrated in Cassandra-0.7 #554 (See [https://builds.apache.org/job/Cassandra-0.7/554/]) fix ColumnIndexer to use long offsets patch by Thomas Richter; reviewed by jbellis for CASSANDRA-3358 jbellis : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1183000 Files : * /cassandra/branches/cassandra-0.7/CHANGES.txt * /cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/db/ColumnIndexer.java 2GB row size limit in ColumnIndex offset calculation Key: CASSANDRA-3358 URL: https://issues.apache.org/jira/browse/CASSANDRA-3358 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.0 Reporter: Thomas Richter Assignee: Thomas Richter Fix For: 0.7.10, 0.8.8, 1.0.1 Index offset is calculated using int instead of long resulting in overflow at 2GB row size. As a result affected columns can not be retrieved. Fix: use long instead of int -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3196) Cassandra-CLI command should have --version option
[ https://issues.apache.org/jira/browse/CASSANDRA-3196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13127028#comment-13127028 ] Hudson commented on CASSANDRA-3196: --- Integrated in Cassandra-0.8 #371 (See [https://builds.apache.org/job/Cassandra-0.8/371/]) display CLI version string on startup patch by pyaskevich; reviewed by jbellis for CASSANDRA-3196 jbellis : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1183103 Files : * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/cli/CliClient.java Cassandra-CLI command should have --version option -- Key: CASSANDRA-3196 URL: https://issues.apache.org/jira/browse/CASSANDRA-3196 Project: Cassandra Issue Type: Wish Components: Tools Environment: Linux version 2.6.32-5-amd64 (Debian 2.6.32-35) Reporter: Mauri Tikka Assignee: Pavel Yaskevich Priority: Minor Fix For: 0.8.8, 1.0.1 Attachments: CASSANDRA-3196.patch Implementing cassandra-cli --version command line option would make it easier to write bug reports and check the versions of tools in use. Or if you want to make it a CLI command inside the tool, I don't know. --version option seems to be the standard way. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3300) relocate Java (JDBC) CQL driver
[ https://issues.apache.org/jira/browse/CASSANDRA-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13127043#comment-13127043 ] Hudson commented on CASSANDRA-3300: --- Integrated in Cassandra #1156 (See [https://builds.apache.org/job/Cassandra/1156/]) remove driver build/test Patch by eevans; reviewed by jbellis for CASSANDRA-3300 eevans : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1183124 Files : * /cassandra/trunk/build.xml relocate Java (JDBC) CQL driver --- Key: CASSANDRA-3300 URL: https://issues.apache.org/jira/browse/CASSANDRA-3300 Project: Cassandra Issue Type: Task Components: Drivers Reporter: Eric Evans Assignee: Eric Evans Priority: Minor Labels: cql Attachments: v1-0001-CASSANDRA-3300-remove-driver-build-test.txt A new project as been created at http://code.google.com/a/apache-extras.org/p/cassandra-jdbc, a current snapshot of the code from trunk has been imported, and the tests updated. I've configured commit notifications to be sent to commits@cassandra.apache.org, though this can be changed if people object. To the best of my knowledge, the only thing remaining is to configure the initial set of committers and admins. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3353) misc CQL doc fixes
[ https://issues.apache.org/jira/browse/CASSANDRA-3353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13127111#comment-13127111 ] Hudson commented on CASSANDRA-3353: --- Integrated in Cassandra #1157 (See [https://builds.apache.org/job/Cassandra/1157/]) bring term info current w/ recent changes Patch by eevans; reviewed by jbellis for CASSANDRA-3353 minor formatting fixes to doc Patch by eevans; reviewed by jbellis for CASSANDRA-3353 eevans : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1183135 Files : * /cassandra/trunk/doc/cql/CQL.textile eevans : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1183134 Files : * /cassandra/trunk/doc/cql/CQL.textile misc CQL doc fixes -- Key: CASSANDRA-3353 URL: https://issues.apache.org/jira/browse/CASSANDRA-3353 Project: Cassandra Issue Type: Bug Components: Documentation website, Drivers Affects Versions: 1.0.0 Reporter: Eric Evans Assignee: Eric Evans Priority: Minor Labels: cql Fix For: 1.0.1 Attachments: v1-0001-CASSANDRA-3353-minor-formatting-fixes.txt, v1-0002-bring-term-info-current-w-recent-changes.txt See patch to follow for some minor documentation fixes (mostly formatting nits). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3300) relocate Java (JDBC) CQL driver
[ https://issues.apache.org/jira/browse/CASSANDRA-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13127112#comment-13127112 ] Hudson commented on CASSANDRA-3300: --- Integrated in Cassandra #1157 (See [https://builds.apache.org/job/Cassandra/1157/]) remove what remains of the drivers tree Patch by eevans; reviewed by jbellis for CASSANDRA-3300 eevans : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1183130 Files : * /cassandra/trunk/drivers/java/CHANGES.txt * /cassandra/trunk/drivers/java/src/org/apache/cassandra/cql/jdbc/AbstractCassandraConnection.java * /cassandra/trunk/drivers/java/src/org/apache/cassandra/cql/jdbc/AbstractResultSet.java * /cassandra/trunk/drivers/java/src/org/apache/cassandra/cql/jdbc/AbstractStatement.java * /cassandra/trunk/drivers/java/src/org/apache/cassandra/cql/jdbc/CResultSet.java * /cassandra/trunk/drivers/java/src/org/apache/cassandra/cql/jdbc/CassandraConnection.java * /cassandra/trunk/drivers/java/src/org/apache/cassandra/cql/jdbc/CassandraDataSource.java * /cassandra/trunk/drivers/java/src/org/apache/cassandra/cql/jdbc/CassandraDatabaseMetaData.java * /cassandra/trunk/drivers/java/src/org/apache/cassandra/cql/jdbc/CassandraDriver.java * /cassandra/trunk/drivers/java/src/org/apache/cassandra/cql/jdbc/CassandraPreparedStatement.java * /cassandra/trunk/drivers/java/src/org/apache/cassandra/cql/jdbc/CassandraResultSet.java * /cassandra/trunk/drivers/java/src/org/apache/cassandra/cql/jdbc/CassandraRowId.java * /cassandra/trunk/drivers/java/src/org/apache/cassandra/cql/jdbc/CassandraStatement.java * /cassandra/trunk/drivers/java/src/org/apache/cassandra/cql/jdbc/ColumnDecoder.java * /cassandra/trunk/drivers/java/src/org/apache/cassandra/cql/jdbc/DriverResolverException.java * /cassandra/trunk/drivers/java/src/org/apache/cassandra/cql/jdbc/InvalidUrlException.java * /cassandra/trunk/drivers/java/src/org/apache/cassandra/cql/jdbc/TypedColumn.java * /cassandra/trunk/drivers/java/src/org/apache/cassandra/cql/jdbc/Utils.java * /cassandra/trunk/drivers/java/test/conf/cassandra.yaml * /cassandra/trunk/drivers/java/test/conf/log4j-junit.properties * /cassandra/trunk/drivers/java/test/org/apache/cassandra/cql/EmbeddedServiceBase.java * /cassandra/trunk/drivers/java/test/org/apache/cassandra/cql/JdbcDriverTest.java * /cassandra/trunk/drivers/java/test/org/apache/cassandra/cql/jdbc/DataSourceTest.java * /cassandra/trunk/drivers/java/test/org/apache/cassandra/cql/jdbc/PreparedStatementTest.java relocate Java (JDBC) CQL driver --- Key: CASSANDRA-3300 URL: https://issues.apache.org/jira/browse/CASSANDRA-3300 Project: Cassandra Issue Type: Task Components: Drivers Reporter: Eric Evans Assignee: Eric Evans Priority: Minor Labels: cql Attachments: v1-0001-CASSANDRA-3300-remove-driver-build-test.txt A new project as been created at http://code.google.com/a/apache-extras.org/p/cassandra-jdbc, a current snapshot of the code from trunk has been imported, and the tests updated. I've configured commit notifications to be sent to commits@cassandra.apache.org, though this can be changed if people object. To the best of my knowledge, the only thing remaining is to configure the initial set of committers and admins. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3349) NPE on malformed CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-3349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13125923#comment-13125923
]
Hudson commented on CASSANDRA-3349:
---
Integrated in Cassandra-0.8 #367 (See
[https://builds.apache.org/job/Cassandra-0.8/367/])
update CQL grammar to require key clause in delete statement
patch by pyaskevich; reviewed by jbellis for CASSANDRA-3349
jbellis :
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1182411
Files :
* /cassandra/branches/cassandra-0.8/CHANGES.txt
* /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/cql/Cql.g
NPE on malformed CQL
Key: CASSANDRA-3349
URL: https://issues.apache.org/jira/browse/CASSANDRA-3349
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.8.0 beta 2
Reporter: paul cannon
Assignee: Pavel Yaskevich
Labels: lhf
Fix For: 0.8.8, 1.0.1
Attachments: CASSANDRA-3349.patch
It's not clear why, but the CQL grammar specification in Cql.g allows for an
empty WHERE clause on DELETE, i.e.:
{noformat}
DELETE FROM someCF WHERE;
{noformat}
When this is used, with or without a column list, it causes an NPE on the
node processing the CQL. Traceback on a recent 1.0.0 build:
{noformat}
ERROR [pool-2-thread-1] 2011-10-11 15:45:25,655 Cassandra.java (line 4082)
Internal error processing execute_cql_query
java.lang.NullPointerException
at
org.apache.cassandra.cql.CqlParser.deleteStatement(CqlParser.java:1994)
at org.apache.cassandra.cql.CqlParser.query(CqlParser.java:292)
at
org.apache.cassandra.cql.QueryProcessor.getStatement(QueryProcessor.java:984)
at
org.apache.cassandra.cql.QueryProcessor.process(QueryProcessor.java:500)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1268)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.process(Cassandra.java:4072)
at
org.apache.cassandra.thrift.Cassandra$Processor.process(Cassandra.java:2889)
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:680)
{noformat}
The CQL client gets an error with the message, Internal application error.
It might be better to allow leaving off the WHERE as well as the condition,
to match SQL semantics, although fixing that probably won't solve this
problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3350) Can't USE numeric keyspace names in CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-3350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13125922#comment-13125922
]
Hudson commented on CASSANDRA-3350:
---
Integrated in Cassandra-0.8 #367 (See
[https://builds.apache.org/job/Cassandra-0.8/367/])
allow numeric keyspace names in USE statement
patch by pyaskevich; reviewed by jbellis for CASSANDRA-3350
jbellis :
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1182413
Files :
* /cassandra/branches/cassandra-0.8/CHANGES.txt
* /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/cql/Cql.g
*
/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/cql/QueryProcessor.java
Can't USE numeric keyspace names in CQL
---
Key: CASSANDRA-3350
URL: https://issues.apache.org/jira/browse/CASSANDRA-3350
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.8.0 beta 2
Reporter: paul cannon
Assignee: Pavel Yaskevich
Priority: Minor
Labels: lhf
Fix For: 0.8.8, 1.0.1
Attachments: CASSANDRA-3350.patch
Cassandra allows keyspace names to start with a digit or an underscore (see
o.a.c.db.migration.Migration.isLegalName), but CQL's {{USE}} statement only
accepts a CQL identifier, which must start with a letter. So there's no way
to use a keyspace named 142 or \_hi\_ in CQL, for example.
The {{USE}} statement should accept string literals and integers as well as
identifiers, and CQL identifiers ({{IDENT}}) should probably allow starting
with the underscore.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3320) pig_cassandra script errors when running against pig 0.9.1 tar ball because there are multiple jars.
[ https://issues.apache.org/jira/browse/CASSANDRA-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13125979#comment-13125979 ] Hudson commented on CASSANDRA-3320: --- Integrated in Cassandra-0.8 #368 (See [https://builds.apache.org/job/Cassandra-0.8/368/]) Fix pig script to only pick up a single pig jar. Patch by Brian Oneill, reviewed by brandonwilliams for CASSANDRA-3320 brandonwilliams : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1182456 Files : * /cassandra/branches/cassandra-0.8/contrib/pig/bin/pig_cassandra pig_cassandra script errors when running against pig 0.9.1 tar ball because there are multiple jars. Key: CASSANDRA-3320 URL: https://issues.apache.org/jira/browse/CASSANDRA-3320 Project: Cassandra Issue Type: Bug Components: Contrib Affects Versions: 0.8.6 Environment: Running on mac os x. PIG_HOME set to a fresh download of pig 0.9.1. Reporter: Brian ONeill Assignee: Brian ONeill Priority: Minor Fix For: 0.8.8 Attachments: trunk-3320.txt The pig_cassandra script in contrib/pig/bin assumes there is only one pig jar file in $PIG_HOME. However, the latest release of pig 0.9.1 has two jar files: one for hadoop and one without hadoop. See below: bone@zen:~/tools/pig-0.9.1- ls -al *.jar -rw-r--r-- 1 bone staff 5130595 Sep 29 18:55 pig-0.9.1-withouthadoop.jar -rw-r--r-- 1 bone staff 12430153 Sep 29 18:55 pig-0.9.1.jar This breaks the shell script with: bin/pig_cassandra: line 42: [: /Users/bone/tools/pig/pig-0.9.1-withouthadoop.jar: binary operator expected Unrecognized option: -x Attached is a patch for the shell script that takes the last jar file listed in the directory. This fixes the problem. I also add an echo to notify the user which jar file they are using. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2863) NPE when writing SSTable generated via repair
[ https://issues.apache.org/jira/browse/CASSANDRA-2863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13124125#comment-13124125 ] Hudson commented on CASSANDRA-2863: --- Integrated in Cassandra-0.8 #366 (See [https://builds.apache.org/job/Cassandra-0.8/366/]) Make SSTW.RowIndexer.iwriter a final field to avoid NPE patch by slebresne; reviewed by jbellis for CASSANDRA-2863 slebresne : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1180958 Files : * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/io/sstable/SSTableWriter.java NPE when writing SSTable generated via repair - Key: CASSANDRA-2863 URL: https://issues.apache.org/jira/browse/CASSANDRA-2863 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.1 Reporter: Héctor Izquierdo Assignee: Sylvain Lebresne Fix For: 0.8.8 Attachments: 2863-v2.patch, 2863.patch A NPE is generated during repair when closing an sstable generated via SSTable build. It doesn't happen always. The node had been scrubbed and compacted before calling repair. INFO [CompactionExecutor:2] 2011-07-06 11:11:32,640 SSTableReader.java (line 158) Opening /d2/cassandra/data/sbs/walf-g-730 ERROR [CompactionExecutor:2] 2011-07-06 11:11:34,327 AbstractCassandraDaemon.java (line 113) Fatal exception in thread Thread[CompactionExecutor:2,1,main] java.lang.NullPointerException at org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.close(SSTableWriter.java:382) at org.apache.cassandra.io.sstable.SSTableWriter$RowIndexer.index(SSTableWriter.java:370) at org.apache.cassandra.io.sstable.SSTableWriter$Builder.build(SSTableWriter.java:315) at org.apache.cassandra.db.compaction.CompactionManager$9.call(CompactionManager.java:1103) at org.apache.cassandra.db.compaction.CompactionManager$9.call(CompactionManager.java:1094) 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. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3299) clientutil depends on FBUtilities (bad)
[
https://issues.apache.org/jira/browse/CASSANDRA-3299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13124285#comment-13124285
]
Hudson commented on CASSANDRA-3299:
---
Integrated in Cassandra #1150 (See
[https://builds.apache.org/job/Cassandra/1150/])
move FBUtils methods for bytes-hex to separate class
Patch by eevans; reviewed by jbellis for CASSANDRA-3299
eevans : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1181018
Files :
* /cassandra/trunk/build.xml
*
/cassandra/trunk/drivers/java/test/org/apache/cassandra/cql/JdbcDriverTest.java
*
/cassandra/trunk/drivers/java/test/org/apache/cassandra/cql/jdbc/PreparedStatementTest.java
*
/cassandra/trunk/examples/simple_authentication/src/org/apache/cassandra/auth/SimpleAuthenticator.java
* /cassandra/trunk/src/java/org/apache/cassandra/auth/Resources.java
* /cassandra/trunk/src/java/org/apache/cassandra/db/marshal/BytesType.java
*
/cassandra/trunk/src/java/org/apache/cassandra/dht/AbstractByteOrderedPartitioner.java
* /cassandra/trunk/src/java/org/apache/cassandra/dht/BytesToken.java
* /cassandra/trunk/src/java/org/apache/cassandra/hadoop/ConfigHelper.java
* /cassandra/trunk/src/java/org/apache/cassandra/utils/ByteBufferUtil.java
* /cassandra/trunk/src/java/org/apache/cassandra/utils/FBUtilities.java
* /cassandra/trunk/src/java/org/apache/cassandra/utils/Hex.java
* /cassandra/trunk/src/java/org/apache/cassandra/utils/MerkleTree.java
* /cassandra/trunk/test/unit/org/apache/cassandra/db/marshal/RoundTripTest.java
* /cassandra/trunk/test/unit/org/apache/cassandra/utils/FBUtilitiesTest.java
* /cassandra/trunk/test/unit/org/apache/cassandra/utils/HexTest.java
* /cassandra/trunk/test/unit/org/apache/cassandra/utils/MerkleTreeTest.java
clientutil depends on FBUtilities (bad)
---
Key: CASSANDRA-3299
URL: https://issues.apache.org/jira/browse/CASSANDRA-3299
Project: Cassandra
Issue Type: Bug
Components: API, Drivers
Affects Versions: 1.0.0
Reporter: Eric Evans
Assignee: Eric Evans
Labels: cql
Fix For: 1.0.1
Attachments:
v1-0001-CASSANDRA-3299-move-FBUtils-methods-for-bytes-hex-to-s.txt
clientutils' (indirect )dependency on FBUtilities (needed for tests) would
result in huge numbers of classes being pulled in transitively.
The attached patch moves the {{bytesToHex}} and {{hexToBytes}} methods into a
new class ({{o.a.c.utils.Hex}}), which has no external dependencies.
This should be pretty safe, but I've marked it fixfor-1.0.1 since we're so
close to release, and because the JDBC driver can embed a snapshot jar in the
meantime.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3312) need initClause when catch Exception and throw new Exception in cli
[
https://issues.apache.org/jira/browse/CASSANDRA-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13120881#comment-13120881
]
Hudson commented on CASSANDRA-3312:
---
Integrated in Cassandra-0.8 #362 (See
[https://builds.apache.org/job/Cassandra-0.8/362/])
Improved CLI exceptions
patch by satishbabu; reviewed by xedin for CASSANDRA-3312
xedin : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1179164
Files :
* /cassandra/branches/cassandra-0.8/CHANGES.txt
*
/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/cli/CliClient.java
need initClause when catch Exception and throw new Exception in cli
---
Key: CASSANDRA-3312
URL: https://issues.apache.org/jira/browse/CASSANDRA-3312
Project: Cassandra
Issue Type: Bug
Reporter: Jackson Chung
Assignee: satish babu krishnamoorthy
Priority: Minor
Fix For: 0.8.7
Attachments: 3312.patch
through CASSANDRA-2746 , we added initCause to the Cli such that we could see
more meaningful exception stacktrace when certain exception is thrown.
However, there are still some other area, eg:
executeGetWithConditions(Tree)
executeSet(Tree)
executeIncr(Tree, long)
etc etc...
basically any time you do a
{code}
{
throw new RuntimeException(e.getMessage());
}
{code}
the real exception is lost. The right approach should be:
{code}
catch (Exception e)
{
throw new RuntimeException(e.getMessage(), e);
}
{code}
eg: i was getting this:
null
java.lang.RuntimeException
at
org.apache.cassandra.cli.CliClient.executeCLIStatement(CliClient.java:310)
at org.apache.cassandra.cli.CliMain.processStatement(CliMain.java:217)
at org.apache.cassandra.cli.CliMain.main(CliMain.java:345)
Caused by: java.lang.RuntimeException
at
org.apache.cassandra.cli.CliClient.executeGetWithConditions(CliClient.java:815)
at
org.apache.cassandra.cli.CliClient.executeCLIStatement(CliClient.java:208)
... 2 more
but i have no idea what the problem is with just the above stack trace.
with the fix, this would tell us more:
null
java.lang.RuntimeException
at
org.apache.cassandra.cli.CliClient.executeCLIStatement(CliClient.java:310)
at org.apache.cassandra.cli.CliMain.processStatement(CliMain.java:217)
at org.apache.cassandra.cli.CliMain.main(CliMain.java:345)
Caused by: java.lang.RuntimeException
at
org.apache.cassandra.cli.CliClient.executeGetWithConditions(CliClient.java:815)
at
org.apache.cassandra.cli.CliClient.executeCLIStatement(CliClient.java:208)
... 2 more
Caused by: UnavailableException()
at
org.apache.cassandra.thrift.Cassandra$get_indexed_slices_result.read(Cassandra.java:14065)
at
org.apache.cassandra.thrift.Cassandra$Client.recv_get_indexed_slices(Cassandra.java:810)
at
org.apache.cassandra.thrift.Cassandra$Client.get_indexed_slices(Cassandra.java:782)
at
org.apache.cassandra.cli.CliClient.executeGetWithConditions(CliClient.java:806)
... 3 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3297) truncate can still result in data being replayed after a restart
[ https://issues.apache.org/jira/browse/CASSANDRA-3297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13121382#comment-13121382 ] Hudson commented on CASSANDRA-3297: --- Integrated in Cassandra-0.8 #364 (See [https://builds.apache.org/job/Cassandra-0.8/364/]) fix truncate allowing data to be replayed post-restart patch by jbellis; reviewed by slebresne for CASSANDRA-3297 jbellis : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1179359 Files : * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/ColumnFamilyStore.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/Truncation.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/commitlog/CommitLog.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java * /cassandra/branches/cassandra-0.8/test/unit/org/apache/cassandra/db/RecoveryManagerTruncateTest.java truncate can still result in data being replayed after a restart Key: CASSANDRA-3297 URL: https://issues.apache.org/jira/browse/CASSANDRA-3297 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.0 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Labels: commitlog Fix For: 0.8.8, 1.0.0 Attachments: 3297.txt Our first stab at fixing this was CASSANDRA-2950. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3244) JDBC CassandraConnection may lead to memory leak when used in a pool
[ https://issues.apache.org/jira/browse/CASSANDRA-3244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13121442#comment-13121442 ] Hudson commented on CASSANDRA-3244: --- Integrated in Cassandra #1142 (See [https://builds.apache.org/job/Cassandra/1142/]) remove statements from connection's list, when closed manually patch by Rick Shaw; reviewed by Patricio Echague and jbellis for CASSANDRA-3244 jbellis : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1179399 Files : * /cassandra/trunk/drivers/java/src/org/apache/cassandra/cql/jdbc/CassandraConnection.java * /cassandra/trunk/drivers/java/src/org/apache/cassandra/cql/jdbc/CassandraStatement.java JDBC CassandraConnection may lead to memory leak when used in a pool Key: CASSANDRA-3244 URL: https://issues.apache.org/jira/browse/CASSANDRA-3244 Project: Cassandra Issue Type: Improvement Components: Drivers Reporter: Patricio Echague Assignee: Rick Shaw Priority: Minor Labels: JDBC Attachments: 3244-v1.txt, 3244-v2.txt I may be wrong here but I noticed that the implementations of CassandraConnection#createStatement() and CassandraConnection#prepareStatement() keep(cache) the created Statement/PrepareStatement internally in a List. They list is freed up only during CassandraConnection.close() which makes me think that, if the connection object is used in a pool implementation, it will lead to a memory leak as it will hold every single statement that is used to interact with the DB until the connection gets closed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3304) Missing fields in show schema output
[
https://issues.apache.org/jira/browse/CASSANDRA-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13121450#comment-13121450
]
Hudson commented on CASSANDRA-3304:
---
Integrated in Cassandra-0.8 #365 (See
[https://builds.apache.org/job/Cassandra-0.8/365/])
Fix missing fields in CLI `show schema` output
patch by Pavel Yaskevich; reviewed by Jonathan Ellis for CASSANDRA-3304
xedin : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1179395
Files :
*
/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/cli/CliClient.java
Missing fields in show schema output
Key: CASSANDRA-3304
URL: https://issues.apache.org/jira/browse/CASSANDRA-3304
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 1.0.0
Reporter: Radim Kolar
Assignee: Pavel Yaskevich
Priority: Minor
Fix For: 1.0.0
Attachments: CASSANDRA-3304.patch
if you compare output of these 2 commands:
*show keyspaces*
Keyspace: test:
Replication Strategy: org.apache.cassandra.locator.SimpleStrategy
Durable Writes: true
Options: [replication_factor:1]
Column Families:
ColumnFamily: sipdb
phone calls routing information
Key Validation Class: org.apache.cassandra.db.marshal.IntegerType
Default column value validator:
org.apache.cassandra.db.marshal.BytesType
Columns sorted by: org.apache.cassandra.db.marshal.AsciiType
Row cache size / save period in seconds / keys to save : 0.0/0/all
Key cache size / save period in seconds: 0.0/0
GC grace seconds: 0
Compaction min/max thresholds: 4/32
Read repair chance: 0.0
Replicate on write: false
Built indexes: []
Column Metadata:
Column Name: kam
Validation Class: org.apache.cassandra.db.marshal.AsciiType
*Compaction Strategy:
org.apache.cassandra.db.compaction.SizeTieredCompacti*
*show schema*
create column family sipdb
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'BytesType'
and key_validation_class = 'IntegerType'
and rows_cached = 0.0
and row_cache_save_period = 0
and keys_cached = 0.0
and key_cache_save_period = 0
and read_repair_chance = 0.0
and gc_grace = 0
and min_compaction_threshold = 4
and max_compaction_threshold = 32
and replicate_on_write = false
and row_cache_provider = 'ConcurrentLinkedHashCacheProvider'
and comment = 'phone calls routing information'
and column_metadata = [
{column_name : 'kam',
validation_class : AsciiType}];
You will discover that show schema is missing: 1. compaction strategy. 2. how
many keys to save
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3271) off-heap cache to use sun.misc.Unsafe instead of JNA
[ https://issues.apache.org/jira/browse/CASSANDRA-3271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13121593#comment-13121593 ] Hudson commented on CASSANDRA-3271: --- Integrated in Cassandra #1144 (See [https://builds.apache.org/job/Cassandra/1144/]) off-heap cache to use sun.misc.Unsafe instead of JNA patch by Pavel Yaskevich; reviewed by Jonathan Ellis for CASSANDRA-3271 xedin : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1179467 Files : * /cassandra/trunk/CHANGES.txt * /cassandra/trunk/src/java/org/apache/cassandra/cache/FreeableMemory.java * /cassandra/trunk/src/java/org/apache/cassandra/cache/SerializingCacheProvider.java * /cassandra/trunk/src/java/org/apache/cassandra/config/CFMetaData.java * /cassandra/trunk/src/java/org/apache/cassandra/io/util/Memory.java * /cassandra/trunk/src/java/org/apache/cassandra/io/util/MemoryInputStream.java * /cassandra/trunk/src/java/org/apache/cassandra/io/util/MemoryOutputStream.java * /cassandra/trunk/src/resources/org/apache/cassandra/cli/CliHelp.yaml * /cassandra/trunk/test/unit/org/apache/cassandra/cache/CacheProviderTest.java off-heap cache to use sun.misc.Unsafe instead of JNA Key: CASSANDRA-3271 URL: https://issues.apache.org/jira/browse/CASSANDRA-3271 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Pavel Yaskevich Assignee: Pavel Yaskevich Priority: Minor Fix For: 1.1 Attachments: 3271-v2.txt, CASSANDRA-3271-v3.patch, CASSANDRA-3271.patch Instead of requiring JNA for off-heap caches we should try to use sun.misc.Unsafe. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3301) Java Stress Tool: COUNTER_GET reads from CounterSuper1 instead of SuperCounter1
[
https://issues.apache.org/jira/browse/CASSANDRA-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13120158#comment-13120158
]
Hudson commented on CASSANDRA-3301:
---
Integrated in Cassandra-0.8 #359 (See
[https://builds.apache.org/job/Cassandra-0.8/359/])
Fix stress COUNTER_GET options
patch by slebresne; reviewed by jbellis for CASSANDRA-3301
slebresne :
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1178785
Files :
* /cassandra/branches/cassandra-0.8/CHANGES.txt
*
/cassandra/branches/cassandra-0.8/tools/stress/src/org/apache/cassandra/stress/operations/CounterGetter.java
Java Stress Tool: COUNTER_GET reads from CounterSuper1 instead of
SuperCounter1
Key: CASSANDRA-3301
URL: https://issues.apache.org/jira/browse/CASSANDRA-3301
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.8.6
Reporter: Cathy Daw
Assignee: Sylvain Lebresne
Fix For: 0.8.7
Attachments: 3301.patch
Output from stress tool - COUNTER_ADD works fine bug COUNTER_GET does not
{code}
./stress --operation=COUNTER_ADD --family-type=Super --num-keys=1
--consistency-level=TWO --replication-factor=3 --nodes=cathy1
Unable to create stress keyspace: Keyspace already exists.
total,interval_op_rate,interval_key_rate,avg_latency,elapsed_time
1,0,0,0.0060,0
END
./stress --operation=COUNTER_GET --family-type=Super --num-keys=1
--consistency-level=QUORUM --nodes=cathy1
total,interval_op_rate,interval_key_rate,avg_latency,elapsed_time
Operation [0] retried 10 times - error reading counter key 0
((InvalidRequestException): unconfigured columnfamily CounterSuper1)
0,0,0,NaN,0
END
{code}
The CF created is called *SuperCounter1* and not *CounterSuper1*
{code}
INFO 00:34:21,344 ColumnFamilyStore(table='Keyspace1',
columnFamily='SuperCounter1') liveRatio is 9.167798032786886 (just-counted
was 9.167798032786886). calculation took 1281ms for 9883 columns
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3309) Nodetool Doesnt close the open JMX connection causing it to leak Threads
[ https://issues.apache.org/jira/browse/CASSANDRA-3309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13120524#comment-13120524 ] Hudson commented on CASSANDRA-3309: --- Integrated in Cassandra-0.8 #360 (See [https://builds.apache.org/job/Cassandra-0.8/360/]) Nodetool closes JMX connections to avoid leaking timer threads. Patch by vijay, reviewed by brandonwilliams for CASSANDRA-3309 brandonwilliams : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1178957 Files : * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/tools/NodeCmd.java * /cassandra/branches/cassandra-1.0.0/CHANGES.txt * /cassandra/branches/cassandra-1.0.0/src/java/org/apache/cassandra/tools/NodeCmd.java Nodetool Doesnt close the open JMX connection causing it to leak Threads Key: CASSANDRA-3309 URL: https://issues.apache.org/jira/browse/CASSANDRA-3309 Project: Cassandra Issue Type: Bug Affects Versions: 0.8.6, 1.0.0 Reporter: Vijay Assignee: Vijay Fix For: 0.8.7, 1.0.0 Attachments: 0001-fixing-jmx-thread-leak.patch When nodetool is used intensively we will see 1000's of JMX server connection timeout Fix is to close the connections when no longer needed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3137) Implement wrapping intersections for ConfigHelper's InputKeyRange
[ https://issues.apache.org/jira/browse/CASSANDRA-3137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13119564#comment-13119564 ] Hudson commented on CASSANDRA-3137: --- Integrated in Cassandra-0.8 #356 (See [https://builds.apache.org/job/Cassandra-0.8/356/]) allow wrapping ranges in Hadoop queries patch by Mck SembWever; reviewed by jbellis for CASSANDRA-3137 jbellis : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1178551 Files : * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/hadoop/ColumnFamilyInputFormat.java Implement wrapping intersections for ConfigHelper's InputKeyRange - Key: CASSANDRA-3137 URL: https://issues.apache.org/jira/browse/CASSANDRA-3137 Project: Cassandra Issue Type: Improvement Components: Hadoop Affects Versions: 0.8.5 Reporter: Mck SembWever Assignee: Mck SembWever Priority: Minor Fix For: 0.8.7, 1.0.0 Attachments: CASSANDRA-3137.patch, CASSANDRA-3137.patch Before there was no support for multiple intersections between the split's range and the job's configured range. After CASSANDRA-3108 it is now 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] [Commented] (CASSANDRA-3211) Enhanced IP resolution for machines with multiple network interfaces
[ https://issues.apache.org/jira/browse/CASSANDRA-3211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13119623#comment-13119623 ] Hudson commented on CASSANDRA-3211: --- Integrated in Cassandra-0.8 #357 (See [https://builds.apache.org/job/Cassandra-0.8/357/]) check all interfaces for a match with split location before falling back to random replica patch by Brian ONeill; reviewed by jbellis for CASSANDRA-3211 jbellis : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1178554 Files : * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java Enhanced IP resolution for machines with multiple network interfaces - Key: CASSANDRA-3211 URL: https://issues.apache.org/jira/browse/CASSANDRA-3211 Project: Cassandra Issue Type: Improvement Components: Hadoop Affects Versions: 0.6 Environment: Mac OS X and Linux with machines that have multiple network interfaces whereby the IP associated with the split is not on the network interface associated with localhost. Reporter: Brian ONeill Priority: Minor Fix For: 0.8.7 Attachments: trunk-3211.txt On unix machines that have multiple network interfaces whereby the IP associated with the split is not on the network interface associated with localhost, the getLocation method cannot find the proper IP and throws an exception no connection available. I changed the implementation to use NetworkInterface instead of InetAddress using getLocalHost(). This is more reliable. See the following references: http://stackoverflow.com/questions/5813194/inetaddress-getlocalhost-does-not-return-expected-ip-address-from-c-windows-sy http://stackoverflow.com/questions/4871451/inetaddress-getlocalhost-returns-wrong-result-when-hostname-is-64-chars http://www.jguru.com/faq/view.jsp?EID=790132 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3273) FailureDetector can take a very long time to mark a host down
[ https://issues.apache.org/jira/browse/CASSANDRA-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13119622#comment-13119622 ] Hudson commented on CASSANDRA-3273: --- Integrated in Cassandra-0.8 #357 (See [https://builds.apache.org/job/Cassandra-0.8/357/]) Fix bug where the FailureDetector can take a very long time to mark a host down. Patch by brandonwilliams, reviewed by Paul Cannon for CASSANDRA-3273 brandonwilliams : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1178563 Files : * /cassandra/branches/cassandra-0.8/CHANGES.txt * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/gms/FailureDetector.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/gms/Gossiper.java * /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/gms/IFailureDetector.java * /cassandra/branches/cassandra-1.0.0/CHANGES.txt * /cassandra/branches/cassandra-1.0.0/src/java/org/apache/cassandra/gms/FailureDetector.java * /cassandra/branches/cassandra-1.0.0/src/java/org/apache/cassandra/gms/Gossiper.java * /cassandra/branches/cassandra-1.0.0/src/java/org/apache/cassandra/gms/IFailureDetector.java 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: Core Reporter: Brandon Williams Assignee: Brandon Williams Fix For: 0.8.7, 1.0.0 Attachments: 3273.txt 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 is 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 than it should 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
