[jira] [Created] (CASSANDRA-4533) Cache saving does not work
Zhu Han created CASSANDRA-4533: -- Summary: Cache saving does not work Key: CASSANDRA-4533 URL: https://issues.apache.org/jira/browse/CASSANDRA-4533 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.3, 1.0.11 Reporter: Zhu Han Cassandra flushes the key and row cache to disk periodically. It also uses a atomic flag in flushInProgress to enforce single cache writer at any time. However, the cache saving task could be submitted to CompactionManager concurrently, as long as the number of worker thread in CompactionManager is larger than 1. Due to the effect of above atomic flag, only a cache can be written out to disk. Other writer are cancelled when the flag is true. I observe the situation in Cassandra 1.0. If nothing is changed, the problem should remain in Cassandra 1.1, 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
git commit: a startswith func that works for dash and bash
Updated Branches:
refs/heads/cassandra-1.1 9fb63a2f9 - 510689e3a
a startswith func that works for dash and bash
Patch by eevans for CASSANDRA-4494
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/510689e3
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/510689e3
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/510689e3
Branch: refs/heads/cassandra-1.1
Commit: 510689e3a44addcabc4e505e0ebed88edcee244b
Parents: 9fb63a2
Author: Eric Evans eev...@apache.org
Authored: Fri Aug 10 10:33:12 2012 -0500
Committer: Eric Evans eev...@apache.org
Committed: Mon Aug 13 09:28:48 2012 -0500
--
conf/cassandra-env.sh |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/510689e3/conf/cassandra-env.sh
--
diff --git a/conf/cassandra-env.sh b/conf/cassandra-env.sh
index 2928018..6ae28a0 100644
--- a/conf/cassandra-env.sh
+++ b/conf/cassandra-env.sh
@@ -177,7 +177,7 @@ if [ x$CASSANDRA_HEAPDUMP_DIR != x ]; then
fi
-startswith () [ ${1#$2} != $1 ]
+startswith() { [ ${1#$2} != $1 ]; }
if [ `uname` = Linux ] ; then
# reduce the per-thread stack size to minimize the impact of Thrift
[jira] [Resolved] (CASSANDRA-4323) Joining new node to cluster fails with error in add column family
[ https://issues.apache.org/jira/browse/CASSANDRA-4323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-4323. --- Resolution: Duplicate Sounds like CASSANDRA-3794 to me. However, if you're certain no concurrent CREATEs were involved, let us know if you con reproduce in 1.1.3 since multiple schema fixes have gone into that version. Joining new node to cluster fails with error in add column family - Key: CASSANDRA-4323 URL: https://issues.apache.org/jira/browse/CASSANDRA-4323 Project: Cassandra Issue Type: Bug Affects Versions: 1.1.1 Environment: CentOS 6, Java 1.6 Reporter: Bryce Godfrey I tried joining a new node to the cluster, and before boostrap started it reported this error: INFO 08:20:51,584 Enqueuing flush of Memtable-schema_columns@1493418651(0/0 serialized/live bytes, 1 ops) INFO 08:20:51,584 Writing Memtable-schema_columns@1493418651(0/0 serialized/live bytes, 1 ops) INFO 08:20:51,589 Completed flushing /opt/cassandra/data/system/schema_columns/system-schema_columns-hc-1-Data.db (61 bytes) ERROR 08:20:51,889 Exception in thread Thread[MigrationStage:1,5,main] java.lang.IllegalArgumentException: value already present: 1015 at com.google.common.base.Preconditions.checkArgument(Preconditions.java:115) at com.google.common.collect.AbstractBiMap.putInBothMaps(AbstractBiMap.java:111) at com.google.common.collect.AbstractBiMap.put(AbstractBiMap.java:96) at com.google.common.collect.HashBiMap.put(HashBiMap.java:84) at org.apache.cassandra.config.Schema.load(Schema.java:385) at org.apache.cassandra.db.DefsTable.addColumnFamily(DefsTable.java:426) at org.apache.cassandra.db.DefsTable.mergeColumnFamilies(DefsTable.java:361) at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:270) at org.apache.cassandra.db.DefsTable.mergeRemoteSchema(DefsTable.java:248) at org.apache.cassandra.service.MigrationManager$MigrationTask.runMayThrow(MigrationManager.java:416) at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) INFO 08:20:51,931 Enqueuing flush of Memtable-schema_keyspaces@833041663(943/1178 serialized/live bytes, 20 ops) INFO 08:20:51,932 Writing Memtable-schema_keyspaces@833041663(943/1178 serialized/live bytes, 20 ops) And continued on, then started writing these errors non-stop: ERROR 08:21:45,959 Error in row mutation org.apache.cassandra.db.UnknownColumnFamilyException: Couldn't find cfId=1019 at org.apache.cassandra.db.ColumnFamilySerializer.deserialize(ColumnFamilySerializer.java:126) at org.apache.cassandra.db.RowMutation$RowMutationSerializer.deserialize(RowMutation.java:439) at org.apache.cassandra.db.RowMutation$RowMutationSerializer.deserialize(RowMutation.java:447) at org.apache.cassandra.db.RowMutation.fromBytes(RowMutation.java:395) at org.apache.cassandra.db.RowMutationVerbHandler.doVerb(RowMutationVerbHandler.java:42) at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) ERROR 08:21:45,814 Error in row mutation org.apache.cassandra.db.UnknownColumnFamilyException: Couldn't find cfId=1019 at org.apache.cassandra.db.ColumnFamilySerializer.deserialize(ColumnFamilySerializer.java:126) at org.apache.cassandra.db.RowMutation$RowMutationSerializer.deserialize(RowMutation.java:439) at org.apache.cassandra.db.RowMutation$RowMutationSerializer.deserialize(RowMutation.java:447) at org.apache.cassandra.db.RowMutation.fromBytes(RowMutation.java:395) at org.apache.cassandra.db.RowMutationVerbHandler.doVerb(RowMutationVerbHandler.java:42) at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) ERROR 08:21:45,813 Error in row mutation
[jira] [Resolved] (CASSANDRA-4251) when loading schema make sure the key and value are not present in the cfIdMap (BiDiMap)
[ https://issues.apache.org/jira/browse/CASSANDRA-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-4251. --- Resolution: Cannot Reproduce when loading schema make sure the key and value are not present in the cfIdMap (BiDiMap) Key: CASSANDRA-4251 URL: https://issues.apache.org/jira/browse/CASSANDRA-4251 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.2 Reporter: Dave Brosius Priority: Trivial Attachments: better_schema_load_exs.diff google bidimap throws an uncaught runtime exception with less than informative information when the cfid already exists in the cfIDMap has it as a value. Add a check to the preflight check of the Schema class instead, so there is better messaging. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4534) old-style mapred interface doesn't set key limit correctly
Jonathan Ellis created CASSANDRA-4534: - Summary: old-style mapred interface doesn't set key limit correctly Key: CASSANDRA-4534 URL: https://issues.apache.org/jira/browse/CASSANDRA-4534 Project: Cassandra Issue Type: Bug Components: Hadoop Affects Versions: 1.0.6 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 1.0.12 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4534) old-style mapred interface doesn't set key limit correctly
[
https://issues.apache.org/jira/browse/CASSANDRA-4534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-4534:
--
Description: {{next(ByteBuffer key, SortedMapByteBuffer, IColumn value)}}
calls clear/put/rewind, but not flip or limit.
old-style mapred interface doesn't set key limit correctly
--
Key: CASSANDRA-4534
URL: https://issues.apache.org/jira/browse/CASSANDRA-4534
Project: Cassandra
Issue Type: Bug
Components: Hadoop
Affects Versions: 1.0.6
Reporter: Jonathan Ellis
Assignee: Jonathan Ellis
Priority: Minor
Fix For: 1.0.12
{{next(ByteBuffer key, SortedMapByteBuffer, IColumn value)}} calls
clear/put/rewind, but not flip or limit.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4535) On Linux cassandra-env.sh truncates JVM_OPTS due to token error in startswith () [ ${1#$2} != $1 ]
Dwight W Smith created CASSANDRA-4535:
-
Summary: On Linux cassandra-env.sh truncates JVM_OPTS due to token
error in startswith () [ ${1#$2} != $1 ]
Key: CASSANDRA-4535
URL: https://issues.apache.org/jira/browse/CASSANDRA-4535
Project: Cassandra
Issue Type: Bug
Environment: Linux 2.6.18-194.el5 #1 SMP
Reporter: Dwight W Smith
Priority: Minor
Installed 1.1.3 on Linux cluster – the JVM_OPTS were truncated due to a script
error in Cassandra-env.sh:
Invalid token in the following.
startswith () [ ${1#$2} != $1 ]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4535) On Linux cassandra-env.sh truncates JVM_OPTS due to token error in startswith () [ ${1#$2} != $1 ]
[
https://issues.apache.org/jira/browse/CASSANDRA-4535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dwight W Smith updated CASSANDRA-4535:
--
Affects Version/s: 1.1.3
On Linux cassandra-env.sh truncates JVM_OPTS due to token error in startswith
() [ ${1#$2} != $1 ]
---
Key: CASSANDRA-4535
URL: https://issues.apache.org/jira/browse/CASSANDRA-4535
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.3
Environment: Linux 2.6.18-194.el5 #1 SMP
Reporter: Dwight W Smith
Priority: Minor
Installed 1.1.3 on Linux cluster – the JVM_OPTS were truncated due to a
script error in Cassandra-env.sh:
Invalid token in the following.
startswith () [ ${1#$2} != $1 ]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-4535) On Linux cassandra-env.sh truncates JVM_OPTS due to token error in startswith () [ ${1#$2} != $1 ]
[
https://issues.apache.org/jira/browse/CASSANDRA-4535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams resolved CASSANDRA-4535.
-
Resolution: Duplicate
Duplicate of CASSANDRA-4494
On Linux cassandra-env.sh truncates JVM_OPTS due to token error in startswith
() [ ${1#$2} != $1 ]
---
Key: CASSANDRA-4535
URL: https://issues.apache.org/jira/browse/CASSANDRA-4535
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.3
Environment: Linux 2.6.18-194.el5 #1 SMP
Reporter: Dwight W Smith
Priority: Minor
Installed 1.1.3 on Linux cluster – the JVM_OPTS were truncated due to a
script error in Cassandra-env.sh:
Invalid token in the following.
startswith () [ ${1#$2} != $1 ]
--
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-4485) cqlsh: support collections
[ https://issues.apache.org/jira/browse/CASSANDRA-4485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13433382#comment-13433382 ] paul cannon commented on CASSANDRA-4485: (CASSANDRA-4500) cqlsh: support collections -- Key: CASSANDRA-4485 URL: https://issues.apache.org/jira/browse/CASSANDRA-4485 Project: Cassandra Issue Type: Improvement Reporter: Sylvain Lebresne Assignee: paul cannon Priority: Minor Fix For: 1.2 Attachments: 4485-super-basic.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] [Created] (CASSANDRA-4536) Ability for CQL3 to list partition keys
Jonathan Ellis created CASSANDRA-4536:
-
Summary: Ability for CQL3 to list partition keys
Key: CASSANDRA-4536
URL: https://issues.apache.org/jira/browse/CASSANDRA-4536
Project: Cassandra
Issue Type: New Feature
Components: API
Affects Versions: 1.1.0
Reporter: Jonathan Ellis
Assignee: Pavel Yaskevich
Priority: Minor
Fix For: 1.2
It can be useful to know the set of in-use partition keys (storage engine row
keys). One example given to me was where application data was modeled as a few
10s of 1000s of wide rows, where the app required presenting these rows to the
user sorted based on information in the partition key. The partition count is
small enough to do the sort client-side in memory, which is what the app did
with the Thrift API--a range slice with an empty columns list.
This was a problem when migrating to CQL3. {{SELECT mykey FROM mytable}}
includes all the logical rows, which makes the resultset too large to make this
a reasonable approach, even with paging.
One way to add support would be to allow DISTINCT in the special case of
{{SELECT DISTINCT mykey FROM mytable}}.
--
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-4498) Remove openjdk-6-jre Cassandra APT dependencies
[
https://issues.apache.org/jira/browse/CASSANDRA-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13433476#comment-13433476
]
Eric Evans commented on CASSANDRA-4498:
---
This doesn't seem like an improvement to me. The openjdk packages might not be
the ones we recommend, but it's quite a bit better than a totally unsatisfied
(and undeclared) dependency. If it comes down to documenting the need to
obtain and install our recommended JVM, versus having an APT installed
Cassandra simply not work, I would think the former preferable.
FWIW, I would use {{java-package}} to build a Debian package myself, and
distribute that to the machines in my cluster. The resulting package should
Provide {{java6-sdk}}, satisfying the dependency so that openjdk wouldn't need
to be installed.
We could even resurrect one of the more specific java package builders that
were popular before Sun grew a pair, and Oracle cut them off.
Finally, if integration with Linux distributions is important, we should be
focusing our efforts on OpenJDK, since the Oracle version is always going to be
a pain. I realize that may not be the easiest path, but that's often the case
for the right/correct one. :)
Remove openjdk-6-jre Cassandra APT dependencies
---
Key: CASSANDRA-4498
URL: https://issues.apache.org/jira/browse/CASSANDRA-4498
Project: Cassandra
Issue Type: Improvement
Reporter: Terrance Shepherd
Assignee: paul cannon
Priority: Minor
Labels: debian
Fix For: 1.1.4, 1.2
Attachments: apache_cassandra_Packages.diff
As it is well known the recommended jre for Cassandra is sun java 1.6 but at
this point that package no longer in the debian or ubuntu apt repos. In order
to run Cassandra with the sun java 1.6 jre it must be installed manually with
out the repos. Because of this when you install cassandra via the apache or
datastax apt repos it must also install openjdk-6-jre even though sun java
1.6 jre is already installed.
I would suggest that the java apt dependencies be removed from the Depends
field in package configuration and move to either the Recommends or Suggests
field so that way openjdk is not being downloaded when not necessary and
possibly interfering with a be pre-installed jre
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: updated for 1.1.4 release
Updated Branches: refs/heads/cassandra-1.1 510689e3a - 9dc560812 updated for 1.1.4 release Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9dc56081 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9dc56081 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9dc56081 Branch: refs/heads/cassandra-1.1 Commit: 9dc560812ea23a4462411a30be2263b803e39fd9 Parents: 510689e Author: Eric Evans eev...@apache.org Authored: Mon Aug 13 15:16:02 2012 -0500 Committer: Eric Evans eev...@apache.org Committed: Mon Aug 13 15:16:02 2012 -0500 -- build.xml|2 +- debian/changelog |6 ++ 2 files changed, 7 insertions(+), 1 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/9dc56081/build.xml -- diff --git a/build.xml b/build.xml index e23483c..10dbecc 100644 --- a/build.xml +++ b/build.xml @@ -25,7 +25,7 @@ property name=debuglevel value=source,lines,vars/ !-- default version and SCM information -- -property name=base.version value=1.1.3/ +property name=base.version value=1.1.4/ property name=scm.connection value=scm:git://git.apache.org/cassandra.git/ property name=scm.developerConnection value=scm:git://git.apache.org/cassandra.git/ property name=scm.url value=http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=tree/ http://git-wip-us.apache.org/repos/asf/cassandra/blob/9dc56081/debian/changelog -- diff --git a/debian/changelog b/debian/changelog index 946498c..9c6bfdc 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +cassandra (1.1.4) unstable; urgency=low + + * New release + + -- Eric Evans eev...@apache.org Mon, 13 Aug 2012 15:13:20 -0500 + cassandra (1.1.3) unstable; urgency=low * New release
[jira] [Commented] (CASSANDRA-4324) Implement Lucene FST in for key index
[
https://issues.apache.org/jira/browse/CASSANDRA-4324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13433526#comment-13433526
]
Jonathan Ellis commented on CASSANDRA-4324:
---
bq. Looks like only SSTableReader calls IndexSummary#getKeys
Yes, although some uses, like the one in {{getKeySamples(Range)}}, are going to
be tricky without an actual list of keys to work with.
Implement Lucene FST in for key index
-
Key: CASSANDRA-4324
URL: https://issues.apache.org/jira/browse/CASSANDRA-4324
Project: Cassandra
Issue Type: Improvement
Reporter: Jason Rutherglen
Assignee: Jason Rutherglen
Priority: Minor
Fix For: 1.2
Attachments: CASSANDRA-4324.patch, CASSANDRA-4324.patch,
CASSANDRA-4324.patch, lucene-core-4.0-SNAPSHOT.jar
The Lucene FST data structure offers a compact and fast system for indexing
Cassandra keys. More keys may be loaded which in turn should seeks faster.
* Update the IndexSummary class to make use of the Lucene FST, overriding the
serialization mechanism.
* Alter SSTableReader to make use of the FST seek mechanism
--
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-4498) Remove openjdk-6-jre Cassandra APT dependencies
[ https://issues.apache.org/jira/browse/CASSANDRA-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13433554#comment-13433554 ] Terrance Shepherd commented on CASSANDRA-4498: -- Thanks Eric, that does make since. Let me provide more back ground around how I found what I believe to be an issue. I have a little script that will set up a complete cassandra node from the ground up, including installing sun jre 1.6, on a Debian like system. When I run a test of this script it takes me 2 minutes and 30 seconds to install everything required through the apt repos, and still install the sun jvm. If I ignore/pre-install openjdk it takes a total run time to setup a new node in 35 seconds. I was not try to recommend we do not declare the dependency of java, I was simply trying to point out that if we make the change to the packages so one without a jvm could simply run apt-get install --install-suggests cassandra and openjdk will be installed, but those who have already install a jvm could simply run apt-get install cassandra and there will be no wasted time installing / downloading openjdk for those who do not need it or other hacks like setting up your own repo to distribute packages or faking satifying dependencies using equivs. Remove openjdk-6-jre Cassandra APT dependencies --- Key: CASSANDRA-4498 URL: https://issues.apache.org/jira/browse/CASSANDRA-4498 Project: Cassandra Issue Type: Improvement Reporter: Terrance Shepherd Assignee: paul cannon Priority: Minor Labels: debian Fix For: 1.1.4, 1.2 Attachments: apache_cassandra_Packages.diff As it is well known the recommended jre for Cassandra is sun java 1.6 but at this point that package no longer in the debian or ubuntu apt repos. In order to run Cassandra with the sun java 1.6 jre it must be installed manually with out the repos. Because of this when you install cassandra via the apache or datastax apt repos it must also install openjdk-6-jre even though sun java 1.6 jre is already installed. I would suggest that the java apt dependencies be removed from the Depends field in package configuration and move to either the Recommends or Suggests field so that way openjdk is not being downloaded when not necessary and possibly interfering with a be pre-installed jre -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Git Push Summary
Updated Tags: refs/tags/1.1.4-tentative [created] 7cefd7411
[jira] [Commented] (CASSANDRA-4498) Remove openjdk-6-jre Cassandra APT dependencies
[
https://issues.apache.org/jira/browse/CASSANDRA-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13433557#comment-13433557
]
Eric Evans commented on CASSANDRA-4498:
---
{quote}
I was not try to recommend we do not declare the dependency of java, I was
simply trying to point out that if we make the change to the packages so one
without a jvm could simply run
apt-get install --install-suggests cassandra
and openjdk will be installed, but those who have already install a jvm could
simply run
apt-get install cassandra
and there will be no wasted time installing / downloading openjdk for those who
do not need it or other hacks like setting up your own repo to distribute
packages or faking satifying dependencies using equivs.
{quote}
I understand what you're saying, but from a Debian packaging perspective, the
Suggests relationship is more of a hack than providing a satisfiable dependency
(either OpenJDK, or a proper Sun JDK Debian package).
Remove openjdk-6-jre Cassandra APT dependencies
---
Key: CASSANDRA-4498
URL: https://issues.apache.org/jira/browse/CASSANDRA-4498
Project: Cassandra
Issue Type: Improvement
Reporter: Terrance Shepherd
Assignee: paul cannon
Priority: Minor
Labels: debian
Fix For: 1.1.4, 1.2
Attachments: apache_cassandra_Packages.diff
As it is well known the recommended jre for Cassandra is sun java 1.6 but at
this point that package no longer in the debian or ubuntu apt repos. In order
to run Cassandra with the sun java 1.6 jre it must be installed manually with
out the repos. Because of this when you install cassandra via the apache or
datastax apt repos it must also install openjdk-6-jre even though sun java
1.6 jre is already installed.
I would suggest that the java apt dependencies be removed from the Depends
field in package configuration and move to either the Recommends or Suggests
field so that way openjdk is not being downloaded when not necessary and
possibly interfering with a be pre-installed jre
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4537) We should emit number of sstables in each level from JMX
sankalp kohli created CASSANDRA-4537: Summary: We should emit number of sstables in each level from JMX Key: CASSANDRA-4537 URL: https://issues.apache.org/jira/browse/CASSANDRA-4537 Project: Cassandra Issue Type: Bug Affects Versions: 1.2 Reporter: sankalp kohli Priority: Minor We should add methods to this Mbean org.apache.cassandra.db.ColumnFamilyStoreMBean These metrics will be helpful to see how sstables are distributed in different levels and how they move to higher level with time. Currently we can see this by looking at the json file but with JMX, we can monitor the historic values over time using any monitoring tool. -- 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-4498) Remove openjdk-6-jre Cassandra APT dependencies
[ https://issues.apache.org/jira/browse/CASSANDRA-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13433617#comment-13433617 ] paul cannon commented on CASSANDRA-4498: bq. We could even resurrect one of the more specific java package builders that were popular before Sun grew a pair, and Oracle cut them off. Wouldn't that expose the project to the same legal problems? bq. Finally, if integration with Linux distributions is important, we should be focusing our efforts on OpenJDK, since the Oracle version is always going to be a pain. I realize that may not be the easiest path, but that's often the case for the right/correct one. Definitely moving toward full OpenJDK 7 support is the right thing to do, but it's probably somewhat long-term and out of scope for this ticket. Spending effort on OpenJDK 6 seems like kind of a waste. Remove openjdk-6-jre Cassandra APT dependencies --- Key: CASSANDRA-4498 URL: https://issues.apache.org/jira/browse/CASSANDRA-4498 Project: Cassandra Issue Type: Improvement Reporter: Terrance Shepherd Assignee: paul cannon Priority: Minor Labels: debian Fix For: 1.1.4, 1.2 Attachments: apache_cassandra_Packages.diff As it is well known the recommended jre for Cassandra is sun java 1.6 but at this point that package no longer in the debian or ubuntu apt repos. In order to run Cassandra with the sun java 1.6 jre it must be installed manually with out the repos. Because of this when you install cassandra via the apache or datastax apt repos it must also install openjdk-6-jre even though sun java 1.6 jre is already installed. I would suggest that the java apt dependencies be removed from the Depends field in package configuration and move to either the Recommends or Suggests field so that way openjdk is not being downloaded when not necessary and possibly interfering with a be pre-installed jre -- 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-4498) Remove openjdk-6-jre Cassandra APT dependencies
[ https://issues.apache.org/jira/browse/CASSANDRA-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13433635#comment-13433635 ] Eric Evans commented on CASSANDRA-4498: --- bq. Wouldn't that expose the project to the same legal problems? I was referring to the packages that downloaded the JVM from Sun to the users machine, and then built a package (basically the way flash is done now). Probably not a huge win over java-package though. bq. Definitely moving toward full OpenJDK 7 support is the right thing to do, but it's probably somewhat long-term and out of scope for this ticket What is it that currently stops OpenJDK 7 from being a good choice. I haven't done any thorough testing, but it seems to work fairly well with Cassandra (but then again, so does OpenJDK 6 for the most part). bq. Spending effort on OpenJDK 6 seems like kind of a waste. Probably, yeah. Remove openjdk-6-jre Cassandra APT dependencies --- Key: CASSANDRA-4498 URL: https://issues.apache.org/jira/browse/CASSANDRA-4498 Project: Cassandra Issue Type: Improvement Reporter: Terrance Shepherd Assignee: paul cannon Priority: Minor Labels: debian Fix For: 1.1.4, 1.2 Attachments: apache_cassandra_Packages.diff As it is well known the recommended jre for Cassandra is sun java 1.6 but at this point that package no longer in the debian or ubuntu apt repos. In order to run Cassandra with the sun java 1.6 jre it must be installed manually with out the repos. Because of this when you install cassandra via the apache or datastax apt repos it must also install openjdk-6-jre even though sun java 1.6 jre is already installed. I would suggest that the java apt dependencies be removed from the Depends field in package configuration and move to either the Recommends or Suggests field so that way openjdk is not being downloaded when not necessary and possibly interfering with a be pre-installed jre -- 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-4498) Remove openjdk-6-jre Cassandra APT dependencies
[ https://issues.apache.org/jira/browse/CASSANDRA-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13433678#comment-13433678 ] paul cannon commented on CASSANDRA-4498: bq. What is it that currently stops OpenJDK 7 from being a good choice. I haven't done any thorough testing, but it seems to work fairly well with Cassandra (but then again, so does OpenJDK 6 for the most part). I've only heard assertions that it's still pretty buggy (such as [here|https://issues.apache.org/jira/browse/CASSANDRA-4275?focusedCommentId=13419886page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13419886]), and that it's had little to no thorough real-world testing. Would definitely be nice to have though. As far as the ticket comment, the submitter says that installing openjdk-6-jre can potentially interfere with a preexisting sun JRE install. Is that just the potential for the new JRE to show up first in $PATH and be preferred by the alternatives system, or is there some more significant problem? Remove openjdk-6-jre Cassandra APT dependencies --- Key: CASSANDRA-4498 URL: https://issues.apache.org/jira/browse/CASSANDRA-4498 Project: Cassandra Issue Type: Improvement Reporter: Terrance Shepherd Assignee: paul cannon Priority: Minor Labels: debian Fix For: 1.1.4, 1.2 Attachments: apache_cassandra_Packages.diff As it is well known the recommended jre for Cassandra is sun java 1.6 but at this point that package no longer in the debian or ubuntu apt repos. In order to run Cassandra with the sun java 1.6 jre it must be installed manually with out the repos. Because of this when you install cassandra via the apache or datastax apt repos it must also install openjdk-6-jre even though sun java 1.6 jre is already installed. I would suggest that the java apt dependencies be removed from the Depends field in package configuration and move to either the Recommends or Suggests field so that way openjdk is not being downloaded when not necessary and possibly interfering with a be pre-installed jre -- 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-4324) Implement Lucene FST in for key index
[
https://issues.apache.org/jira/browse/CASSANDRA-4324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13433731#comment-13433731
]
Jason Rutherglen commented on CASSANDRA-4324:
-
{quote}some uses, like the one in getKeySamples(Range), are going to be tricky
without an actual list of keys to work with{quote}
The FST has a range iteration method, and the FST will return the keys, which
should suffice?
Implement Lucene FST in for key index
-
Key: CASSANDRA-4324
URL: https://issues.apache.org/jira/browse/CASSANDRA-4324
Project: Cassandra
Issue Type: Improvement
Reporter: Jason Rutherglen
Assignee: Jason Rutherglen
Priority: Minor
Fix For: 1.2
Attachments: CASSANDRA-4324.patch, CASSANDRA-4324.patch,
CASSANDRA-4324.patch, lucene-core-4.0-SNAPSHOT.jar
The Lucene FST data structure offers a compact and fast system for indexing
Cassandra keys. More keys may be loaded which in turn should seeks faster.
* Update the IndexSummary class to make use of the Lucene FST, overriding the
serialization mechanism.
* Alter SSTableReader to make use of the FST seek mechanism
--
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-4324) Implement Lucene FST in for key index
[ https://issues.apache.org/jira/browse/CASSANDRA-4324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13433740#comment-13433740 ] Jonathan Ellis commented on CASSANDRA-4324: --- Yes, I don't think we need random access anywhere but the actual index lookups. Implement Lucene FST in for key index - Key: CASSANDRA-4324 URL: https://issues.apache.org/jira/browse/CASSANDRA-4324 Project: Cassandra Issue Type: Improvement Reporter: Jason Rutherglen Assignee: Jason Rutherglen Priority: Minor Fix For: 1.2 Attachments: CASSANDRA-4324.patch, CASSANDRA-4324.patch, CASSANDRA-4324.patch, lucene-core-4.0-SNAPSHOT.jar The Lucene FST data structure offers a compact and fast system for indexing Cassandra keys. More keys may be loaded which in turn should seeks faster. * Update the IndexSummary class to make use of the Lucene FST, overriding the serialization mechanism. * Alter SSTableReader to make use of the FST seek mechanism -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2710) Get multiple column ranges
[ https://issues.apache.org/jira/browse/CASSANDRA-2710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vijay updated CASSANDRA-2710: - Attachment: 0001-2710-multiple-column-ranges-cql.patch CQL part. cqlsh:Keyspace1 select 0 .. 2,3 from Standard1 where key = 100; Bad Request: line 1:16 mismatched input 'from' expecting RANGEOP cqlsh:Keyspace1 select 0 .. 2,3 .. 0 from Standard1 where key = 100; Bad Request: Slice finish must come after start in traversal order cqlsh:Keyspace1 select 0 .. 2,3 .. '' from Standard1 where key = 100; 0 | 1 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 2 | 3 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 4 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 5 | 50 ... Get multiple column ranges -- Key: CASSANDRA-2710 URL: https://issues.apache.org/jira/browse/CASSANDRA-2710 Project: Cassandra Issue Type: Sub-task Reporter: David Boxenhorn Assignee: Vijay Labels: compositeColumns, cql Attachments: 0001-2710-multiple-column-ranges-cql.patch, 0001-2710-multiple-column-ranges-thrift.patch I have replaced all my super column families with regular column families using composite columns. I have easily been able to support all previous functionality (I don't need range delete) except for one thing: getting multiple super columns with a single access. For this, I would need to get multiple ranges. (I can get multiple columns, or a single range, but not multiple ranges.) For example, I used to have [superColumnName1,subColumnName1..N],[superColumnName2,subColumnName1..N] and I could get superColumnName1, superColumnName2 Now I have [lensuperColumnName10lensubColumnName1..lensuperColumnName10lensubColumnNameN],[lensuperColumnName20lensubColumnName1..lensuperColumnName20lensubColumnNameN] and I need to get superColumnName1..superColumnName1+, superColumnName2..superColumnName2+ to get the same functionality I would like the clients to support this functionality, e.g. Hector to have .setRages parallel to .setColumnNames and for CQL to support a syntax like SELECT [FIRST N] [REVERSED] name1..nameN1, name2..nameN2... FROM ... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3487) better repair session timeouts and retrys
[ https://issues.apache.org/jira/browse/CASSANDRA-3487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vijay updated CASSANDRA-3487: - Assignee: (was: Vijay) better repair session timeouts and retrys - Key: CASSANDRA-3487 URL: https://issues.apache.org/jira/browse/CASSANDRA-3487 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.1.0 Reporter: Vijay Fix For: 1.2 It would be great if we can timeout a validation compaction which is taking long or had an exception while doing a Validation. Repair can gossip its status to all the other nodes, hence any node which is waiting for response of a tree request to wait until it complete, if the repair is not going to complete because of exception or because it is too busy taking the incoming request we can timeout the user request. Bonus: By displaying the repair gossip via nodetool, user/script running the request can have a better handle on whats going on in the cluster. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3534) Enhance memory emergency pressure valve
[ https://issues.apache.org/jira/browse/CASSANDRA-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vijay updated CASSANDRA-3534: - Assignee: (was: Vijay) Enhance memory emergency pressure valve --- Key: CASSANDRA-3534 URL: https://issues.apache.org/jira/browse/CASSANDRA-3534 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.1.0 Reporter: Vijay Priority: Minor Seems like when these thresholds are reached we are trying to reduce the keycache and Memtable sizes, but in the trunk memtable is moved off-heap hence reducing that will not actually help. Reducing the keycache might help but we might want to provide a way to bring the cache level back to the configured value when the pressure goes away. Conversation from IRC: we might want to remove these setting all together after global keycache. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3590) Use multiple connection to share the OutboutTCPConnection
[ https://issues.apache.org/jira/browse/CASSANDRA-3590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vijay updated CASSANDRA-3590: - Fix Version/s: (was: 1.2) Assignee: (was: Vijay) Use multiple connection to share the OutboutTCPConnection - Key: CASSANDRA-3590 URL: https://issues.apache.org/jira/browse/CASSANDRA-3590 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.1.0 Reporter: Vijay Priority: Minor Attachments: TCPTest.xlsx, TCPTest.zip Currently there is one connection between any given host to another host in the cluster, the problem with this is: 1) This can become a bottleneck in some cases where the latencies are higher. 2) When a connection is dropped we also drop the queue and recreate a new one and hence the messages can be lost (Currently hints will take care of it and clients also can retry) by making it a configurable option to configure the number of connections and also making the queue common to those connections the above 2 issues can be resolved. -- 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-4537) We should emit number of sstables in each level from JMX
[ https://issues.apache.org/jira/browse/CASSANDRA-4537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13433833#comment-13433833 ] Brandon Williams commented on CASSANDRA-4537: - I would go one further and say it should be available via nodetool compactionstats. I can't count the number of times I've had to paste a python script that prints level counts. We should emit number of sstables in each level from JMX Key: CASSANDRA-4537 URL: https://issues.apache.org/jira/browse/CASSANDRA-4537 Project: Cassandra Issue Type: Bug Affects Versions: 1.2 Reporter: sankalp kohli Priority: Minor Labels: compaction, leveled Original Estimate: 12h Remaining Estimate: 12h We should add methods to this Mbean org.apache.cassandra.db.ColumnFamilyStoreMBean These metrics will be helpful to see how sstables are distributed in different levels and how they move to higher level with time. Currently we can see this by looking at the json file but with JMX, we can monitor the historic values over time using any monitoring tool. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4494) nodetool can't work at all !
[
https://issues.apache.org/jira/browse/CASSANDRA-4494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
sunjian updated CASSANDRA-4494:
---
Comment: was deleted
(was: why cassandra community release such a version , disappointment .)
nodetool can't work at all !
Key: CASSANDRA-4494
URL: https://issues.apache.org/jira/browse/CASSANDRA-4494
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 1.1.3
Environment: centos 64bit
Reporter: sunjian
Assignee: paul cannon
Priority: Critical
Fix For: 1.1.4
Attachments: 4494-sh-error.patch.txt
1. download cassandra 1.1.3 , then start with {cassandra}/bin/cassandra -pf
2. cd to bin , call nodetool as ./nodetool -h localhost ring
3. console returned : failed to connect to 'localhost:7199' : connection
refused
BUT ,
at the same centos , all was ok before (1.1.2) .
PS:
cassandra-cli/cqlsh works well (1.1.3)
--
update:
even if add the following in cassandra-env.sh , connection refused as well :
JVM_OPTS=$JVM_OPTS -Djava.rmi.server.hostname=10.10.30.11
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4538) Strange CorruptedBlockException when massive insert binary data
Tommy Cheng created CASSANDRA-4538: -- Summary: Strange CorruptedBlockException when massive insert binary data Key: CASSANDRA-4538 URL: https://issues.apache.org/jira/browse/CASSANDRA-4538 Project: Cassandra Issue Type: Bug Affects Versions: 1.1.3 Environment: Debian sequeeze 32bit Reporter: Tommy Cheng Priority: Critical After inserting ~ 1 records, here is the error log INFO 10:53:33,543 Compacted to [/var/lib/cassandra/data/ST/company/ST-company.company_acct_no_idx-he-13-Data.db,]. 407,681 to 409,133 (~100% of original) bytes for 9,250 keys at 0.715926MB/s. Time: 545ms. ERROR 10:53:35,445 Exception in thread Thread[CompactionExecutor:3,1,main] java.io.IOError: org.apache.cassandra.io.compress.CorruptedBlockException: (/var/lib/cassandra/data/ST/company/ST-company-he-9-Data.db): corruption detected, chunk at 7530128 of length 19575. at org.apache.cassandra.db.compaction.PrecompactedRow.merge(PrecompactedRow.java:116) at org.apache.cassandra.db.compaction.PrecompactedRow.init(PrecompactedRow.java:99) at org.apache.cassandra.db.compaction.CompactionController.getCompactedRow(CompactionController.java:176) at org.apache.cassandra.db.compaction.CompactionIterable$Reducer.getReduced(CompactionIterable.java:83) at org.apache.cassandra.db.compaction.CompactionIterable$Reducer.getReduced(CompactionIterable.java:68) at org.apache.cassandra.utils.MergeIterator$ManyToOne.consume(MergeIterator.java:118) at org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:101) at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140) at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135) at com.google.common.collect.Iterators$7.computeNext(Iterators.java:614) at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140) at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135) at org.apache.cassandra.db.compaction.CompactionTask.execute(CompactionTask.java:173) at org.apache.cassandra.db.compaction.CompactionManager$1.runMayThrow(CompactionManager.java:154) at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: org.apache.cassandra.io.compress.CorruptedBlockException: (/var/lib/cassandra/data/ST/company/ST-company-he-9-Data.db): corruption detected, chunk at 7530128 of length 19575. at org.apache.cassandra.io.compress.CompressedRandomAccessReader.decompressChunk(CompressedRandomAccessReader.java:98) at org.apache.cassandra.io.compress.CompressedRandomAccessReader.reBuffer(CompressedRandomAccessReader.java:77) at org.apache.cassandra.io.util.RandomAccessReader.read(RandomAccessReader.java:302) at java.io.RandomAccessFile.readFully(RandomAccessFile.java:397) at java.io.RandomAccessFile.readFully(RandomAccessFile.java:377) at org.apache.cassandra.utils.BytesReadTracker.readFully(BytesReadTracker.java:95) at org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:401) at org.apache.cassandra.utils.ByteBufferUtil.readWithLength(ByteBufferUtil.java:363) at org.apache.cassandra.db.ColumnSerializer.deserialize(ColumnSerializer.java:119) at org.apache.cassandra.db.ColumnSerializer.deserialize(ColumnSerializer.java:36) at org.apache.cassandra.db.ColumnFamilySerializer.deserializeColumns(ColumnFamilySerializer.java:144) at org.apache.cassandra.io.sstable.SSTableIdentityIterator.getColumnFamilyWithColumns(SSTableIdentityIterator.java:234) at org.apache.cassandra.db.compaction.PrecompactedRow.merge(PrecompactedRow.java:112) ... 20 more Here is the startup of cassandra root@cassandra-desktop:~# cassandra -f xss = -ea -javaagent:/usr/share/cassandra/lib/jamm-0.2.5.jar -XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 -Xms496M -Xmx496M -Xmn124M -XX:+HeapDumpOnOutOfMemoryError -Xss128k INFO 10:56:37,113 Logging initialized INFO 10:56:37,122 JVM vendor/version: Java HotSpot(TM) Client VM/1.6.0_26 INFO 10:56:37,123 Heap size: 507117568/507117568 INFO 10:56:37,123 Classpath:
[jira] [Updated] (CASSANDRA-4538) Strange CorruptedBlockException when massive insert binary data
[ https://issues.apache.org/jira/browse/CASSANDRA-4538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommy Cheng updated CASSANDRA-4538: --- Attachment: cassandra-stresstest.zip stress test binary insert Strange CorruptedBlockException when massive insert binary data --- Key: CASSANDRA-4538 URL: https://issues.apache.org/jira/browse/CASSANDRA-4538 Project: Cassandra Issue Type: Bug Affects Versions: 1.1.3 Environment: Debian sequeeze 32bit Reporter: Tommy Cheng Priority: Critical Labels: CorruptedBlockException, binary, insert Attachments: cassandra-stresstest.zip After inserting ~ 1 records, here is the error log INFO 10:53:33,543 Compacted to [/var/lib/cassandra/data/ST/company/ST-company.company_acct_no_idx-he-13-Data.db,]. 407,681 to 409,133 (~100% of original) bytes for 9,250 keys at 0.715926MB/s. Time: 545ms. ERROR 10:53:35,445 Exception in thread Thread[CompactionExecutor:3,1,main] java.io.IOError: org.apache.cassandra.io.compress.CorruptedBlockException: (/var/lib/cassandra/data/ST/company/ST-company-he-9-Data.db): corruption detected, chunk at 7530128 of length 19575. at org.apache.cassandra.db.compaction.PrecompactedRow.merge(PrecompactedRow.java:116) at org.apache.cassandra.db.compaction.PrecompactedRow.init(PrecompactedRow.java:99) at org.apache.cassandra.db.compaction.CompactionController.getCompactedRow(CompactionController.java:176) at org.apache.cassandra.db.compaction.CompactionIterable$Reducer.getReduced(CompactionIterable.java:83) at org.apache.cassandra.db.compaction.CompactionIterable$Reducer.getReduced(CompactionIterable.java:68) at org.apache.cassandra.utils.MergeIterator$ManyToOne.consume(MergeIterator.java:118) at org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:101) at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140) at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135) at com.google.common.collect.Iterators$7.computeNext(Iterators.java:614) at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140) at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135) at org.apache.cassandra.db.compaction.CompactionTask.execute(CompactionTask.java:173) at org.apache.cassandra.db.compaction.CompactionManager$1.runMayThrow(CompactionManager.java:154) at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: org.apache.cassandra.io.compress.CorruptedBlockException: (/var/lib/cassandra/data/ST/company/ST-company-he-9-Data.db): corruption detected, chunk at 7530128 of length 19575. at org.apache.cassandra.io.compress.CompressedRandomAccessReader.decompressChunk(CompressedRandomAccessReader.java:98) at org.apache.cassandra.io.compress.CompressedRandomAccessReader.reBuffer(CompressedRandomAccessReader.java:77) at org.apache.cassandra.io.util.RandomAccessReader.read(RandomAccessReader.java:302) at java.io.RandomAccessFile.readFully(RandomAccessFile.java:397) at java.io.RandomAccessFile.readFully(RandomAccessFile.java:377) at org.apache.cassandra.utils.BytesReadTracker.readFully(BytesReadTracker.java:95) at org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:401) at org.apache.cassandra.utils.ByteBufferUtil.readWithLength(ByteBufferUtil.java:363) at org.apache.cassandra.db.ColumnSerializer.deserialize(ColumnSerializer.java:119) at org.apache.cassandra.db.ColumnSerializer.deserialize(ColumnSerializer.java:36) at org.apache.cassandra.db.ColumnFamilySerializer.deserializeColumns(ColumnFamilySerializer.java:144) at org.apache.cassandra.io.sstable.SSTableIdentityIterator.getColumnFamilyWithColumns(SSTableIdentityIterator.java:234) at org.apache.cassandra.db.compaction.PrecompactedRow.merge(PrecompactedRow.java:112) ... 20 more Here is the startup of cassandra root@cassandra-desktop:~# cassandra -f xss = -ea
