[jira] [Commented] (CASSANDRA-3025) PHP/PDO driver for Cassandra CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13126386#comment-13126386
]
Aurimas Sabaitis commented on CASSANDRA-3025:
-
Hi,
Thanks Mikko for great job! I am very happy at last to remove all necessary
trift php code.
For now I am only missing one feature, automatic UUID conversion, it would be
nice to get it as string and if CASSANDRA_ATTR_PRESERVE_VALUES is true return
it as binary.
PHP/PDO driver for Cassandra CQL
Key: CASSANDRA-3025
URL: https://issues.apache.org/jira/browse/CASSANDRA-3025
Project: Cassandra
Issue Type: New Feature
Components: API
Reporter: Mikko Koppanen
Assignee: Mikko Koppanen
Labels: php
Attachments: pdo_cassandra-0.1.0.tgz, pdo_cassandra-0.1.1.tgz,
pdo_cassandra-0.1.2.tgz, pdo_cassandra-0.1.3.tgz, pdo_cassandra-0.2.0.tgz,
pdo_cassandra-0.2.1.tgz, php_test_results_20110818_2317.txt
Hello,
attached is the initial version of the PDO driver for Cassandra CQL language.
This is a native PHP extension written in what I would call a combination of
C and C++, due to PHP being C. The thrift API used is the C++.
The API looks roughly following:
{code}
?php
$db = new PDO('cassandra:host=127.0.0.1;port=9160');
$db-exec (CREATE KEYSPACE mytest with strategy_class = 'SimpleStrategy' and
strategy_options:replication_factor=1;);
$db-exec (USE mytest);
$db-exec (CREATE COLUMNFAMILY users (
my_key varchar PRIMARY KEY,
full_name varchar ););
$stmt = $db-prepare (INSERT INTO users (my_key, full_name) VALUES (:key,
:full_name););
$stmt-execute (array (':key' = 'mikko', ':full_name' = 'Mikko K' ));
{code}
Currently prepared statements are emulated on the client side but I
understand that there is a plan to add prepared statements to Cassandra CQL
API as well. I will add this feature in to the extension as soon as they are
implemented.
Additional documentation can be found in github
https://github.com/mkoppanen/php-pdo_cassandra, in the form of rendered
MarkDown file. Tests are currently not included in the package file and they
can be found in the github for now as well.
I have created documentation in docbook format as well, but have not yet
rendered it.
Comments and feedback are welcome.
Thanks,
Mikko
--
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=13126422#comment-13126422 ] Stephen Connolly commented on CASSANDRA-3300: - Well ideally the cassandra-clientutil.jar needs to be set up to publish to Maven central... and there is also the question of publishing the JDBC driver to Maven central. Since ASF does not allow its hardware to be used by apache-extras (correct me if I am wrong, please) we'll (i.e. I suspect me) have to use oss.sonatype.org to publish to central. I have a mavenized version of the build which looks quite nice in a local git repo. I would be happy to maintain the build for this component if you guys are happy with it being mavenized and if I have permissions to push to the repo as I suspect it would be me running the release builds until others feel confident typing mvn release:prepare release:perform -B ;-) If you don't want to go the mavenized route, that's fine but it may require more hand-holding from me and I'd require others to do more of the work (i.e. I'm happy being a release manager if pom.xml and not build.xml... if build.xml I'm happy to support but not be a release manager) 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 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-3300) relocate Java (JDBC) CQL driver
[ https://issues.apache.org/jira/browse/CASSANDRA-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13126446#comment-13126446 ] Stephen Connolly commented on CASSANDRA-3300: - Here http://code.google.com/a/apache-extras.org/r/stephenalanconnolly-cassandra-jdbc-maven/ is my mavenized version. Brief summary of the changes * Using cassandra-maven-plugin to start a cassandra server for running the integration tests. * Using build-helper-maven-plugin and resource filtering to ensure that the tests run on random ports each time * Using maven-failsafe-plugin so that integration tests are run while the cassandra server is running. * No need for the lib directory any more Note, before you can build this you need to get cassandra-clientutils.jar into your local repository: mvn install:install-file \ -DgroupId=org.apache.cassandra \ -DartifactId=cassandra-clientutil \ -Dversion=1.0.0-rc2-SNAPSHOT \ -Dpackaging=jar \ -Dfile=path/to/apache-cassandra-clientutil-1.0.0-rc2-SNAPSHOT.jar Then to run the whole build including integration tests mvn clean install To just create the jars mvn package -DskipTests Once we sort out promotion through oss.sonatype.org, making a release should be just mvn release:prepare release:perform And then close and release the staging repo at oss.sonatype.org (same GUI as repository.apache.org) 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 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-3354) tombstone not removed after compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13126455#comment-13126455 ] Sylvain Lebresne commented on CASSANDRA-3354: - No, Expiring columns don't need two compactions to get gc'ed. The conversion of expiring column to tombstone is only a space optimization (to potentially gain the space of the column value during the usually fairly long gc_grace period), but it changes nothing to when the column is gc'ed. So, an expired expiring column is gc'ed as soon as it can, in one shot (I just tried it to be sure and it works). Now, as for what you are seeing, I'm not sure what it is but here's some thinks to check: * for a expired column to be gc'ed during a compaction, it needs to be gcable at the *start* of the compaction (same for tombstone actually). That could make a difference on long running compaction (and yes, we could probably improve that but I doubt this has a big impact in practice). * related to the previous, expiring columns are converted to tombstone at read time. This is true for the reads done by sstable2json in particular. This means that when sstable2json shows you a tombstone, it could be that inside the sstable, it's actually an expired column and it turns out that this column was not expired yet at the time of the compaction. * only major compactions are guaranteed to gc all tombstones. Though if you've used 'nodetool compact' then you've triggered a major one. tombstone not removed after compaction -- Key: CASSANDRA-3354 URL: https://issues.apache.org/jira/browse/CASSANDRA-3354 Project: Cassandra Issue Type: Bug Reporter: Yang Yang Assignee: Sylvain Lebresne Priority: Minor I set GC_grace to 2 hours, for testing. then I compacted the sstables using nodecmd, but the resulting sstables contained many Deletion records older than 2 hours 0d5e32633036663463310001: [[0132f8820139303030303030303030303030303030303030303030303030303030303030303030303263303666346332,4e95a659,1318429297125,d]], yyang@ip-10-71-86-162:~/src/svn/whisky$ perl -e 'print gmtime(1318429297).\n ' Wed Oct 12 14:21:37 2011 -rw-r--r-- 1 yyang yyang 381366163 2011-10-12 16:39 /mnt/cass/lib/cassandra/data/testBudget_items/multi_click_filter-h-511-Data.db but it seems that after running a few more compactions, these records are gone -- 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-3357) SSTableImport/Export don't handle tombstone well if value validation != BytesType
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 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] [Updated] (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:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-3357: Attachment: 3357.patch 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-3300) relocate Java (JDBC) CQL driver
[ https://issues.apache.org/jira/browse/CASSANDRA-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13126595#comment-13126595 ] Rick Shaw commented on CASSANDRA-3300: -- I personally am fine with a Maven install/deploy/release mechinism. It can be a unified part of the build/test process (my pref as well) or just be reserved for when it is needed and use the traditional ANT tooling for build/test. As I have mentioned before, I would like to restructure the (JDBC) trunk directory structure to match up with Maven default structure to make it easier for maven folks to check it in/out of a personal test jig that allows them to add their own POM if they wish. This restructure is very simple and will have no impact on an ANT build once the ANT tasks are adjusted. I would very much like to see Stephen's POM. 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 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-3300) relocate Java (JDBC) CQL driver
[ https://issues.apache.org/jira/browse/CASSANDRA-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13126599#comment-13126599 ] Stephen Connolly commented on CASSANDRA-3300: - http://code.google.com/a/apache-extras.org/r/stephenalanconnolly-cassandra-jdbc-maven/ is where my pom is at. This is a full-on build does all the tests on an isolated cassandra instance that it fires up as part of the build. At present you need two staging repositories to build the maven based project: https://repository.apache.org/content/repositories/orgapachecassandra-055/ for cassandra 1.0.0 https://nexus.codehaus.org/content/repositories/orgcodehausmojo-010/ for cassandra-maven-plugin 1.0.0-1 and you need to mvn install:install-file \ -DgroupId=org.apache.cassandra \ -DartifactId=cassandra-clientutil \ -Dversion=1.0.0-rc2-SNAPSHOT \ -Dpackaging=jar \ -Dfile=path/to/apache-cassandra-clientutil-1.0.0-rc2-SNAPSHOT.jar will build if you do all that. Once the two release votes pass all that remains is to get clientutil released and into maven central and it will be self-contained 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 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] [Created] (CASSANDRA-3358) 2GB row size limit in ColumnIndex offset calculation
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.8.7, 0.7.9, 1.0.0 Reporter: Thomas Richter 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-3025) PHP/PDO driver for Cassandra CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13126672#comment-13126672
]
Jonathan Ellis commented on CASSANDRA-3025:
---
Please follow up on the apache-extras project.
PHP/PDO driver for Cassandra CQL
Key: CASSANDRA-3025
URL: https://issues.apache.org/jira/browse/CASSANDRA-3025
Project: Cassandra
Issue Type: New Feature
Components: API
Reporter: Mikko Koppanen
Assignee: Mikko Koppanen
Labels: php
Attachments: pdo_cassandra-0.1.0.tgz, pdo_cassandra-0.1.1.tgz,
pdo_cassandra-0.1.2.tgz, pdo_cassandra-0.1.3.tgz, pdo_cassandra-0.2.0.tgz,
pdo_cassandra-0.2.1.tgz, php_test_results_20110818_2317.txt
Hello,
attached is the initial version of the PDO driver for Cassandra CQL language.
This is a native PHP extension written in what I would call a combination of
C and C++, due to PHP being C. The thrift API used is the C++.
The API looks roughly following:
{code}
?php
$db = new PDO('cassandra:host=127.0.0.1;port=9160');
$db-exec (CREATE KEYSPACE mytest with strategy_class = 'SimpleStrategy' and
strategy_options:replication_factor=1;);
$db-exec (USE mytest);
$db-exec (CREATE COLUMNFAMILY users (
my_key varchar PRIMARY KEY,
full_name varchar ););
$stmt = $db-prepare (INSERT INTO users (my_key, full_name) VALUES (:key,
:full_name););
$stmt-execute (array (':key' = 'mikko', ':full_name' = 'Mikko K' ));
{code}
Currently prepared statements are emulated on the client side but I
understand that there is a plan to add prepared statements to Cassandra CQL
API as well. I will add this feature in to the extension as soon as they are
implemented.
Additional documentation can be found in github
https://github.com/mkoppanen/php-pdo_cassandra, in the form of rendered
MarkDown file. Tests are currently not included in the package file and they
can be found in the github for now as well.
I have created documentation in docbook format as well, but have not yet
rendered it.
Comments and feedback are welcome.
Thanks,
Mikko
--
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=13126674#comment-13126674 ] Jonathan Ellis commented on CASSANDRA-3357: --- +1 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
[Cassandra Wiki] Update of CodeStyle by JakeLuciani
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The CodeStyle page has been changed by JakeLuciani: http://wiki.apache.org/cassandra/CodeStyle?action=diffrev1=19rev2=20 Comment: add eclipse codestyle link * [blank line] * everything else alphabetically + == format files for IDEs == + * Eclipse (https://github.com/tjake/cassandra-style-eclipse) +
[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=13126676#comment-13126676 ] Jonathan Ellis commented on CASSANDRA-3358: --- Weird -- you're absolutely right, but I could have sworn we fixed this already. :) 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.9, 0.8.7, 1.0.0 Reporter: Thomas Richter 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-3300) relocate Java (JDBC) CQL driver
[
https://issues.apache.org/jira/browse/CASSANDRA-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13126689#comment-13126689
]
Eric Evans commented on CASSANDRA-3300:
---
bq. Well ideally the cassandra-clientutil.jar needs to be set up to publish to
Maven central... and there is also the question of publishing the JDBC driver
to Maven central.
OK, but that should be a separate ticket, and not something that blocks this
one, (it's something that would need to be done whether the driver was moved or
not).
This ticket is technically done, the only thing remaining is to actually remove
the {{drivers/}} directory, and of course, the build and test targets from
{{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
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
svn commit: r1182950 - in /cassandra/branches/cassandra-0.8: CHANGES.txt src/java/org/apache/cassandra/tools/SSTableExport.java src/java/org/apache/cassandra/tools/SSTableImport.java
Author: slebresne Date: Thu Oct 13 16:19:07 2011 New Revision: 1182950 URL: http://svn.apache.org/viewvc?rev=1182950view=rev Log: Fix handling of tombstone by SSTableExport/Import when validation != BytesType patch by slebresne; reviewed by jbellis for CASSANDRA-3357 Modified: 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 Modified: cassandra/branches/cassandra-0.8/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/CHANGES.txt?rev=1182950r1=1182949r2=1182950view=diff == --- cassandra/branches/cassandra-0.8/CHANGES.txt (original) +++ cassandra/branches/cassandra-0.8/CHANGES.txt Thu Oct 13 16:19:07 2011 @@ -5,6 +5,7 @@ (CASSANDRA-3349) * (CQL) allow numeric keyspace names in USE statement (CASSANDRA-3350) * (Hadoop) skip empty rows when slicing the entire row (CASSANDRA-2855) + * Fix handling of tombstone by SSTableExport/Import (CASSANDRA-3357) 0.8.7 Modified: cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/tools/SSTableExport.java URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/tools/SSTableExport.java?rev=1182950r1=1182949r2=1182950view=diff == --- cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/tools/SSTableExport.java (original) +++ cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/tools/SSTableExport.java Thu Oct 13 16:19:07 2011 @@ -128,7 +128,10 @@ public class SSTableExport AbstractType validator = cfMetaData.getValueValidator(name); serializedColumn.add(comparator.getString(name)); -serializedColumn.add(validator.getString(value)); +if (column instanceof DeletedColumn) +serializedColumn.add(ByteBufferUtil.bytesToHex(value)); +else +serializedColumn.add(validator.getString(value)); serializedColumn.add(column.timestamp()); if (column instanceof DeletedColumn) Modified: cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/tools/SSTableImport.java URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/tools/SSTableImport.java?rev=1182950r1=1182949r2=1182950view=diff == --- cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/tools/SSTableImport.java (original) +++ cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/tools/SSTableImport.java Thu Oct 13 16:19:07 2011 @@ -26,6 +26,7 @@ import java.util.*; import org.apache.cassandra.db.marshal.AbstractType; import org.apache.cassandra.db.marshal.BytesType; import org.apache.cassandra.db.marshal.MarshalException; +import org.apache.cassandra.utils.ByteBufferUtil; import org.apache.commons.cli.*; import org.apache.cassandra.config.CFMetaData; @@ -103,7 +104,6 @@ public class SSTableImport assert fields.size() = 3 : Column definition should have at least 3; name = stringAsType((String) fields.get(0), comparator); -value = stringAsType((String) fields.get(1), meta.getValueValidator(name.duplicate())); timestamp = (Long) fields.get(2); kind = ; @@ -137,6 +137,9 @@ public class SSTableImport } } } + +value = isDeleted() ? ByteBufferUtil.hexToBytes((String) fields.get(1)) +: stringAsType((String) fields.get(1), meta.getValueValidator(name.duplicate())); } }
svn commit: r1182951 - in /cassandra/branches/cassandra-1.0.0: ./ contrib/ interface/thrift/gen-java/org/apache/cassandra/thrift/ src/java/org/apache/cassandra/tools/
Author: slebresne Date: Thu Oct 13 16:20:22 2011 New Revision: 1182951 URL: http://svn.apache.org/viewvc?rev=1182951view=rev Log: merge from 0.8 Modified: cassandra/branches/cassandra-1.0.0/ (props changed) cassandra/branches/cassandra-1.0.0/CHANGES.txt cassandra/branches/cassandra-1.0.0/contrib/ (props changed) cassandra/branches/cassandra-1.0.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java (props changed) cassandra/branches/cassandra-1.0.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java (props changed) cassandra/branches/cassandra-1.0.0/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java (props changed) cassandra/branches/cassandra-1.0.0/interface/thrift/gen-java/org/apache/cassandra/thrift/NotFoundException.java (props changed) cassandra/branches/cassandra-1.0.0/interface/thrift/gen-java/org/apache/cassandra/thrift/SuperColumn.java (props changed) cassandra/branches/cassandra-1.0.0/src/java/org/apache/cassandra/tools/SSTableExport.java cassandra/branches/cassandra-1.0.0/src/java/org/apache/cassandra/tools/SSTableImport.java Propchange: cassandra/branches/cassandra-1.0.0/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Oct 13 16:20:22 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1131291 /cassandra/branches/cassandra-0.7:1026516-1170333,1172024 /cassandra/branches/cassandra-0.7.0:1053690-1055654 -/cassandra/branches/cassandra-0.8:1090934-1125013,1125019-1178554,1178785,1178957,1179359,1179364,1180958 +/cassandra/branches/cassandra-0.8:1090934-1125013,1125019-1178554,1178785,1178957,1179359,1179364,1180958,1182950 /cassandra/branches/cassandra-0.8.0:1125021-1130369 /cassandra/branches/cassandra-0.8.1:1101014-1125018 /cassandra/tags/cassandra-0.7.0-rc3:1051699-1053689 Modified: cassandra/branches/cassandra-1.0.0/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-1.0.0/CHANGES.txt?rev=1182951r1=1182950r2=1182951view=diff == --- cassandra/branches/cassandra-1.0.0/CHANGES.txt (original) +++ cassandra/branches/cassandra-1.0.0/CHANGES.txt Thu Oct 13 16:20:22 2011 @@ -30,6 +30,7 @@ Fixes merged from 0.8 below: * Nodetool no longer leaks threads and closes JMX connections (CASSANDRA-3309) * fix truncate allowing data to be replayed post-restart (CASSANDRA-3297) * Move SimpleAuthority and SimpleAuthenticator to examples (CASSANDRA-2922) + * Fix handling of tombstone by SSTableExport/Import (CASSANDRA-3357) 1.0.0-rc2 Propchange: cassandra/branches/cassandra-1.0.0/contrib/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Oct 13 16:20:22 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6/contrib:922689-1052356,1052358-1053452,1053454,1053456-1068009 /cassandra/branches/cassandra-0.7/contrib:1026516-1170333,1172024 /cassandra/branches/cassandra-0.7.0/contrib:1053690-1055654 -/cassandra/branches/cassandra-0.8/contrib:1090934-1125013,1125019-1178554,1178785,1178957,1179359,1179364,1180958 +/cassandra/branches/cassandra-0.8/contrib:1090934-1125013,1125019-1178554,1178785,1178957,1179359,1179364,1180958,1182950 /cassandra/branches/cassandra-0.8.0/contrib:1125021-1130369 /cassandra/branches/cassandra-0.8.1/contrib:1101014-1125018 /cassandra/tags/cassandra-0.7.0-rc3/contrib:1051699-1053689 Propchange: cassandra/branches/cassandra-1.0.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Oct 13 16:20:22 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:922689-1052356,1052358-1053452,1053454,1053456-1131291 /cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1170333,1172024 /cassandra/branches/cassandra-0.7.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1053690-1055654 -/cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1090934-1125013,1125019-1178554,1178785,1178957,1179359,1179364,1180958 +/cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1090934-1125013,1125019-1178554,1178785,1178957,1179359,1179364,1180958,1182950 /cassandra/branches/cassandra-0.8.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1125021-1130369 /cassandra/branches/cassandra-0.8.1/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1101014-1125018
svn commit: r1182952 - in /cassandra/branches/cassandra-1.0: ./ contrib/ interface/thrift/gen-java/org/apache/cassandra/thrift/ src/java/org/apache/cassandra/tools/
Author: slebresne Date: Thu Oct 13 16:21:56 2011 New Revision: 1182952 URL: http://svn.apache.org/viewvc?rev=1182952view=rev Log: merge from 1.0.0 Modified: cassandra/branches/cassandra-1.0/ (props changed) cassandra/branches/cassandra-1.0/CHANGES.txt cassandra/branches/cassandra-1.0/contrib/ (props changed) cassandra/branches/cassandra-1.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java (props changed) cassandra/branches/cassandra-1.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java (props changed) cassandra/branches/cassandra-1.0/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java (props changed) cassandra/branches/cassandra-1.0/interface/thrift/gen-java/org/apache/cassandra/thrift/NotFoundException.java (props changed) cassandra/branches/cassandra-1.0/interface/thrift/gen-java/org/apache/cassandra/thrift/SuperColumn.java (props changed) cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/tools/SSTableExport.java cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/tools/SSTableImport.java Propchange: cassandra/branches/cassandra-1.0/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Oct 13 16:21:56 2011 @@ -1,11 +1,11 @@ /cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1131291 /cassandra/branches/cassandra-0.7:1026516-1170333,1172024 /cassandra/branches/cassandra-0.7.0:1053690-1055654 -/cassandra/branches/cassandra-0.8:1090934-1125013,1125019-1182422 +/cassandra/branches/cassandra-0.8:1090934-1125013,1125019-1182422,1182950 /cassandra/branches/cassandra-0.8.0:1125021-1130369 /cassandra/branches/cassandra-0.8.1:1101014-1125018 /cassandra/branches/cassandra-1.0:1167106,1167185 -/cassandra/branches/cassandra-1.0.0:1167104-1181093,1181741 +/cassandra/branches/cassandra-1.0.0:1167104-1181093,1181741,1182951 /cassandra/tags/cassandra-0.7.0-rc3:1051699-1053689 /cassandra/tags/cassandra-0.8.0-rc1:1102511-1125020 /cassandra/trunk:1167085-1167102,1169870 Modified: cassandra/branches/cassandra-1.0/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-1.0/CHANGES.txt?rev=1182952r1=1182951r2=1182952view=diff == --- cassandra/branches/cassandra-1.0/CHANGES.txt (original) +++ cassandra/branches/cassandra-1.0/CHANGES.txt Thu Oct 13 16:21:56 2011 @@ -44,6 +44,7 @@ Fixes merged from 0.8 below: * Force flush of system table after updating/removing a token (CASSANDRA-3243) * Make Pig storage handle implements LoadMetadata (CASSANDRA-2777) * Improved CLI exceptions (CASSANDRA-3312) + * Fix handling of tombstone by SSTableExport/Import (CASSANDRA-3357) 1.0.0-rc2 Propchange: cassandra/branches/cassandra-1.0/contrib/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Oct 13 16:21:56 2011 @@ -1,11 +1,11 @@ /cassandra/branches/cassandra-0.6/contrib:922689-1052356,1052358-1053452,1053454,1053456-1068009 /cassandra/branches/cassandra-0.7/contrib:1026516-1170333,1172024 /cassandra/branches/cassandra-0.7.0/contrib:1053690-1055654 -/cassandra/branches/cassandra-0.8/contrib:1090934-1125013,1125019-1182422 +/cassandra/branches/cassandra-0.8/contrib:1090934-1125013,1125019-1182422,1182950 /cassandra/branches/cassandra-0.8.0/contrib:1125021-1130369 /cassandra/branches/cassandra-0.8.1/contrib:1101014-1125018 /cassandra/branches/cassandra-1.0/contrib:1167106,1167185 -/cassandra/branches/cassandra-1.0.0/contrib:1167104-1181093,1181741 +/cassandra/branches/cassandra-1.0.0/contrib:1167104-1181093,1181741,1182951 /cassandra/tags/cassandra-0.7.0-rc3/contrib:1051699-1053689 /cassandra/tags/cassandra-0.8.0-rc1/contrib:1102511-1125020 /cassandra/trunk/contrib:1167085-1167102,1169870 Propchange: cassandra/branches/cassandra-1.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Oct 13 16:21:56 2011 @@ -1,11 +1,11 @@ /cassandra/branches/cassandra-0.6/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:922689-1052356,1052358-1053452,1053454,1053456-1131291 /cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1170333,1172024 /cassandra/branches/cassandra-0.7.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1053690-1055654 -/cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1090934-1125013,1125019-1182422 +/cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1090934-1125013,1125019-1182422,1182950
[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=13126699#comment-13126699 ] Eric Evans commented on CASSANDRA-3300: --- bq. Using cassandra-maven-plugin to start a cassandra server for running the integration tests. The idea is that at some point, there will be an established set of tests that each driver must implement. An automated system will then run each driver's test suite against the current, and some number of older versions of Cassandra. All of this will be used as a sort of acceptance criteria for blessing/certifying/whatever. Currently, having the tests connect to an already running Cassandra instance seems like the best way to make that work consistently against an arbitrary number of drivers (i.e. let the test system spin-up different versions of Cassandra prior to each test run). TL;DR Unless you have alternatives to the above, please make sure to support a simple test mode that connects to Cassandra on a configurable host and port. 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 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
svn commit: r1182955 - in /cassandra/trunk: ./ contrib/ interface/thrift/gen-java/org/apache/cassandra/thrift/ src/java/org/apache/cassandra/tools/
Author: slebresne Date: Thu Oct 13 16:24:42 2011 New Revision: 1182955 URL: http://svn.apache.org/viewvc?rev=1182955view=rev Log: merge from 1.0 Modified: cassandra/trunk/ (props changed) cassandra/trunk/CHANGES.txt cassandra/trunk/contrib/ (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/NotFoundException.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/SuperColumn.java (props changed) cassandra/trunk/src/java/org/apache/cassandra/tools/SSTableExport.java cassandra/trunk/src/java/org/apache/cassandra/tools/SSTableImport.java Propchange: cassandra/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Oct 13 16:24:42 2011 @@ -1,11 +1,11 @@ /cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1131291 /cassandra/branches/cassandra-0.7:1026516-1170333,1172024 /cassandra/branches/cassandra-0.7.0:1053690-1055654 -/cassandra/branches/cassandra-0.8:1090934-1125013,1125019-1182422 +/cassandra/branches/cassandra-0.8:1090934-1125013,1125019-1182422,1182950 /cassandra/branches/cassandra-0.8.0:1125021-1130369 /cassandra/branches/cassandra-0.8.1:1101014-1125018 -/cassandra/branches/cassandra-1.0:1167085-1182653 -/cassandra/branches/cassandra-1.0.0:1167104-1167229,1167232-1181093,1181741 +/cassandra/branches/cassandra-1.0:1167085-1182653,1182952 +/cassandra/branches/cassandra-1.0.0:1167104-1167229,1167232-1181093,1181741,1182951 /cassandra/tags/cassandra-0.7.0-rc3:1051699-1053689 /cassandra/tags/cassandra-0.8.0-rc1:1102511-1125020 /incubator/cassandra/branches/cassandra-0.3:774578-796573 Modified: cassandra/trunk/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/trunk/CHANGES.txt?rev=1182955r1=1182954r2=1182955view=diff == --- cassandra/trunk/CHANGES.txt (original) +++ cassandra/trunk/CHANGES.txt Thu Oct 13 16:24:42 2011 @@ -48,6 +48,7 @@ Fixes merged from 0.8 below: * Force flush of system table after updating/removing a token (CASSANDRA-3243) * Make Pig storage handle implements LoadMetadata (CASSANDRA-2777) * Improved CLI exceptions (CASSANDRA-3312) + * Fix handling of tombstone by SSTableExport/Import (CASSANDRA-3357) 1.0.0-rc2 Propchange: cassandra/trunk/contrib/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Oct 13 16:24:42 2011 @@ -1,11 +1,11 @@ /cassandra/branches/cassandra-0.6/contrib:922689-1052356,1052358-1053452,1053454,1053456-1068009 /cassandra/branches/cassandra-0.7/contrib:1026516-1170333,1172024 /cassandra/branches/cassandra-0.7.0/contrib:1053690-1055654 -/cassandra/branches/cassandra-0.8/contrib:1090934-1125013,1125019-1182422 +/cassandra/branches/cassandra-0.8/contrib:1090934-1125013,1125019-1182422,1182950 /cassandra/branches/cassandra-0.8.0/contrib:1125021-1130369 /cassandra/branches/cassandra-0.8.1/contrib:1101014-1125018 -/cassandra/branches/cassandra-1.0/contrib:1167085-1182653 -/cassandra/branches/cassandra-1.0.0/contrib:1167104-1167229,1167232-1181093,1181741 +/cassandra/branches/cassandra-1.0/contrib:1167085-1182653,1182952 +/cassandra/branches/cassandra-1.0.0/contrib:1167104-1167229,1167232-1181093,1181741,1182951 /cassandra/tags/cassandra-0.7.0-rc3/contrib:1051699-1053689 /cassandra/tags/cassandra-0.8.0-rc1/contrib:1102511-1125020 /incubator/cassandra/branches/cassandra-0.3/contrib:774578-796573 Propchange: cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Oct 13 16:24:42 2011 @@ -1,11 +1,11 @@ /cassandra/branches/cassandra-0.6/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:922689-1052356,1052358-1053452,1053454,1053456-1131291 /cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1170333,1172024 /cassandra/branches/cassandra-0.7.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1053690-1055654 -/cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1090934-1125013,1125019-1182422 +/cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1090934-1125013,1125019-1182422,1182950
[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=13126702#comment-13126702 ] Stephen Connolly commented on CASSANDRA-3300: - At present the tests run on a port host that is configured by properties. I can add a profile switch so that if the port/host property is defined then it will not spin up the cassandra server quite easily 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 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] [Reopened] (CASSANDRA-3354) tombstone not removed after compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Yang reopened CASSANDRA-3354: -- since it's not the 2-compaction scenario conjectured before, need to investigate what happened tombstone not removed after compaction -- Key: CASSANDRA-3354 URL: https://issues.apache.org/jira/browse/CASSANDRA-3354 Project: Cassandra Issue Type: Bug Reporter: Yang Yang Assignee: Sylvain Lebresne Priority: Minor I set GC_grace to 2 hours, for testing. then I compacted the sstables using nodecmd, but the resulting sstables contained many Deletion records older than 2 hours 0d5e32633036663463310001: [[0132f8820139303030303030303030303030303030303030303030303030303030303030303030303263303666346332,4e95a659,1318429297125,d]], yyang@ip-10-71-86-162:~/src/svn/whisky$ perl -e 'print gmtime(1318429297).\n ' Wed Oct 12 14:21:37 2011 -rw-r--r-- 1 yyang yyang 381366163 2011-10-12 16:39 /mnt/cass/lib/cassandra/data/testBudget_items/multi_click_filter-h-511-Data.db but it seems that after running a few more compactions, these records are gone -- 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
svn commit: r1183000 - in /cassandra/branches/cassandra-0.7: CHANGES.txt src/java/org/apache/cassandra/db/ColumnIndexer.java
Author: jbellis Date: Thu Oct 13 17:28:46 2011 New Revision: 1183000 URL: http://svn.apache.org/viewvc?rev=1183000view=rev Log: fix ColumnIndexer to use long offsets patch by Thomas Richter; reviewed by jbellis for CASSANDRA-3358 Modified: cassandra/branches/cassandra-0.7/CHANGES.txt cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/db/ColumnIndexer.java Modified: cassandra/branches/cassandra-0.7/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/CHANGES.txt?rev=1183000r1=1182999r2=1183000view=diff == --- cassandra/branches/cassandra-0.7/CHANGES.txt (original) +++ cassandra/branches/cassandra-0.7/CHANGES.txt Thu Oct 13 17:28:46 2011 @@ -1,6 +1,7 @@ 0.7.10 * Fix divide by zero error in GCInspector (CASSANDRA-3164) * revert CASSANDRA-2388 + * fix ColumnIndexer to use long offsets (CASSANDRA-3358) 0.7.9 Modified: cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/db/ColumnIndexer.java URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/db/ColumnIndexer.java?rev=1183000r1=1182999r2=1183000view=diff == --- cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/db/ColumnIndexer.java (original) +++ cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/db/ColumnIndexer.java Thu Oct 13 17:28:46 2011 @@ -70,7 +70,7 @@ public class ColumnIndexer // update bloom filter and create a list of IndexInfo objects marking the first and last column // in each block of ColumnIndexSize ListIndexHelper.IndexInfo indexList = new ArrayListIndexHelper.IndexInfo(); -int endPosition = 0, startPosition = -1; +long endPosition = 0, startPosition = -1; int indexSizeInBytes = 0; IColumn lastColumn = null, firstColumn = null; for (IColumn column : columns)
[jira] [Updated] (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:all-tabpanel ] Jonathan Ellis updated CASSANDRA-3358: -- Affects Version/s: (was: 0.8.7) (was: 0.7.9) (was: 1.0.0) 0.7.0 Fix Version/s: 1.0.1 0.8.8 0.7.10 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 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] [Resolved] (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:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-3358. --- Resolution: Fixed Reviewer: jbellis Assignee: Thomas Richter committed the proposed fix, thanks! 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
svn commit: r1183002 - in /cassandra/branches/cassandra-0.8: ./ contrib/ interface/thrift/gen-java/org/apache/cassandra/thrift/ src/java/org/apache/cassandra/db/
Author: jbellis Date: Thu Oct 13 17:36:16 2011 New Revision: 1183002 URL: http://svn.apache.org/viewvc?rev=1183002view=rev Log: merge #3358 from 0.7 Modified: cassandra/branches/cassandra-0.8/ (props changed) cassandra/branches/cassandra-0.8/CHANGES.txt cassandra/branches/cassandra-0.8/contrib/ (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/NotFoundException.java (props changed) cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/SuperColumn.java (props changed) cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/ColumnIndexer.java Propchange: cassandra/branches/cassandra-0.8/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Oct 13 17:36:16 2011 @@ -1,5 +1,5 @@ /cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1131291 -/cassandra/branches/cassandra-0.7:1026516-1170333,1172024 +/cassandra/branches/cassandra-0.7:1026516-1183000 /cassandra/branches/cassandra-0.7.0:1053690-1055654 /cassandra/branches/cassandra-0.8:1090934-1125013,1125041 /cassandra/branches/cassandra-0.8.0:1125021-1130369 Modified: cassandra/branches/cassandra-0.8/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/CHANGES.txt?rev=1183002r1=1183001r2=1183002view=diff == --- cassandra/branches/cassandra-0.8/CHANGES.txt (original) +++ cassandra/branches/cassandra-0.8/CHANGES.txt Thu Oct 13 17:36:16 2011 @@ -6,6 +6,7 @@ * (CQL) allow numeric keyspace names in USE statement (CASSANDRA-3350) * (Hadoop) skip empty rows when slicing the entire row (CASSANDRA-2855) * Fix handling of tombstone by SSTableExport/Import (CASSANDRA-3357) + * fix ColumnIndexer to use long offsets (CASSANDRA-3358) 0.8.7 Propchange: cassandra/branches/cassandra-0.8/contrib/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Oct 13 17:36:16 2011 @@ -1,5 +1,5 @@ /cassandra/branches/cassandra-0.6/contrib:922689-1052356,1052358-1053452,1053454,1053456-1068009 -/cassandra/branches/cassandra-0.7/contrib:1026516-1170333,1172024 +/cassandra/branches/cassandra-0.7/contrib:1026516-1183000 /cassandra/branches/cassandra-0.7.0/contrib:1053690-1055654 /cassandra/branches/cassandra-0.8/contrib:1090934-1125013,1125041 /cassandra/branches/cassandra-0.8.0/contrib:1125021-1130369 Propchange: cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Oct 13 17:36:16 2011 @@ -1,5 +1,5 @@ /cassandra/branches/cassandra-0.6/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:922689-1052356,1052358-1053452,1053454,1053456-1131291 -/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1170333,1172024 +/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1183000 /cassandra/branches/cassandra-0.7.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1053690-1055654 /cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1090934-1125013,1125041 /cassandra/branches/cassandra-0.8.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1125021-1130369 Propchange: cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Oct 13 17:36:16 2011 @@ -1,5 +1,5 @@ /cassandra/branches/cassandra-0.6/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:922689-1052356,1052358-1053452,1053454,1053456-1131291 -/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1026516-1170333,1172024 +/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1026516-1183000 /cassandra/branches/cassandra-0.7.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1053690-1055654 /cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java:1090934-1125013,1125041
svn commit: r1183003 - in /cassandra/branches/cassandra-1.0: ./ contrib/ contrib/pig/bin/ interface/thrift/gen-java/org/apache/cassandra/thrift/ src/java/org/apache/cassandra/db/ src/java/org/apache/c
Author: jbellis Date: Thu Oct 13 17:38:01 2011 New Revision: 1183003 URL: http://svn.apache.org/viewvc?rev=1183003view=rev Log: merge #3358 from 0.8 Modified: cassandra/branches/cassandra-1.0/ (props changed) cassandra/branches/cassandra-1.0/CHANGES.txt cassandra/branches/cassandra-1.0/contrib/ (props changed) cassandra/branches/cassandra-1.0/contrib/pig/bin/pig_cassandra cassandra/branches/cassandra-1.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java (props changed) cassandra/branches/cassandra-1.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java (props changed) cassandra/branches/cassandra-1.0/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java (props changed) cassandra/branches/cassandra-1.0/interface/thrift/gen-java/org/apache/cassandra/thrift/NotFoundException.java (props changed) cassandra/branches/cassandra-1.0/interface/thrift/gen-java/org/apache/cassandra/thrift/SuperColumn.java (props changed) cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/db/ColumnIndexer.java cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java Propchange: cassandra/branches/cassandra-1.0/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Oct 13 17:38:01 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1131291 -/cassandra/branches/cassandra-0.7:1026516-1170333,1172024 +/cassandra/branches/cassandra-0.7:1026516-1183000 /cassandra/branches/cassandra-0.7.0:1053690-1055654 -/cassandra/branches/cassandra-0.8:1090934-1125013,1125019-1182422,1182950 +/cassandra/branches/cassandra-0.8:1090934-1125013,1125019-1183002 /cassandra/branches/cassandra-0.8.0:1125021-1130369 /cassandra/branches/cassandra-0.8.1:1101014-1125018 /cassandra/branches/cassandra-1.0:1167106,1167185 Modified: cassandra/branches/cassandra-1.0/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-1.0/CHANGES.txt?rev=1183003r1=1183002r2=1183003view=diff == --- cassandra/branches/cassandra-1.0/CHANGES.txt (original) +++ cassandra/branches/cassandra-1.0/CHANGES.txt Thu Oct 13 17:38:01 2011 @@ -7,6 +7,9 @@ (CASSANDRA-3349) * (CQL) allow numeric keyspace names in USE statement (CASSANDRA-3350) * reduce network copies (CASSANDRA-) + * (Hadoop) skip empty rows when slicing the entire row (CASSANDRA-2855) + * Fix handling of tombstone by SSTableExport/Import (CASSANDRA-3357) + * fix ColumnIndexer to use long offsets (CASSANDRA-3358) 1.0.0-final Propchange: cassandra/branches/cassandra-1.0/contrib/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Oct 13 17:38:01 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6/contrib:922689-1052356,1052358-1053452,1053454,1053456-1068009 -/cassandra/branches/cassandra-0.7/contrib:1026516-1170333,1172024 +/cassandra/branches/cassandra-0.7/contrib:1026516-1183000 /cassandra/branches/cassandra-0.7.0/contrib:1053690-1055654 -/cassandra/branches/cassandra-0.8/contrib:1090934-1125013,1125019-1182422,1182950 +/cassandra/branches/cassandra-0.8/contrib:1090934-1125013,1125019-1183002 /cassandra/branches/cassandra-0.8.0/contrib:1125021-1130369 /cassandra/branches/cassandra-0.8.1/contrib:1101014-1125018 /cassandra/branches/cassandra-1.0/contrib:1167106,1167185 Modified: cassandra/branches/cassandra-1.0/contrib/pig/bin/pig_cassandra URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-1.0/contrib/pig/bin/pig_cassandra?rev=1183003r1=1183002r2=1183003view=diff == --- cassandra/branches/cassandra-1.0/contrib/pig/bin/pig_cassandra (original) +++ cassandra/branches/cassandra-1.0/contrib/pig/bin/pig_cassandra Thu Oct 13 17:38:01 2011 @@ -38,11 +38,15 @@ if [ x$PIG_HOME = x ]; then fi # pig jar. -PIG_JAR=$PIG_HOME/pig*.jar +for jar in $PIG_HOME/*.jar; do + PIG_JAR=$jar +done +echo Using $PIG_JAR. if [ ! -e $PIG_JAR ]; then echo Unable to locate Pig jar 2 exit 1 fi + CLASSPATH=$CLASSPATH:$PIG_JAR export PIG_CLASSPATH=$PIG_CLASSPATH:$CLASSPATH Propchange: cassandra/branches/cassandra-1.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Oct 13 17:38:01 2011 @@ -1,7 +1,7 @@ /cassandra/branches/cassandra-0.6/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:922689-1052356,1052358-1053452,1053454,1053456-1131291 -/cassandra/branches/cassandra-0.7/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1026516-1170333,1172024
svn commit: r1183004 - in /cassandra/trunk: ./ conf/ contrib/ contrib/pig/bin/ interface/thrift/gen-java/org/apache/cassandra/thrift/ src/java/org/apache/cassandra/db/ src/java/org/apache/cassandra/ha
Author: jbellis Date: Thu Oct 13 17:39:31 2011 New Revision: 1183004 URL: http://svn.apache.org/viewvc?rev=1183004view=rev Log: merge from 1.0 Modified: cassandra/trunk/ (props changed) cassandra/trunk/CHANGES.txt cassandra/trunk/conf/cassandra-env.sh cassandra/trunk/contrib/ (props changed) cassandra/trunk/contrib/pig/bin/pig_cassandra cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/NotFoundException.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/SuperColumn.java (props changed) cassandra/trunk/src/java/org/apache/cassandra/db/ColumnIndexer.java cassandra/trunk/src/java/org/apache/cassandra/hadoop/ColumnFamilyRecordReader.java Propchange: cassandra/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Oct 13 17:39:31 2011 @@ -1,10 +1,10 @@ /cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1131291 -/cassandra/branches/cassandra-0.7:1026516-1170333,1172024 +/cassandra/branches/cassandra-0.7:1026516-1183000 /cassandra/branches/cassandra-0.7.0:1053690-1055654 -/cassandra/branches/cassandra-0.8:1090934-1125013,1125019-1182422,1182950 +/cassandra/branches/cassandra-0.8:1090934-1125013,1125019-1183002 /cassandra/branches/cassandra-0.8.0:1125021-1130369 /cassandra/branches/cassandra-0.8.1:1101014-1125018 -/cassandra/branches/cassandra-1.0:1167085-1182653,1182952 +/cassandra/branches/cassandra-1.0:1167085-1183003 /cassandra/branches/cassandra-1.0.0:1167104-1167229,1167232-1181093,1181741,1182951 /cassandra/tags/cassandra-0.7.0-rc3:1051699-1053689 /cassandra/tags/cassandra-0.8.0-rc1:1102511-1125020 Modified: cassandra/trunk/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/trunk/CHANGES.txt?rev=1183004r1=1183003r2=1183004view=diff == --- cassandra/trunk/CHANGES.txt (original) +++ cassandra/trunk/CHANGES.txt Thu Oct 13 17:39:31 2011 @@ -11,6 +11,9 @@ (CASSANDRA-3349) * (CQL) allow numeric keyspace names in USE statement (CASSANDRA-3350) * reduce network copies (CASSANDRA-) + * (Hadoop) skip empty rows when slicing the entire row (CASSANDRA-2855) + * Fix handling of tombstone by SSTableExport/Import (CASSANDRA-3357) + * fix ColumnIndexer to use long offsets (CASSANDRA-3358) 1.0.0-final Modified: cassandra/trunk/conf/cassandra-env.sh URL: http://svn.apache.org/viewvc/cassandra/trunk/conf/cassandra-env.sh?rev=1183004r1=1183003r2=1183004view=diff == --- cassandra/trunk/conf/cassandra-env.sh (original) +++ cassandra/trunk/conf/cassandra-env.sh Thu Oct 13 17:39:31 2011 @@ -165,9 +165,10 @@ JVM_OPTS=$JVM_OPTS -XX:+UseCMSInitiatin # GC logging options -- uncomment to enable # JVM_OPTS=$JVM_OPTS -XX:+PrintGCDetails # JVM_OPTS=$JVM_OPTS -XX:+PrintGCTimeStamps -# JVM_OPTS=$JVM_OPTS -XX:+PrintClassHistogram # JVM_OPTS=$JVM_OPTS -XX:+PrintTenuringDistribution # JVM_OPTS=$JVM_OPTS -XX:+PrintGCApplicationStoppedTime +# JVM_OPTS=$JVM_OPTS -XX:+PrintPromotionFailure +# JVM_OPTS=$JVM_OPTS -XX:PrintFLSStatistics=1 # JVM_OPTS=$JVM_OPTS -Xloggc:/var/log/cassandra/gc-`date +%s`.log # uncomment to have Cassandra JVM listen for remote debuggers/profilers on port 1414 Propchange: cassandra/trunk/contrib/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Oct 13 17:39:31 2011 @@ -1,10 +1,10 @@ /cassandra/branches/cassandra-0.6/contrib:922689-1052356,1052358-1053452,1053454,1053456-1068009 -/cassandra/branches/cassandra-0.7/contrib:1026516-1170333,1172024 +/cassandra/branches/cassandra-0.7/contrib:1026516-1183000 /cassandra/branches/cassandra-0.7.0/contrib:1053690-1055654 -/cassandra/branches/cassandra-0.8/contrib:1090934-1125013,1125019-1182422,1182950 +/cassandra/branches/cassandra-0.8/contrib:1090934-1125013,1125019-1183002 /cassandra/branches/cassandra-0.8.0/contrib:1125021-1130369 /cassandra/branches/cassandra-0.8.1/contrib:1101014-1125018 -/cassandra/branches/cassandra-1.0/contrib:1167085-1182653,1182952 +/cassandra/branches/cassandra-1.0/contrib:1167085-1183003 /cassandra/branches/cassandra-1.0.0/contrib:1167104-1167229,1167232-1181093,1181741,1182951 /cassandra/tags/cassandra-0.7.0-rc3/contrib:1051699-1053689 /cassandra/tags/cassandra-0.8.0-rc1/contrib:1102511-1125020 Modified: cassandra/trunk/contrib/pig/bin/pig_cassandra URL:
[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] [Assigned] (CASSANDRA-3354) tombstone not removed after compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3354: - Assignee: Yang Yang (was: Sylvain Lebresne) tombstone not removed after compaction -- Key: CASSANDRA-3354 URL: https://issues.apache.org/jira/browse/CASSANDRA-3354 Project: Cassandra Issue Type: Bug Reporter: Yang Yang Assignee: Yang Yang Priority: Minor I set GC_grace to 2 hours, for testing. then I compacted the sstables using nodecmd, but the resulting sstables contained many Deletion records older than 2 hours 0d5e32633036663463310001: [[0132f8820139303030303030303030303030303030303030303030303030303030303030303030303263303666346332,4e95a659,1318429297125,d]], yyang@ip-10-71-86-162:~/src/svn/whisky$ perl -e 'print gmtime(1318429297).\n ' Wed Oct 12 14:21:37 2011 -rw-r--r-- 1 yyang yyang 381366163 2011-10-12 16:39 /mnt/cass/lib/cassandra/data/testBudget_items/multi_click_filter-h-511-Data.db but it seems that after running a few more compactions, these records are gone -- 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-3302) stop Cassandra result in hang
[ https://issues.apache.org/jira/browse/CASSANDRA-3302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13126808#comment-13126808 ] Jonathan Ellis commented on CASSANDRA-3302: --- Jackson, if I remember correctly, this is broken in trunk but not 1.0.0? Hence the suspicion of CASSANDRA-3261. stop Cassandra result in hang - Key: CASSANDRA-3302 URL: https://issues.apache.org/jira/browse/CASSANDRA-3302 Project: Cassandra Issue Type: Bug Affects Versions: 1.0.1 Reporter: Jackson Chung Assignee: T Jake Luciani testing this under trunk via a hacked package (replacing jars from 0.8.6 deb installation) When calling service cassandra stop, the Cassandra process hang: http://aep.appspot.com/display/i6aIUCkt4kz0HG5l2VszMM7QvLo/ The following logs is observed in the C* log: INFO [main] 2011-10-03 23:20:46,434 AbstractCassandraDaemon.java (line 270) Cassandra shutting down... INFO [main] 2011-10-03 23:20:46,434 CassandraDaemon.java (line 218) Stop listening to thrift clients Re-run this using 1.0.0 branch, (following the same hack procedure), C* stop properly, and the following is observed in the log: INFO [main] 2011-10-04 05:02:08,048 AbstractCassandraDaemon.java (line 270) Cassandra shutting down... INFO [main] 2011-10-04 05:02:08,049 CassandraDaemon.java (line 218) Stop listening to thrift clients INFO [Thread-2] 2011-10-04 05:02:08,318 MessagingService.java (line 482) Shutting down MessageService... INFO [Thread-2] 2011-10-04 05:02:08,319 MessagingService.java (line 497) Waiting for in-progress requests to complete INFO [ACCEPT-/10.83.77.171] 2011-10-04 05:02:08,319 MessagingService.java (line 637) MessagingService shutting down server thread. could this be related to CASSANDRA-3261 ? -- 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-3241) CQL JDBC doesn't work with groovy.sql.Sql
[ https://issues.apache.org/jira/browse/CASSANDRA-3241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-3241. --- Resolution: Incomplete CQL JDBC doesn't work with groovy.sql.Sql - Key: CASSANDRA-3241 URL: https://issues.apache.org/jira/browse/CASSANDRA-3241 Project: Cassandra Issue Type: Bug Components: API Reporter: M Chen Priority: Minor Apparently there's something that groovy.sql.Sql doesn't like about the CQL JDBC driver. That seems a shame given how simple it is to use -- 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-3248) CommitLog writer should call fdatasync instead of fsync
[
https://issues.apache.org/jira/browse/CASSANDRA-3248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13126809#comment-13126809
]
Jonathan Ellis commented on CASSANDRA-3248:
---
Any news, Zhu?
CommitLog writer should call fdatasync instead of fsync
---
Key: CASSANDRA-3248
URL: https://issues.apache.org/jira/browse/CASSANDRA-3248
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 0.6.13, 0.7.9, 0.8.6, 1.0.0, 1.1
Environment: Linux
Reporter: Zhu Han
Original Estimate: 48h
Remaining Estimate: 48h
CommitLogSegment uses SequentialWriter to flush the buffered data to log
device. It depends on FileDescriptor#sync() which invokes fsync() as it force
the file attributes to disk.
However, at least on Linux, fdatasync() is good enough for commit log flush:
bq. fdatasync() is similar to fsync(), but does not flush modified metadata
unless that metadata is needed in order to allow a subsequent data retrieval
to be correctly handled. For example, changes to st_atime or st_mtime
(respectively, time of last access and time of last modification; see
stat(2)) do not require flushing because they are not necessary for a
subsequent data read to be handled correctly. On the other hand, a change to
the file size (st_size, as made by say ftruncate(2)), would require a
metadata flush.
File size is synced to disk by fdatasync() either. Although the commit log
recovery logic sorts the commit log segements on their modify timestamp, it
can be removed safely, IMHO.
I checked the native code of JRE 6. On Linux and Solaris,
FileChannel#force(false) invokes fdatasync(). On windows, the false flag does
not have any impact.
On my log device (commodity SATA HDD, write cache disabled), there is large
performance gap between fsync() and fdatasync():
{quote}
$sysbench --test=fileio --num-threads=1 --file-num=1 --file-total-size=10G
--file-fsync-all=on --file-fsync-mode={color:red}fdatasync{color}
--file-test-mode=seqwr --max-time=600 --file-block-size=2K --max-requests=0
run
{color:blue}54.90{color} Requests/sec executed
per-request statistics:
min: 8.29ms
avg: 18.18ms
max:108.36ms
approx. 95 percentile: 25.02ms
$ sysbench --test=fileio --num-threads=1 --file-num=1 --file-total-size=10G
--file-fsync-all=on --file-fsync-mode={color:red}fsync{color}
--file-test-mode=seqwr --max-time=600 --file-block-size=2K --max-requests=0
run
{color:blue}28.08{color} Requests/sec executed
per-request statistics:
min: 33.28ms
avg: 35.61ms
max:911.87ms
approx. 95 percentile: 41.69ms
{quote}
I do think this is a very critical performance improvement.
--
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-3340) Add a default range to queries
[
https://issues.apache.org/jira/browse/CASSANDRA-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-3340.
---
Resolution: Duplicate
It sounds like this is a special case of being able to request multiple ranges
in a single api call. We already have tickets open for that (CASSANDRA-2710,
CASSANDRA-3069).
Add a default range to queries
--
Key: CASSANDRA-3340
URL: https://issues.apache.org/jira/browse/CASSANDRA-3340
Project: Cassandra
Issue Type: New Feature
Reporter: David Semeria
Priority: Minor
Often we find ourselves having to make two nearly identical queries when in
theory one could suffice.
Assuming we're storing json properites in discrete columns, a typical user
row might look like this:
default:name, default:age,... address:street, address:number,...
contacts:email, contacts,phone, contacts:mobile
To extract the contacts for a given user we would pass startCol = 'contacts',
endCol = 'contacts' + charAfter(':')
However, we frequently also need to retrieve the properties under the
'default' key. To do this we currently need to make a second nearly identical
query, with the only difference that startCol and endCol now refer to
'default'
It would be nice if we could pass in a default range along with the standard
range during queries.
It seems inefficient to make Cassandra extract the same row(s) twice, with
the only difference being how they are filtered.
I'm not in a position to estimate how many other users might find this
functionality useful, all I can say is that we certainly would.
Thanks.
--
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-3226) Single faulty node brings down entire cluster. No reads/writes possible
[ https://issues.apache.org/jira/browse/CASSANDRA-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13126815#comment-13126815 ] Jonathan Ellis commented on CASSANDRA-3226: --- Any update, Thibaut? Single faulty node brings down entire cluster. No reads/writes possible --- Key: CASSANDRA-3226 URL: https://issues.apache.org/jira/browse/CASSANDRA-3226 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.5 Environment: linux Reporter: Thibaut Attachments: jstack No client is able to read anything from the entire cluster anymore. This occured a few times so far, but I can't reproduce it. Looks like an OOM directly after starting up the node? Restarting the node solves the issue. I also have to kill the node with -9 because normal kill won't kill the node. Healty nodes: *.13: Mode: Normal Not sending any streams. Not receiving any streams. Pool NameActive Pending Completed Commandsn/a 15237 416868 Responses n/a 0 126721 *.14. Mode: Normal Not sending any streams. Not receiving any streams. Pool NameActive Pending Completed Commandsn/a 15387 437325 Responses n/a 0 131066 *.15: Mode: Normal Not sending any streams. Not receiving any streams. Pool NameActive Pending Completed Commandsn/a 15530 368771 Responses n/a 0 145168 etc... The pending commands at the healty nodes all increase. Faulty node before restart: /software/cassandra/bin/nodetool -h localhost info Token: f33 Gossip active: true Load : 130.67 GB Generation No: 1316197687 Uptime (seconds) : 137051 Heap Memory (MB) : 3580.22 / 3614.00 Data Center : datacenter1 Rack : rack1 Exceptions : 108 /software/cassandra/bin/nodetool -h localhost netstats Mode: Normal Not sending any streams. Not receiving any streams. Pool NameActive Pending Completed Commandsn/a 0 29696566 Responses n/a 560 26650981 Log excerpt: INFO [GossipStage:3] 2011-09-18 09:16:46,254 Gossiper.java (line 713) Node /192.168.0.11 has restarted, now UP again INFO [GossipStage:3] 2011-09-18 09:16:46,255 Gossiper.java (line 681) InetAddress /192.168.0.11 is now UP INFO [GossipStage:3] 2011-09-18 09:16:46,255 StorageService.java (line 815) Node /192.168.0.11 state jump to normal INFO [GossipStage:3] 2011-09-18 09:16:46,257 StorageService.java (line 815) Node /192.168.0.11 state jump to normal INFO [GossipStage:3] 2011-09-18 09:16:54,984 StorageService.java (line 815) Node /192.168.0.6 state jump to normal INFO [GossipStage:3] 2011-09-18 09:16:54,984 Gossiper.java (line 681) InetAddress /192.168.0.6 is now UP INFO [GossipStage:3] 2011-09-18 09:16:56,262 StorageService.java (line 815) Node /192.168.0.18 state jump to normal INFO [GossipStage:3] 2011-09-18 09:16:56,263 Gossiper.java (line 681) InetAddress /192.168.0.18 is now UP INFO [GossipStage:3] 2011-09-18 09:17:06,272 Gossiper.java (line 713) Node /192.168.0.1 has restarted, now UP again INFO [GossipStage:3] 2011-09-18 09:17:06,272 Gossiper.java (line 681) InetAddress /192.168.0.1 is now UP INFO [GossipStage:3] 2011-09-18 09:17:06,272 StorageService.java (line 815) Node /192.168.0.1 state jump to normal INFO [HintedHandoff:1] 2011-09-18 09:20:49,846 HintedHandOffManager.java (line 323) Started hinted handoff for endpoint /192.168.0.8 INFO [HintedHandoff:1] 2011-09-18 09:20:49,847 HintedHandOffManager.java (line 379) Finished hinted handoff of 0 rows to endpoint /192.168.0.8 INFO [HintedHandoff:1] 2011-09-18 09:21:45,430 HintedHandOffManager.java (line 323) Started hinted handoff for endpoint /192.168.0.7 INFO [HintedHandoff:1] 2011-09-18 09:21:45,696 HintedHandOffManager.java (line 379) Finished hinted handoff of 0 rows to endpoint /192.168.0.7 INFO [HintedHandoff:1] 2011-09-18 09:21:52,432 HintedHandOffManager.java (line 323) Started hinted handoff for endpoint /192.168.0.20 INFO [HintedHandoff:1] 2011-09-18 09:21:52,432 HintedHandOffManager.java (line 379) Finished hinted handoff of 0 rows to endpoint /192.168.0.20 INFO [HintedHandoff:1] 2011-09-18 09:22:12,469 HintedHandOffManager.java (line 323) Started hinted handoff for endpoint /192.168.0.9 INFO [HintedHandoff:1] 2011-09-18 09:22:12,469 HintedHandOffManager.java (line 379) Finished hinted handoff of 0 rows to endpoint
[jira] [Updated] (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:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-3272:
--
Attachment: 3272.txt
currently EACH_QUORUM silently does LOCAL_QUORUM instead. Patch attached to
raise an error saying EACH_QUORUM is only supported for writes.
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.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:
col_fam.get('test-key-1',read_consistency_level=pycassa.ConsistencyLevel.EACH_QUORUM)
OrderedDict([('test-col', 'test-value')])
--
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-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:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-3272:
--
Priority: Minor (was: Major)
Affects Version/s: 0.7.0
Fix Version/s: 1.1
Assignee: Jonathan Ellis
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.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:
col_fam.get('test-key-1',read_consistency_level=pycassa.ConsistencyLevel.EACH_QUORUM)
OrderedDict([('test-col', 'test-value')])
--
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-3355) Race trying to register CFS MBean
[
https://issues.apache.org/jira/browse/CASSANDRA-3355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-3355.
---
Resolution: Duplicate
see CASSANDRA-3217
Race trying to register CFS MBean
-
Key: CASSANDRA-3355
URL: https://issues.apache.org/jira/browse/CASSANDRA-3355
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Brandon Williams
Priority: Minor
I heard reports of this multiple times, here's an example:
{noformat}
INFO 16:08:23,672 reading saved cache
/var/lib/cassandra/saved_caches/spider-InterfaceDailyCompressed-KeyCache
INFO 16:08:23,995 Opening
/var/lib/cassandra/data/spider/InterfaceDailyCompressed-g-63
INFO 16:08:24,253 Opening
/var/lib/cassandra/data/spider/InterfaceDailyCompressed-g-75
INFO 16:08:24,422 Opening
/var/lib/cassandra/data/spider/InterfaceDailyCompressed-g-113
INFO 16:08:24,443 Opening
/var/lib/cassandra/data/spider/InterfaceDailyCompressed-g-36
INFO 16:08:24,756 Opening
/var/lib/cassandra/data/spider/InterfaceDailyCompressed-g-102
INFO 16:08:24,789 Opening
/var/lib/cassandra/data/spider/InterfaceDailyCompressed-g-58
ERROR 16:08:25,105 Exception encountered during startup.
java.lang.RuntimeException: javax.management.InstanceAlreadyExistsException:
org.apache.cassandra.db:type=ColumnFamilies,keyspace=spider,columnfamily=InterfaceDailyCompressed
at
org.apache.cassandra.db.ColumnFamilyStore.init(ColumnFamilyStore.java:303)
at
org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:465)
at
org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:435)
at org.apache.cassandra.db.Table.initCf(Table.java:369)
at org.apache.cassandra.db.Table.init(Table.java:306)
at org.apache.cassandra.db.Table.open(Table.java:111)
at
org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:187)
at
org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:341)
at
org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:97)
Caused by: javax.management.InstanceAlreadyExistsException:
org.apache.cassandra.db:type=ColumnFamilies,keyspace=spider,columnfamily=InterfaceDailyCompressed
at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:453)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.internal_addObject(DefaultMBeanServerInterceptor.java:1484)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:963)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:917)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:312)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:482)
at
org.apache.cassandra.db.ColumnFamilyStore.init(ColumnFamilyStore.java:299)
... 8 more
Exception encountered during startup.
java.lang.RuntimeException: javax.management.InstanceAlreadyExistsException:
org.apache.cassandra.db:type=ColumnFamilies,keyspace=spider,columnfamily=InterfaceDailyCompressed
at
org.apache.cassandra.db.ColumnFamilyStore.init(ColumnFamilyStore.java:303)
at
org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:465)
at
org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:435)
at org.apache.cassandra.db.Table.initCf(Table.java:369)
at org.apache.cassandra.db.Table.init(Table.java:306)
at org.apache.cassandra.db.Table.open(Table.java:111)
at
org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:187)
at
org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:341)
at
org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:97)
Caused by: javax.management.InstanceAlreadyExistsException:
org.apache.cassandra.db:type=ColumnFamilies,keyspace=spider,columnfamily=InterfaceDailyCompressed
at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:453)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.internal_addObject(DefaultMBeanServerInterceptor.java:1484)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:963)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:917)
at
[jira] [Assigned] (CASSANDRA-3196) Cassandra-CLI command should have --version option
[ https://issues.apache.org/jira/browse/CASSANDRA-3196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3196: - Assignee: Pavel Yaskevich Can we just make the cli print FBUtilities.getReleaseVersionString() on startup? 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 Affects Versions: 0.8.5 Environment: Linux version 2.6.32-5-amd64 (Debian 2.6.32-35) Reporter: Mauri Tikka Assignee: Pavel Yaskevich Priority: Minor 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] [Updated] (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:all-tabpanel ] Brandon Williams updated CASSANDRA-3214: Reviewer: brandon.williams (was: jbellis) 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 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] [Updated] (CASSANDRA-3196) Cassandra-CLI command should have --version option
[ https://issues.apache.org/jira/browse/CASSANDRA-3196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-3196: -- Affects Version/s: (was: 0.8.5) Fix Version/s: 1.0.1 0.8.8 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 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
svn commit: r1183046 - in /cassandra/branches/cassandra-1.0: CHANGES.txt bin/nodetool
Author: jbellis Date: Thu Oct 13 19:26:43 2011 New Revision: 1183046 URL: http://svn.apache.org/viewvc?rev=1183046view=rev Log: limit nodetool to 32MB of heap patch by Zenek Kraweznik; reviewed by jbellis for CASSANDRA-3124 Modified: cassandra/branches/cassandra-1.0/CHANGES.txt cassandra/branches/cassandra-1.0/bin/nodetool Modified: cassandra/branches/cassandra-1.0/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-1.0/CHANGES.txt?rev=1183046r1=1183045r2=1183046view=diff == --- cassandra/branches/cassandra-1.0/CHANGES.txt (original) +++ cassandra/branches/cassandra-1.0/CHANGES.txt Thu Oct 13 19:26:43 2011 @@ -10,6 +10,7 @@ * (Hadoop) skip empty rows when slicing the entire row (CASSANDRA-2855) * Fix handling of tombstone by SSTableExport/Import (CASSANDRA-3357) * fix ColumnIndexer to use long offsets (CASSANDRA-3358) + * limit nodetool to 32MB of heap (CASSANDRA-3124) 1.0.0-final Modified: cassandra/branches/cassandra-1.0/bin/nodetool URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-1.0/bin/nodetool?rev=1183046r1=1183045r2=1183046view=diff == --- cassandra/branches/cassandra-1.0/bin/nodetool (original) +++ cassandra/branches/cassandra-1.0/bin/nodetool Thu Oct 13 19:26:43 2011 @@ -55,8 +55,10 @@ case `uname` in ;; esac -$JAVA -cp $CLASSPATH -Dstorage-config=$CASSANDRA_CONF \ --Dlog4j.configuration=log4j-tools.properties \ -org.apache.cassandra.tools.NodeCmd $@ +$JAVA -cp $CLASSPATH \ + -Xmx32m \ + -Dlog4j.configuration=log4j-tools.properties \ + -Dstorage-config=$CASSANDRA_CONF \ + org.apache.cassandra.tools.NodeCmd $@ # vi:ai sw=4 ts=4 tw=0 et
[jira] [Commented] (CASSANDRA-3124) java heap limit for nodetool
[ https://issues.apache.org/jira/browse/CASSANDRA-3124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13126835#comment-13126835 ] Jonathan Ellis commented on CASSANDRA-3124: --- I don't think nodetool should ever need more than 32M, so that's reasonable. Committed in r1183046. java heap limit for nodetool Key: CASSANDRA-3124 URL: https://issues.apache.org/jira/browse/CASSANDRA-3124 Project: Cassandra Issue Type: Improvement Components: Core, Tools Affects Versions: 0.8.1, 0.8.2, 0.8.3, 0.8.4 Environment: not important Reporter: Zenek Kraweznik Priority: Minor by defaull (from debian package) # nodetool Error occurred during initialization of VM Could not reserve enough space for object heap Could not create the Java virtual machine. # and: --- /usr/bin/nodetool.old 2011-09-02 14:15:14.228152799 +0200 +++ /usr/bin/nodetool 2011-09-02 14:14:28.745154552 +0200 @@ -55,7 +55,7 @@ ;; esac -$JAVA -cp $CLASSPATH -Dstorage-config=$CASSANDRA_CONF \ +$JAVA -Xmx32m -cp $CLASSPATH -Dstorage-config=$CASSANDRA_CONF \ -Dlog4j.configuration=log4j-tools.properties \ org.apache.cassandra.tools.NodeCmd $@ after every upgrade i had to add limit manually. I think it's good idea to add it by default ;) -- 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-3124) java heap limit for nodetool
[ https://issues.apache.org/jira/browse/CASSANDRA-3124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-3124. --- Resolution: Fixed Reviewer: jbellis committed java heap limit for nodetool Key: CASSANDRA-3124 URL: https://issues.apache.org/jira/browse/CASSANDRA-3124 Project: Cassandra Issue Type: Improvement Components: Tools Environment: not important Reporter: Zenek Kraweznik Assignee: Zenek Kraweznik Priority: Minor Fix For: 1.0.1 by defaull (from debian package) # nodetool Error occurred during initialization of VM Could not reserve enough space for object heap Could not create the Java virtual machine. # and: --- /usr/bin/nodetool.old 2011-09-02 14:15:14.228152799 +0200 +++ /usr/bin/nodetool 2011-09-02 14:14:28.745154552 +0200 @@ -55,7 +55,7 @@ ;; esac -$JAVA -cp $CLASSPATH -Dstorage-config=$CASSANDRA_CONF \ +$JAVA -Xmx32m -cp $CLASSPATH -Dstorage-config=$CASSANDRA_CONF \ -Dlog4j.configuration=log4j-tools.properties \ org.apache.cassandra.tools.NodeCmd $@ after every upgrade i had to add limit manually. I think it's good idea to add it by default ;) -- 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-3124) java heap limit for nodetool
[ https://issues.apache.org/jira/browse/CASSANDRA-3124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-3124: -- Component/s: (was: Core) Affects Version/s: (was: 0.8.4) (was: 0.8.3) (was: 0.8.2) (was: 0.8.1) Fix Version/s: 1.0.1 Assignee: Zenek Kraweznik java heap limit for nodetool Key: CASSANDRA-3124 URL: https://issues.apache.org/jira/browse/CASSANDRA-3124 Project: Cassandra Issue Type: Improvement Components: Tools Environment: not important Reporter: Zenek Kraweznik Assignee: Zenek Kraweznik Priority: Minor Fix For: 1.0.1 by defaull (from debian package) # nodetool Error occurred during initialization of VM Could not reserve enough space for object heap Could not create the Java virtual machine. # and: --- /usr/bin/nodetool.old 2011-09-02 14:15:14.228152799 +0200 +++ /usr/bin/nodetool 2011-09-02 14:14:28.745154552 +0200 @@ -55,7 +55,7 @@ ;; esac -$JAVA -cp $CLASSPATH -Dstorage-config=$CASSANDRA_CONF \ +$JAVA -Xmx32m -cp $CLASSPATH -Dstorage-config=$CASSANDRA_CONF \ -Dlog4j.configuration=log4j-tools.properties \ org.apache.cassandra.tools.NodeCmd $@ after every upgrade i had to add limit manually. I think it's good idea to add it by default ;) -- 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-3134) Patch Hadoop Streaming Source to Support Cassandra IO
[ https://issues.apache.org/jira/browse/CASSANDRA-3134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13126852#comment-13126852 ] Brandon Williams commented on CASSANDRA-3134: - It seems like TypedBytes is the Hadoop Way, so I think I'm ok with going with that instead of using AbstractBytes. Patch Hadoop Streaming Source to Support Cassandra IO - Key: CASSANDRA-3134 URL: https://issues.apache.org/jira/browse/CASSANDRA-3134 Project: Cassandra Issue Type: New Feature Components: Hadoop Reporter: Brandyn White Priority: Minor Labels: hadoop, hadoop_examples_streaming Original Estimate: 504h Remaining Estimate: 504h (text is a repost from [CASSANDRA-1497|https://issues.apache.org/jira/browse/CASSANDRA-1497]) I'm the author of the Hadoopy http://bwhite.github.com/hadoopy/ python library and I'm interested in taking another stab at streaming support. Hadoopy and Dumbo both use the TypedBytes format that is in CDH for communication with the streaming jar. A simple way to get this to work is modify the streaming code (make hadoop-cassandra-streaming.jar) so that it uses the same TypedBytes communication with streaming programs, but the actual job IO is using the Cassandra IO. The user would have the exact same streaming interface, but the user would specify the keyspace, etc using environmental variables. The benefits of this are 1. Easy implementation: Take the cloudera-patched version of streaming and change the IO, add environmental variable reading. 2. Only Client side: As the streaming jar is included in the job, no server side changes are required. 3. Simple maintenance: If the Hadoop Cassandra interface changes, then this would require the same simple fixup as any other Hadoop job. 4. The TypedBytes format supports all of the necessary Cassandara types (https://issues.apache.org/jira/browse/HADOOP-5450) 5. Compatible with existing streaming libraries: Hadoopy and dumbo would only need to know the path of this new streaming jar 6. No need for avro The negatives of this are 1. Duplicative code: This would be a dupe and patch of the streaming jar. This can be stored itself as a patch. 2. I'd have to check but this solution should work on a stock hadoop (cluster side) but it requires TypedBytes (client side) which can be included in the jar. I can code this up but I wanted to get some feedback from the community first. -- 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-3302) stop Cassandra result in hang
[ https://issues.apache.org/jira/browse/CASSANDRA-3302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13126858#comment-13126858 ] Jackson Chung commented on CASSANDRA-3302: -- indeed i was testing on trunk but not 1.0.0 but i have not tried to test using 1.0.0 to see if it fails there. i could give it a quick try stop Cassandra result in hang - Key: CASSANDRA-3302 URL: https://issues.apache.org/jira/browse/CASSANDRA-3302 Project: Cassandra Issue Type: Bug Affects Versions: 1.0.1 Reporter: Jackson Chung Assignee: T Jake Luciani testing this under trunk via a hacked package (replacing jars from 0.8.6 deb installation) When calling service cassandra stop, the Cassandra process hang: http://aep.appspot.com/display/i6aIUCkt4kz0HG5l2VszMM7QvLo/ The following logs is observed in the C* log: INFO [main] 2011-10-03 23:20:46,434 AbstractCassandraDaemon.java (line 270) Cassandra shutting down... INFO [main] 2011-10-03 23:20:46,434 CassandraDaemon.java (line 218) Stop listening to thrift clients Re-run this using 1.0.0 branch, (following the same hack procedure), C* stop properly, and the following is observed in the log: INFO [main] 2011-10-04 05:02:08,048 AbstractCassandraDaemon.java (line 270) Cassandra shutting down... INFO [main] 2011-10-04 05:02:08,049 CassandraDaemon.java (line 218) Stop listening to thrift clients INFO [Thread-2] 2011-10-04 05:02:08,318 MessagingService.java (line 482) Shutting down MessageService... INFO [Thread-2] 2011-10-04 05:02:08,319 MessagingService.java (line 497) Waiting for in-progress requests to complete INFO [ACCEPT-/10.83.77.171] 2011-10-04 05:02:08,319 MessagingService.java (line 637) MessagingService shutting down server thread. could this be related to CASSANDRA-3261 ? -- 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] [Reopened] (CASSANDRA-3149) Update CQL type names to match expected (SQL) behavor
[
https://issues.apache.org/jira/browse/CASSANDRA-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
paul cannon reopened CASSANDRA-3149:
So, this apparently didn't go far enough: the CQL parser still thinks date is
an ok type, and timestamp isn't. If you try to execute this with CQL in any
cassandra after this change:
{noformat}
CREATE COLUMNFAMILY foo ( KEY timestamp PRIMARY KEY );
{noformat}
..or use {{timestamp}} anywhere else a validator type is expected, you'll get
an IRE with {{no viable alternative at input 'timestamp'}}.
src/java/org/apache/cassandra/cql/Cql.g needs to have date changed to
timestamp. It looks like all the other types line up right.
Update CQL type names to match expected (SQL) behavor
-
Key: CASSANDRA-3149
URL: https://issues.apache.org/jira/browse/CASSANDRA-3149
Project: Cassandra
Issue Type: Improvement
Affects Versions: 0.8.0
Reporter: Jonathan Ellis
Assignee: Jonathan Ellis
Priority: Minor
Labels: cql
Fix For: 1.0.0
Attachments: 3149.txt
As discussed in CASSANDRA-3031, we should make the following changes:
- rename bytea to blob
- rename date to timestamp
- remove int, pending addition of CASSANDRA-3031 (bigint and varint will be
unchanged)
--
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=13126881#comment-13126881 ] Stephen Connolly commented on CASSANDRA-3300: - 52c42c62d8033802360aa3fd79e8992a3dd18f90 adds the ability to test with a non-internal cassandra server, e.g. * If you define the property cassandra.rpc.port then the profiles will switch and instead of using a locally started cassandra server, it will use the cassandra server on the specified port (cassandra.host defaults to localhost but that can be overridden too). mvn -Dcassandra.rpc.port=9170 -Dcassandra.host=10.0.0.5 * If you don't define the property it will launch a cassandra server via the cassandra-maven-plugin using random unused ports (and shut it down afterwards) 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 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] [Updated] (CASSANDRA-3196) Cassandra-CLI command should have --version option
[ https://issues.apache.org/jira/browse/CASSANDRA-3196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3196: --- Attachment: CASSANDRA-3196.patch 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-2749) fine-grained control over data directories
[ https://issues.apache.org/jira/browse/CASSANDRA-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13126899#comment-13126899 ] Pavel Yaskevich commented on CASSANDRA-2749: Looks better now but I don't like how you changed DescriptorTest especially testLegacy() userActionUtilsKey there is meant to be a CF name, so it seems like current version does not work correctly? fine-grained control over data directories -- Key: CASSANDRA-2749 URL: https://issues.apache.org/jira/browse/CASSANDRA-2749 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Jonathan Ellis Priority: Minor Fix For: 1.1 Attachments: 0001-Make-it-possible-to-put-column-families-in-subdirect.patch, 2749_backwards_compatible_v1.patch, 2749_backwards_compatible_v2.patch Currently Cassandra supports multiple data directories but no way to control what sstables are placed where. Particularly for systems with mixed SSDs and rotational disks, it would be nice to pin frequently accessed columnfamilies to the SSDs. Postgresql does this with tablespaces (http://www.postgresql.org/docs/9.0/static/manage-ag-tablespaces.html) but we should probably avoid using that name because of confusing similarity to keyspaces. -- 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
svn commit: r1183084 - in /cassandra/branches/cassandra-1.0: CHANGES.txt src/java/org/apache/cassandra/cql/Cql.g
Author: jbellis Date: Thu Oct 13 20:43:50 2011 New Revision: 1183084 URL: http://svn.apache.org/viewvc?rev=1183084view=rev Log: update CQL parser to accept timestamp instead of date patch by Paul Cannon; reviewed by jbellis for CASSANDRA-3149 Modified: cassandra/branches/cassandra-1.0/CHANGES.txt cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/cql/Cql.g Modified: cassandra/branches/cassandra-1.0/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-1.0/CHANGES.txt?rev=1183084r1=1183083r2=1183084view=diff == --- cassandra/branches/cassandra-1.0/CHANGES.txt (original) +++ cassandra/branches/cassandra-1.0/CHANGES.txt Thu Oct 13 20:43:50 2011 @@ -11,6 +11,7 @@ * Fix handling of tombstone by SSTableExport/Import (CASSANDRA-3357) * fix ColumnIndexer to use long offsets (CASSANDRA-3358) * limit nodetool to 32MB of heap (CASSANDRA-3124) + * (CQL) update parser to accept timestamp instead of date (CASSANDRA-3149) 1.0.0-final Modified: cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/cql/Cql.g URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/cql/Cql.g?rev=1183084r1=1183083r2=1183084view=diff == --- cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/cql/Cql.g (original) +++ cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/cql/Cql.g Thu Oct 13 20:43:50 2011 @@ -436,7 +436,7 @@ dropColumnFamilyStatement returns [Strin ; comparatorType -: 'blob' | 'ascii' | 'text' | 'varchar' | 'int' | 'varint' | 'bigint' | 'uuid' | 'counter' | 'boolean' | 'date' | 'float' | 'double' | 'decimal' +: 'blob' | 'ascii' | 'text' | 'varchar' | 'int' | 'varint' | 'bigint' | 'uuid' | 'counter' | 'boolean' | 'timestamp' | 'float' | 'double' | 'decimal' ; term returns [Term item]
[jira] [Resolved] (CASSANDRA-3149) Update CQL type names to match expected (SQL) behavor
[ https://issues.apache.org/jira/browse/CASSANDRA-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-3149. --- Resolution: Fixed done in 1.0 branch in r1183084 Update CQL type names to match expected (SQL) behavor - Key: CASSANDRA-3149 URL: https://issues.apache.org/jira/browse/CASSANDRA-3149 Project: Cassandra Issue Type: Improvement Affects Versions: 0.8.0 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Labels: cql Fix For: 1.0.0 Attachments: 3149.txt As discussed in CASSANDRA-3031, we should make the following changes: - rename bytea to blob - rename date to timestamp - remove int, pending addition of CASSANDRA-3031 (bigint and varint will be unchanged) -- 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-2749) fine-grained control over data directories
[ https://issues.apache.org/jira/browse/CASSANDRA-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13126910#comment-13126910 ] Marcus Eriksson commented on CASSANDRA-2749: ah that is a leftover from my first non-backwards-compatible patch it works even without the cf in the new File(...) fine-grained control over data directories -- Key: CASSANDRA-2749 URL: https://issues.apache.org/jira/browse/CASSANDRA-2749 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Jonathan Ellis Priority: Minor Fix For: 1.1 Attachments: 0001-Make-it-possible-to-put-column-families-in-subdirect.patch, 2749_backwards_compatible_v1.patch, 2749_backwards_compatible_v2.patch Currently Cassandra supports multiple data directories but no way to control what sstables are placed where. Particularly for systems with mixed SSDs and rotational disks, it would be nice to pin frequently accessed columnfamilies to the SSDs. Postgresql does this with tablespaces (http://www.postgresql.org/docs/9.0/static/manage-ag-tablespaces.html) but we should probably avoid using that name because of confusing similarity to keyspaces. -- 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-3226) Single faulty node brings down entire cluster. No reads/writes possible
[ https://issues.apache.org/jira/browse/CASSANDRA-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13126908#comment-13126908 ] Thibaut commented on CASSANDRA-3226: It hasn't reappeared so far, which is a good thing :-). I guess you can close the issue. If it reappears again I will let you know. Single faulty node brings down entire cluster. No reads/writes possible --- Key: CASSANDRA-3226 URL: https://issues.apache.org/jira/browse/CASSANDRA-3226 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.5 Environment: linux Reporter: Thibaut Attachments: jstack No client is able to read anything from the entire cluster anymore. This occured a few times so far, but I can't reproduce it. Looks like an OOM directly after starting up the node? Restarting the node solves the issue. I also have to kill the node with -9 because normal kill won't kill the node. Healty nodes: *.13: Mode: Normal Not sending any streams. Not receiving any streams. Pool NameActive Pending Completed Commandsn/a 15237 416868 Responses n/a 0 126721 *.14. Mode: Normal Not sending any streams. Not receiving any streams. Pool NameActive Pending Completed Commandsn/a 15387 437325 Responses n/a 0 131066 *.15: Mode: Normal Not sending any streams. Not receiving any streams. Pool NameActive Pending Completed Commandsn/a 15530 368771 Responses n/a 0 145168 etc... The pending commands at the healty nodes all increase. Faulty node before restart: /software/cassandra/bin/nodetool -h localhost info Token: f33 Gossip active: true Load : 130.67 GB Generation No: 1316197687 Uptime (seconds) : 137051 Heap Memory (MB) : 3580.22 / 3614.00 Data Center : datacenter1 Rack : rack1 Exceptions : 108 /software/cassandra/bin/nodetool -h localhost netstats Mode: Normal Not sending any streams. Not receiving any streams. Pool NameActive Pending Completed Commandsn/a 0 29696566 Responses n/a 560 26650981 Log excerpt: INFO [GossipStage:3] 2011-09-18 09:16:46,254 Gossiper.java (line 713) Node /192.168.0.11 has restarted, now UP again INFO [GossipStage:3] 2011-09-18 09:16:46,255 Gossiper.java (line 681) InetAddress /192.168.0.11 is now UP INFO [GossipStage:3] 2011-09-18 09:16:46,255 StorageService.java (line 815) Node /192.168.0.11 state jump to normal INFO [GossipStage:3] 2011-09-18 09:16:46,257 StorageService.java (line 815) Node /192.168.0.11 state jump to normal INFO [GossipStage:3] 2011-09-18 09:16:54,984 StorageService.java (line 815) Node /192.168.0.6 state jump to normal INFO [GossipStage:3] 2011-09-18 09:16:54,984 Gossiper.java (line 681) InetAddress /192.168.0.6 is now UP INFO [GossipStage:3] 2011-09-18 09:16:56,262 StorageService.java (line 815) Node /192.168.0.18 state jump to normal INFO [GossipStage:3] 2011-09-18 09:16:56,263 Gossiper.java (line 681) InetAddress /192.168.0.18 is now UP INFO [GossipStage:3] 2011-09-18 09:17:06,272 Gossiper.java (line 713) Node /192.168.0.1 has restarted, now UP again INFO [GossipStage:3] 2011-09-18 09:17:06,272 Gossiper.java (line 681) InetAddress /192.168.0.1 is now UP INFO [GossipStage:3] 2011-09-18 09:17:06,272 StorageService.java (line 815) Node /192.168.0.1 state jump to normal INFO [HintedHandoff:1] 2011-09-18 09:20:49,846 HintedHandOffManager.java (line 323) Started hinted handoff for endpoint /192.168.0.8 INFO [HintedHandoff:1] 2011-09-18 09:20:49,847 HintedHandOffManager.java (line 379) Finished hinted handoff of 0 rows to endpoint /192.168.0.8 INFO [HintedHandoff:1] 2011-09-18 09:21:45,430 HintedHandOffManager.java (line 323) Started hinted handoff for endpoint /192.168.0.7 INFO [HintedHandoff:1] 2011-09-18 09:21:45,696 HintedHandOffManager.java (line 379) Finished hinted handoff of 0 rows to endpoint /192.168.0.7 INFO [HintedHandoff:1] 2011-09-18 09:21:52,432 HintedHandOffManager.java (line 323) Started hinted handoff for endpoint /192.168.0.20 INFO [HintedHandoff:1] 2011-09-18 09:21:52,432 HintedHandOffManager.java (line 379) Finished hinted handoff of 0 rows to endpoint /192.168.0.20 INFO [HintedHandoff:1] 2011-09-18 09:22:12,469 HintedHandOffManager.java (line 323) Started hinted handoff for endpoint /192.168.0.9 INFO [HintedHandoff:1] 2011-09-18
[jira] [Resolved] (CASSANDRA-3226) Single faulty node brings down entire cluster. No reads/writes possible
[ https://issues.apache.org/jira/browse/CASSANDRA-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-3226. --- Resolution: Cannot Reproduce sounds good, thanks! Single faulty node brings down entire cluster. No reads/writes possible --- Key: CASSANDRA-3226 URL: https://issues.apache.org/jira/browse/CASSANDRA-3226 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.5 Environment: linux Reporter: Thibaut Attachments: jstack No client is able to read anything from the entire cluster anymore. This occured a few times so far, but I can't reproduce it. Looks like an OOM directly after starting up the node? Restarting the node solves the issue. I also have to kill the node with -9 because normal kill won't kill the node. Healty nodes: *.13: Mode: Normal Not sending any streams. Not receiving any streams. Pool NameActive Pending Completed Commandsn/a 15237 416868 Responses n/a 0 126721 *.14. Mode: Normal Not sending any streams. Not receiving any streams. Pool NameActive Pending Completed Commandsn/a 15387 437325 Responses n/a 0 131066 *.15: Mode: Normal Not sending any streams. Not receiving any streams. Pool NameActive Pending Completed Commandsn/a 15530 368771 Responses n/a 0 145168 etc... The pending commands at the healty nodes all increase. Faulty node before restart: /software/cassandra/bin/nodetool -h localhost info Token: f33 Gossip active: true Load : 130.67 GB Generation No: 1316197687 Uptime (seconds) : 137051 Heap Memory (MB) : 3580.22 / 3614.00 Data Center : datacenter1 Rack : rack1 Exceptions : 108 /software/cassandra/bin/nodetool -h localhost netstats Mode: Normal Not sending any streams. Not receiving any streams. Pool NameActive Pending Completed Commandsn/a 0 29696566 Responses n/a 560 26650981 Log excerpt: INFO [GossipStage:3] 2011-09-18 09:16:46,254 Gossiper.java (line 713) Node /192.168.0.11 has restarted, now UP again INFO [GossipStage:3] 2011-09-18 09:16:46,255 Gossiper.java (line 681) InetAddress /192.168.0.11 is now UP INFO [GossipStage:3] 2011-09-18 09:16:46,255 StorageService.java (line 815) Node /192.168.0.11 state jump to normal INFO [GossipStage:3] 2011-09-18 09:16:46,257 StorageService.java (line 815) Node /192.168.0.11 state jump to normal INFO [GossipStage:3] 2011-09-18 09:16:54,984 StorageService.java (line 815) Node /192.168.0.6 state jump to normal INFO [GossipStage:3] 2011-09-18 09:16:54,984 Gossiper.java (line 681) InetAddress /192.168.0.6 is now UP INFO [GossipStage:3] 2011-09-18 09:16:56,262 StorageService.java (line 815) Node /192.168.0.18 state jump to normal INFO [GossipStage:3] 2011-09-18 09:16:56,263 Gossiper.java (line 681) InetAddress /192.168.0.18 is now UP INFO [GossipStage:3] 2011-09-18 09:17:06,272 Gossiper.java (line 713) Node /192.168.0.1 has restarted, now UP again INFO [GossipStage:3] 2011-09-18 09:17:06,272 Gossiper.java (line 681) InetAddress /192.168.0.1 is now UP INFO [GossipStage:3] 2011-09-18 09:17:06,272 StorageService.java (line 815) Node /192.168.0.1 state jump to normal INFO [HintedHandoff:1] 2011-09-18 09:20:49,846 HintedHandOffManager.java (line 323) Started hinted handoff for endpoint /192.168.0.8 INFO [HintedHandoff:1] 2011-09-18 09:20:49,847 HintedHandOffManager.java (line 379) Finished hinted handoff of 0 rows to endpoint /192.168.0.8 INFO [HintedHandoff:1] 2011-09-18 09:21:45,430 HintedHandOffManager.java (line 323) Started hinted handoff for endpoint /192.168.0.7 INFO [HintedHandoff:1] 2011-09-18 09:21:45,696 HintedHandOffManager.java (line 379) Finished hinted handoff of 0 rows to endpoint /192.168.0.7 INFO [HintedHandoff:1] 2011-09-18 09:21:52,432 HintedHandOffManager.java (line 323) Started hinted handoff for endpoint /192.168.0.20 INFO [HintedHandoff:1] 2011-09-18 09:21:52,432 HintedHandOffManager.java (line 379) Finished hinted handoff of 0 rows to endpoint /192.168.0.20 INFO [HintedHandoff:1] 2011-09-18 09:22:12,469 HintedHandOffManager.java (line 323) Started hinted handoff for endpoint /192.168.0.9 INFO [HintedHandoff:1] 2011-09-18 09:22:12,469 HintedHandOffManager.java (line 379) Finished hinted handoff of 0 rows to endpoint /192.168.0.9 INFO
[jira] [Commented] (CASSANDRA-3127) Message (inter-node) compression
[ https://issues.apache.org/jira/browse/CASSANDRA-3127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13126944#comment-13126944 ] Jonathan Ellis commented on CASSANDRA-3127: --- It would be pretty easy to configure off, on, and cross-dc. In the cross-dc case, OutboundTcpConnection could just ask the snitch (DatabaseDescriptor.getEndpointSnitch) if the target node is in another DC, and make the compression decision based on that. Message (inter-node) compression Key: CASSANDRA-3127 URL: https://issues.apache.org/jira/browse/CASSANDRA-3127 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Sylvain Lebresne Priority: Minor CASSANDRA-3015 adds compression of streams. But it could be useful to also compress some messages. Compressing messages is easy, but what may be little bit trickier is when and what messages to compress to get the best performances. The simple solution would be to just have it either always on or always off. But for very small messages (gossip?) that may be counter-productive. On the other side of the spectrum, this is likely always a good choice to compress for say the exchange of merkle trees across data-centers. We could maybe define a size of messages after which we start to compress. Maybe the option to only compress for cross data-center messages would be useful too (but I may also just be getting carried away). -- 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-3127) Message (inter-node) compression
[ https://issues.apache.org/jira/browse/CASSANDRA-3127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13126957#comment-13126957 ] Jonathan Ellis commented on CASSANDRA-3127: --- bq. define a size of messages after which we start to compress Let's go with this: intranode_message_compression_threshold 0 means compress messages larger than it. = 0 means off. Let's leave off the cross-dc complexity for now. The code should be fairly self-contained in OutboundTcpConnection and IncomingTcpConnection. FileStreamTask provides an example of using compression over a socket. Message (inter-node) compression Key: CASSANDRA-3127 URL: https://issues.apache.org/jira/browse/CASSANDRA-3127 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Sylvain Lebresne Priority: Minor CASSANDRA-3015 adds compression of streams. But it could be useful to also compress some messages. Compressing messages is easy, but what may be little bit trickier is when and what messages to compress to get the best performances. The simple solution would be to just have it either always on or always off. But for very small messages (gossip?) that may be counter-productive. On the other side of the spectrum, this is likely always a good choice to compress for say the exchange of merkle trees across data-centers. We could maybe define a size of messages after which we start to compress. Maybe the option to only compress for cross data-center messages would be useful too (but I may also just be getting carried away). -- 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-3127) Message (inter-node) compression
[ https://issues.apache.org/jira/browse/CASSANDRA-3127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-3127: -- Comment: was deleted (was: It would be pretty easy to configure off, on, and cross-dc. In the cross-dc case, OutboundTcpConnection could just ask the snitch (DatabaseDescriptor.getEndpointSnitch) if the target node is in another DC, and make the compression decision based on that.) Message (inter-node) compression Key: CASSANDRA-3127 URL: https://issues.apache.org/jira/browse/CASSANDRA-3127 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Sylvain Lebresne Priority: Minor CASSANDRA-3015 adds compression of streams. But it could be useful to also compress some messages. Compressing messages is easy, but what may be little bit trickier is when and what messages to compress to get the best performances. The simple solution would be to just have it either always on or always off. But for very small messages (gossip?) that may be counter-productive. On the other side of the spectrum, this is likely always a good choice to compress for say the exchange of merkle trees across data-centers. We could maybe define a size of messages after which we start to compress. Maybe the option to only compress for cross data-center messages would be useful too (but I may also just be getting carried away). -- 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-3101) Should check for errors when calling /bin/ln
[ https://issues.apache.org/jira/browse/CASSANDRA-3101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-3101: -- Reviewer: thepaul Fix Version/s: 1.0.1 Assignee: Pavel Yaskevich Should check for errors when calling /bin/ln Key: CASSANDRA-3101 URL: https://issues.apache.org/jira/browse/CASSANDRA-3101 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.4 Reporter: paul cannon Assignee: Pavel Yaskevich Priority: Minor Labels: lhf Fix For: 1.0.1 It looks like cassandra.utils.CLibrary.createHardLinkWithExec() does not check for any errors in the execution of the hard-link-making utility. This could be bad if, for example, the user has put the snapshot directory on a different filesystem from the data directory. The hard linking would fail and the sstable snapshots would not exist, but no error would be reported. It does look like errors with the more direct JNA link() call are handled correctly- an exception is thrown. The WithExec version should probably do the same thing. Definitely it would be enough to check the process exit value from /bin/ln for nonzero in the *nix case, but I don't know whether 'fsutil hardlink create' or 'cmd /c mklink /H' return nonzero on failure. For bonus points, use any output from the Process's error stream in the text of the exception, to aid in debugging problems. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3073) liveSize() calculation is wrong in case of overwrite
[
https://issues.apache.org/jira/browse/CASSANDRA-3073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13126973#comment-13126973
]
Jonathan Ellis commented on CASSANDRA-3073:
---
bq. could we add a config option to control to choose the SlabAllocator or the
native one
I'm fine with adding an option.
bq. by the time minor GC happens, some old columns in the Region has been
superceded and are useless
the Column objects themselves aren't the problem, since they are all the same
[shallow] size. It's the name, value, and key buffers that cause fragmentation,
and those are what we clone into the arena regions.
liveSize() calculation is wrong in case of overwrite
Key: CASSANDRA-3073
URL: https://issues.apache.org/jira/browse/CASSANDRA-3073
Project: Cassandra
Issue Type: Bug
Reporter: Yang Yang
Priority: Minor
Attachments:
0001-liveSize-is-different-from-throughput-particularly-w.patch
currently liveSize() is the sum of currentThroughput.
this definition is wrong if most of the operations are overwrite, or counter
(which is essentially overwrite).
for example, the following code should always keep a single entry in db, with
one row, one cf, one column, and supposedly should have a size of only about
100 bytes.
connect localhost/9160;
create keyspace blah;
use blah;
create column family cf2 with memtable_throughput=1024 and
memtable_operations=1 ;
set the cassandra.yaml
memtable_total_space_in_mb: 20
to make the error appear faster (but if u set to default, still same issue
will appear)
then we use a simple pycassa script:
pool = pycassa.connect('blah')
mycf = pycassa.ColumnFamily(pool,cf2);
for x in range(1,1000) :
... xx = mycf.insert('key1',{'col1':{}.format(x)})
...
you will see sstables being generated with only sizes of a few k, though we
set the CF options to get high SSTable sizes
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3073) liveSize() calculation is wrong in case of overwrite
[
https://issues.apache.org/jira/browse/CASSANDRA-3073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis reassigned CASSANDRA-3073:
-
Assignee: Yang Yang
liveSize() calculation is wrong in case of overwrite
Key: CASSANDRA-3073
URL: https://issues.apache.org/jira/browse/CASSANDRA-3073
Project: Cassandra
Issue Type: Bug
Reporter: Yang Yang
Assignee: Yang Yang
Priority: Minor
Attachments:
0001-liveSize-is-different-from-throughput-particularly-w.patch
currently liveSize() is the sum of currentThroughput.
this definition is wrong if most of the operations are overwrite, or counter
(which is essentially overwrite).
for example, the following code should always keep a single entry in db, with
one row, one cf, one column, and supposedly should have a size of only about
100 bytes.
connect localhost/9160;
create keyspace blah;
use blah;
create column family cf2 with memtable_throughput=1024 and
memtable_operations=1 ;
set the cassandra.yaml
memtable_total_space_in_mb: 20
to make the error appear faster (but if u set to default, still same issue
will appear)
then we use a simple pycassa script:
pool = pycassa.connect('blah')
mycf = pycassa.ColumnFamily(pool,cf2);
for x in range(1,1000) :
... xx = mycf.insert('key1',{'col1':{}.format(x)})
...
you will see sstables being generated with only sizes of a few k, though we
set the CF options to get high SSTable sizes
--
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-2749) fine-grained control over data directories
[ https://issues.apache.org/jira/browse/CASSANDRA-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13126980#comment-13126980 ] Pavel Yaskevich commented on CASSANDRA-2749: I forgot to mention - would be great to see a test for RecursiveGlob and please put a license banner on top of that file like we do everywhere else. fine-grained control over data directories -- Key: CASSANDRA-2749 URL: https://issues.apache.org/jira/browse/CASSANDRA-2749 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Jonathan Ellis Priority: Minor Fix For: 1.1 Attachments: 0001-Make-it-possible-to-put-column-families-in-subdirect.patch, 2749_backwards_compatible_v1.patch, 2749_backwards_compatible_v2.patch Currently Cassandra supports multiple data directories but no way to control what sstables are placed where. Particularly for systems with mixed SSDs and rotational disks, it would be nice to pin frequently accessed columnfamilies to the SSDs. Postgresql does this with tablespaces (http://www.postgresql.org/docs/9.0/static/manage-ag-tablespaces.html) but we should probably avoid using that name because of confusing similarity to keyspaces. -- 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=13126986#comment-13126986 ] Jonathan Ellis commented on CASSANDRA-3300: --- bq. This ticket is technically done, the only thing remaining is to actually remove the drivers/ directory, and of course, the build and test targets from build.xml. +1 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 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
svn commit: r1183124 - /cassandra/trunk/build.xml
Author: eevans
Date: Thu Oct 13 21:53:53 2011
New Revision: 1183124
URL: http://svn.apache.org/viewvc?rev=1183124view=rev
Log:
remove driver build/test
Patch by eevans; reviewed by jbellis for CASSANDRA-3300
Modified:
cassandra/trunk/build.xml
Modified: cassandra/trunk/build.xml
URL:
http://svn.apache.org/viewvc/cassandra/trunk/build.xml?rev=1183124r1=1183123r2=1183124view=diff
==
--- cassandra/trunk/build.xml (original)
+++ cassandra/trunk/build.xml Thu Oct 13 21:53:53 2011
@@ -36,7 +36,6 @@
property name=build.src value=${basedir}/src/
property name=build.src.java value=${basedir}/src/java/
property name=build.src.resources value=${basedir}/src/resources/
-property name=build.src.driver value=${basedir}/drivers/java/src /
property name=avro.src value=${basedir}/src/avro/
property name=build.src.gen-java value=${basedir}/src/gen-java/
property name=build.lib value=${basedir}/lib/
@@ -47,7 +46,6 @@
property name=build.classes value=${build.dir}/classes/
property name=build.classes.main value=${build.classes}/main /
property name=build.classes.thrift value=${build.classes}/thrift /
-property name=build.classes.cql value=${build.classes}/cql /
property name=javadoc.dir value=${build.dir}/javadoc/
property name=javadoc.jars.dir value=${build.dir}/javadocs/
property name=interface.dir value=${basedir}/interface/
@@ -61,11 +59,9 @@
property name=test.data value=${test.dir}/data/
property name=test.name value=*Test/
property name=test.unit.src value=${test.dir}/unit/
-property name=test.src.driver value=${basedir}/drivers/java/test/
property name=test.long.src value=${test.dir}/long/
property name=test.distributed.src value=${test.dir}/distributed/
property name=dist.dir value=${build.dir}/dist/
-property name=cql.driver.version value=1.0.4 /
condition property=version value=${base.version}
isset property=release/
/condition
@@ -162,7 +158,6 @@
message=Not a source artifact, stopping here. /
mkdir dir=${build.classes.main}/
mkdir dir=${build.classes.thrift}/
-mkdir dir=${build.classes.cql}/
mkdir dir=${test.lib}/
mkdir dir=${test.classes}/
mkdir dir=${build.src.gen-java}/
@@ -400,7 +395,6 @@ url=${svn.entry.url}?pathrev=${svn.entry
dependency groupId=log4j artifactId=log4j version=1.2.16 /
dependency groupId=org.apache.cassandra
artifactId=cassandra-all version=${version} /
dependency groupId=org.apache.cassandra
artifactId=cassandra-thrift version=${version} /
- dependency groupId=org.apache.cassandra
artifactId=cassandra-cql version=${version} /
/dependencyManagement
developer id=alakshman name=Avinash Lakshman/
developer id=antelder name=Anthony Elder/
@@ -519,22 +513,6 @@ url=${svn.entry.url}?pathrev=${svn.entry
scm connection=${scm.connection}
developerConnection=${scm.developerConnection} url=${scm.url}/
dependency groupId=com.google.guava artifactId=guava/
/artifact:pom
- artifact:pom id=cql-pom
-artifactId=cassandra-cql
-url=http://cassandra.apache.org;
-name=Apache Cassandra
-parent groupId=org.apache.cassandra
-artifactId=cassandra-parent
-version=${version}/
-scm connection=${scm.connection}
developerConnection=${scm.developerConnection} url=${scm.url}/
-dependency groupId=com.google.guava artifactId=guava/
-dependency groupId=org.slf4j artifactId=slf4j-api/
-dependency groupId=org.apache.thrift artifactId=libthrift/
-dependency groupId=org.apache.cassandra
artifactId=cassandra-thrift/
-dependency groupId=org.apache.cassandra artifactId=cassandra-all/
-!-- because cassandra-all uses log4j, and we need cassandra-all,
consumers must use log4j, so force log4j version of slf4j --
-dependency groupId=org.slf4j artifactId=slf4j-log4j12
scope=runtime/
- /artifact:pom
artifact:pom id=dist-pom
artifactId=apache-cassandra
@@ -704,11 +682,6 @@ url=${svn.entry.url}?pathrev=${svn.entry
src path=${build.src.gen-java}/
classpath refid=cassandra.classpath/
/javac
-javac debug=true debuglevel=${debuglevel}
- destdir=${build.classes.cql} includeantruntime=false
-src path=${build.src.driver} /
-classpath refid=cassandra.classpath/
-/javac
copy todir=${build.classes.main}
fileset dir=${build.src.resources} /
/copy
@@ -786,20 +759,6 @@ url=${svn.entry.url}?pathrev=${svn.entry
attribute name=Implementation-Vendor value=Apache/
/manifest
/jar
-
- !-- CQL driver Jar --
- artifact:writepom
[jira] [Assigned] (CASSANDRA-3016) CQL: double and float types do not seem to work properly
[
https://issues.apache.org/jira/browse/CASSANDRA-3016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis reassigned CASSANDRA-3016:
-
Assignee: paul cannon (was: Tyler Hobbs)
Paul, is this still a problem w/ latest dbapi driver? if so, can you create a
ticket in that project?
CQL: double and float types do not seem to work properly
Key: CASSANDRA-3016
URL: https://issues.apache.org/jira/browse/CASSANDRA-3016
Project: Cassandra
Issue Type: Bug
Reporter: Matt Hollingsworth
Assignee: paul cannon
Was asked to make this from the mailing list by Jonathan Ellis.
I'm just getting started with CQL, and decided to do a simple test
create/insert/select thing to check that everything was working. Most
everything seems to work, but it appears that double/floats do not work
properly. Here's what I did:
test.cql
--
CREATE KEYSPACE test with strategy_class = 'SimpleStrategy' and
strategy_options:replication_factor=1;
USE test;
CREATE COLUMNFAMILY testvals (
key varchar PRIMARY KEY,
value float
);
INSERT INTO testvals (key,value) VALUES ('k1',341.32355);
SELECT key, value FROM testvals;
--
The output is this:
cqlsh localhost scripts/test.cql
key |value |
k1 | @uU-B??? |
Same thing happens when I do value double. I also tried to do this from the
python driver, gives the same weirdness:
In [2]: import cql
In [3]: con = cql.connect(localhost,keyspace=test)
In [4]: cursor = con.cursor()
In [5]: cursor.execute(SELECT * from testvals)
Out[5]: True
In [6]: for r in cursor: print r
...:
[u'k1', '?\xf8\x00\x00\x00\x00\x00\x00']
--
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-3014) AnitEntropy/MerkleTree Error
[ https://issues.apache.org/jira/browse/CASSANDRA-3014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-3014. --- Resolution: Cannot Reproduce AnitEntropy/MerkleTree Error Key: CASSANDRA-3014 URL: https://issues.apache.org/jira/browse/CASSANDRA-3014 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.0 Reporter: Hefeng Yuan Priority: Minor Hi, We are seeing some AntiEntropy error in our production servers, since it's hard to repro in other env, pasting the stack track here for some clue. We're using a cluster of 2 data centers, 9 nodes, 6 for online traffic, 3 for Brisk BI. Our RF is Cassandra:5, Brisk:1. Our Cassandra server version is 0.8.0. Data is written using Hector 0.7.0-20 and cassandra 0.7.2 library. Partitioner is random. Our nodetool repair is scheduled once per week. The exception stack is appended in the end. Any help is appreciated. Thanks, Hefeng ERROR [AntiEntropyStage:2] 2011-08-08 04:24:39,556 AbstractCassandraDaemon.java (line 113) Fatal exception in thread Thread[AntiEntropyStage:2,5,main] java.lang.AssertionError at org.apache.cassandra.utils.MerkleTree.inc(MerkleTree.java:154) at org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:262) at org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:273) at org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284) at org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284) at org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:273) at org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284) at org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284) at org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284) at org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:273) at org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284) at org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:273) at org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284) at org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:273) at org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284) at org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:273) at org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:273) at org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284) at org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284) at org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284) at org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:273) at org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284) at org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284) at org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284) at org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284) at org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:273) at org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284) at org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:273) at org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284) at org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284) at org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:273) at org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:273) at org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:273) at org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:273) at org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284) at org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:273) at org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284) at org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:273) at org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:284) at org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:273) at org.apache.cassandra.utils.MerkleTree.differenceHelper(MerkleTree.java:273) at
[jira] [Updated] (CASSANDRA-2999) cassandra-cli doesn't accept floats for memtable_thoughput
[ https://issues.apache.org/jira/browse/CASSANDRA-2999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2999: -- Reviewer: thobbs Affects Version/s: (was: 0.8.2) Fix Version/s: 1.0.1 Assignee: Pavel Yaskevich cassandra-cli doesn't accept floats for memtable_thoughput -- Key: CASSANDRA-2999 URL: https://issues.apache.org/jira/browse/CASSANDRA-2999 Project: Cassandra Issue Type: Bug Components: Tools Reporter: Tyler Hobbs Assignee: Pavel Yaskevich Priority: Trivial Fix For: 1.0.1 The cassandra-cli does not accept floats for the value of memtable_throughput (memtable_throughput_in_mb). This means that you can't specify a value with sub-MB resolution, such as 0.5. This probably doesn't matter much for production, but it's useful for testing really low memtable thresholds. -- 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-3359) snapshot should include manifest under leveledcompaction
snapshot should include manifest under leveledcompaction Key: CASSANDRA-3359 URL: https://issues.apache.org/jira/browse/CASSANDRA-3359 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.0.0 Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Fix For: 1.0.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
svn commit: r1183130 - in /cassandra/trunk/drivers/java: ./ src/org/apache/cassandra/cql/jdbc/ test/conf/ test/org/apache/cassandra/cql/ test/org/apache/cassandra/cql/jdbc/
Author: eevans Date: Thu Oct 13 22:02:38 2011 New Revision: 1183130 URL: http://svn.apache.org/viewvc?rev=1183130view=rev Log: remove what remains of the drivers tree Patch by eevans; reviewed by jbellis for CASSANDRA-3300 Removed: 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
[jira] [Commented] (CASSANDRA-2967) Only bind JMX to the same IP address that is being used in Cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-2967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13127004#comment-13127004 ] Jonathan Ellis commented on CASSANDRA-2967: --- Norman, are you still planning to tackle this? Only bind JMX to the same IP address that is being used in Cassandra Key: CASSANDRA-2967 URL: https://issues.apache.org/jira/browse/CASSANDRA-2967 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.8.2 Reporter: Joaquin Casares Priority: Minor Labels: lhf The setup is 5 nodes in each data center are all running on one physical test machine and even though the repair was run against the correct IP the wrong JMX port was used. As a result, instead of repairing all 5 nodes I was repairing the same node 5 times. It would be nice if Cassandra's JMX would bind to only the IP address on which its thrift/RPC services are listening on instead of binding to all IP's on the box. -- 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-3300) relocate Java (JDBC) CQL driver
[ https://issues.apache.org/jira/browse/CASSANDRA-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Evans resolved CASSANDRA-3300. --- Resolution: Fixed Assignee: Eric Evans committed, and drivers/ removed. 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
svn commit: r1183134 - /cassandra/trunk/doc/cql/CQL.textile
Author: eevans
Date: Thu Oct 13 22:07:31 2011
New Revision: 1183134
URL: http://svn.apache.org/viewvc?rev=1183134view=rev
Log:
minor formatting fixes to doc
Patch by eevans; reviewed by jbellis for CASSANDRA-3353
Modified:
cassandra/trunk/doc/cql/CQL.textile
Modified: cassandra/trunk/doc/cql/CQL.textile
URL:
http://svn.apache.org/viewvc/cassandra/trunk/doc/cql/CQL.textile?rev=1183134r1=1183133r2=1183134view=diff
==
--- cassandra/trunk/doc/cql/CQL.textile (original)
+++ cassandra/trunk/doc/cql/CQL.textile Thu Oct 13 22:07:31 2011
@@ -197,7 +197,7 @@ h2. BATCH
_Synopsis:_
-bc.
+bc.
BATCH BEGIN BATCH [USING CONSISTENCY LEVEL [AND TIMESTAMP timestamp]]
INSERT or UPDATE or DELETE statements separated by semicolon or end of
line
APPLY BATCH
@@ -210,7 +210,7 @@ _NOTE: While there are no isolation guar
_Example:_
-bc.
+bc.
BEGIN BATCH USING CONSISTENCY QUORUM
INSERT INTO users (KEY, password, name) VALUES ('user2', 'ch@ngem3b',
'second user')
UPDATE users SET password = 'ps22dhds' WHERE KEY = 'user2'
@@ -384,20 +384,19 @@ Versioning of the CQL language adheres t
h1. Changes
-pre.
-Fri, 09 Sep 2011 11:43:00 -0500 - Jonathan Ellis
+pre. Fri, 09 Sep 2011 11:43:00 -0500 - Jonathan Ellis
* add int data type
-Wed, 07 Sep 2011 09:01:00 -0500 - Jonathan Ellis
+pre. Wed, 07 Sep 2011 09:01:00 -0500 - Jonathan Ellis
* Updated version to 2.0; Documented row-based count()
* Updated list of supported data types
-Wed, 10 Aug 2011 11:22:00 -0500 - Eric Evans
+pre. Wed, 10 Aug 2011 11:22:00 -0500 - Eric Evans
* Improved INSERT vs. UPDATE wording.
* Documented counter column incr/descr.
-Sat, 01 Jun 2011 15:58:00 -0600 - Pavel Yaskevich
+pre. Sat, 01 Jun 2011 15:58:00 -0600 - Pavel Yaskevich
* Updated to support ALTER (CASSANDRA-1709)
-Tue, 22 Mar 2011 18:10:28 -0700 - Eric Evans eev...@rackspace.com
+pre. Tue, 22 Mar 2011 18:10:28 -0700 - Eric Evans eev...@rackspace.com
* Initial version, 1.0.0
[jira] [Commented] (CASSANDRA-3005) OutboundTcpConnection's sending queue grows unboundedly without any backpressure logic
[ https://issues.apache.org/jira/browse/CASSANDRA-3005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13127008#comment-13127008 ] Jonathan Ellis commented on CASSANDRA-3005: --- Melvin, are you working on a patch incorporating Stu's feedback? OutboundTcpConnection's sending queue grows unboundedly without any backpressure logic -- Key: CASSANDRA-3005 URL: https://issues.apache.org/jira/browse/CASSANDRA-3005 Project: Cassandra Issue Type: Improvement Reporter: Melvin Wang Assignee: Melvin Wang Attachments: c3005.patch OutboundTcpConnection's sending queue unconditionally queues up the request and process them in sequence. Thinking about tagging the message coming in with timestamp and drop them before actually sending it if the message stays in the queue for too long, which is defined by the message's own time out value. -- 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-2987) maven-ant-tasks should have more than one repo defined
[ https://issues.apache.org/jira/browse/CASSANDRA-2987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13127007#comment-13127007 ] Brandon Williams commented on CASSANDRA-2987: - bq. We should be pointing to repo1.maven.org which will resolve via Geo-DNS to the local mirror This still has the problem of returning an address you possibly don't have a route to for whatever reason, and since it's the only repo defined is still fails. I'd like it to try at least one other host. maven-ant-tasks should have more than one repo defined -- Key: CASSANDRA-2987 URL: https://issues.apache.org/jira/browse/CASSANDRA-2987 Project: Cassandra Issue Type: Improvement Reporter: Brandon Williams Assignee: Stephen Connolly Priority: Trivial If, for whatever reason, repo2.maven.org is down or unreachable, you can no longer build cassandra (unless you already have all the deps). -- 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
svn commit: r1183135 - /cassandra/trunk/doc/cql/CQL.textile
Author: eevans Date: Thu Oct 13 22:08:28 2011 New Revision: 1183135 URL: http://svn.apache.org/viewvc?rev=1183135view=rev Log: bring term info current w/ recent changes Patch by eevans; reviewed by jbellis for CASSANDRA-3353 Modified: cassandra/trunk/doc/cql/CQL.textile Modified: cassandra/trunk/doc/cql/CQL.textile URL: http://svn.apache.org/viewvc/cassandra/trunk/doc/cql/CQL.textile?rev=1183135r1=1183134r2=1183135view=diff == --- cassandra/trunk/doc/cql/CQL.textile (original) +++ cassandra/trunk/doc/cql/CQL.textile Thu Oct 13 22:08:28 2011 @@ -368,10 +368,10 @@ How column name/value terms are interpre |uuid|The string @now@, to represent a type-1 (time-based) UUID with a date-time component based on the current time| |uuid|Numeric value representing milliseconds since epoch| |uuid|An iso8601 timestamp:http://en.wikipedia.org/wiki/8601| -|int|Integer value capable of fitting in 8 bytes (same as bigint)| +|int|Integer value capable of fitting in 4 bytes| |bigint|Integer value capable of fitting in 8 bytes| |varint|Integer value of arbitrary size| -|bytea|Hex-encoded strings (converted directly to the corresponding bytes)| +|blob|Hex-encoded strings (converted directly to the corresponding bytes)| h1. Versioning
[jira] [Commented] (CASSANDRA-3016) CQL: double and float types do not seem to work properly
[
https://issues.apache.org/jira/browse/CASSANDRA-3016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13127015#comment-13127015
]
paul cannon commented on CASSANDRA-3016:
Yes, still a problem.
CQL: double and float types do not seem to work properly
Key: CASSANDRA-3016
URL: https://issues.apache.org/jira/browse/CASSANDRA-3016
Project: Cassandra
Issue Type: Bug
Reporter: Matt Hollingsworth
Assignee: paul cannon
Was asked to make this from the mailing list by Jonathan Ellis.
I'm just getting started with CQL, and decided to do a simple test
create/insert/select thing to check that everything was working. Most
everything seems to work, but it appears that double/floats do not work
properly. Here's what I did:
test.cql
--
CREATE KEYSPACE test with strategy_class = 'SimpleStrategy' and
strategy_options:replication_factor=1;
USE test;
CREATE COLUMNFAMILY testvals (
key varchar PRIMARY KEY,
value float
);
INSERT INTO testvals (key,value) VALUES ('k1',341.32355);
SELECT key, value FROM testvals;
--
The output is this:
cqlsh localhost scripts/test.cql
key |value |
k1 | @uU-B??? |
Same thing happens when I do value double. I also tried to do this from the
python driver, gives the same weirdness:
In [2]: import cql
In [3]: con = cql.connect(localhost,keyspace=test)
In [4]: cursor = con.cursor()
In [5]: cursor.execute(SELECT * from testvals)
Out[5]: True
In [6]: for r in cursor: print r
...:
[u'k1', '?\xf8\x00\x00\x00\x00\x00\x00']
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-2893) Add row-level isolation
[ https://issues.apache.org/jira/browse/CASSANDRA-2893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-2893: - Assignee: Sylvain Lebresne Add row-level isolation --- Key: CASSANDRA-2893 URL: https://issues.apache.org/jira/browse/CASSANDRA-2893 Project: Cassandra Issue Type: Improvement Reporter: Jonathan Ellis Assignee: Sylvain Lebresne Priority: Minor This could be done using an the atomic ConcurrentMap operations from the Memtable and something like http://code.google.com/p/pcollections/ to replace the ConcurrentSkipListMap in ThreadSafeSortedColumns. The trick is that pcollections does not provide a SortedMap, so we probably need to write our own. Googling [persistent sortedmap] I found http://code.google.com/p/actord/source/browse/trunk/actord/src/main/scala/ff/collection (in scala) and http://clojure.org/data_structures#Data Structures-Maps. -- 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
buildbot failure in ASF Buildbot on cassandra-trunk
The Buildbot has detected a new failure on builder cassandra-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/cassandra-trunk/builds/1723 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: isis_ubuntu Build Reason: scheduler Build Source Stamp: [branch cassandra/trunk] 1183134 Blamelist: eevans BUILD FAILED: failed compile sincerely, -The Buildbot
[jira] [Resolved] (CASSANDRA-2871) improve cfstats output
[ https://issues.apache.org/jira/browse/CASSANDRA-2871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-2871. --- Resolution: Later Assignee: (was: Wojciech Meler) Closing for inactivity. I also note that I'm unwilling to compromise human-readability to get grep-friendliness. improve cfstats output -- Key: CASSANDRA-2871 URL: https://issues.apache.org/jira/browse/CASSANDRA-2871 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 0.8.0 Reporter: Wojciech Meler Priority: Trivial Cfstats should be more grep-friendly - data should be presented in table - one keyspace/column family per line. -- 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
buildbot success in ASF Buildbot on cassandra-trunk
The Buildbot has detected a restored build on builder cassandra-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/cassandra-trunk/builds/1724 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: isis_ubuntu Build Reason: scheduler Build Source Stamp: [branch cassandra/trunk] 1183135 Blamelist: eevans Build succeeded! sincerely, -The Buildbot
[jira] [Resolved] (CASSANDRA-3016) CQL: double and float types do not seem to work properly
[
https://issues.apache.org/jira/browse/CASSANDRA-3016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
paul cannon resolved CASSANDRA-3016.
Resolution: Invalid
http://code.google.com/a/apache-extras.org/p/cassandra-dbapi2/issues/detail?id=8
submitted. Closing this one.
CQL: double and float types do not seem to work properly
Key: CASSANDRA-3016
URL: https://issues.apache.org/jira/browse/CASSANDRA-3016
Project: Cassandra
Issue Type: Bug
Reporter: Matt Hollingsworth
Assignee: paul cannon
Was asked to make this from the mailing list by Jonathan Ellis.
I'm just getting started with CQL, and decided to do a simple test
create/insert/select thing to check that everything was working. Most
everything seems to work, but it appears that double/floats do not work
properly. Here's what I did:
test.cql
--
CREATE KEYSPACE test with strategy_class = 'SimpleStrategy' and
strategy_options:replication_factor=1;
USE test;
CREATE COLUMNFAMILY testvals (
key varchar PRIMARY KEY,
value float
);
INSERT INTO testvals (key,value) VALUES ('k1',341.32355);
SELECT key, value FROM testvals;
--
The output is this:
cqlsh localhost scripts/test.cql
key |value |
k1 | @uU-B??? |
Same thing happens when I do value double. I also tried to do this from the
python driver, gives the same weirdness:
In [2]: import cql
In [3]: con = cql.connect(localhost,keyspace=test)
In [4]: cursor = con.cursor()
In [5]: cursor.execute(SELECT * from testvals)
Out[5]: True
In [6]: for r in cursor: print r
...:
[u'k1', '?\xf8\x00\x00\x00\x00\x00\x00']
--
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-2866) Add higher nofile (ulimit -n) property to the install configuration for debian and rpm packaging
[ https://issues.apache.org/jira/browse/CASSANDRA-2866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-2866. --- Resolution: Duplicate done in CASSANDRA-3206 Add higher nofile (ulimit -n) property to the install configuration for debian and rpm packaging Key: CASSANDRA-2866 URL: https://issues.apache.org/jira/browse/CASSANDRA-2866 Project: Cassandra Issue Type: Improvement Components: Packaging Reporter: Jeremy Hanna Priority: Minor Labels: lhf Currently in the packaging we set the memlock to unlimited. We should also up the nofile value (ulimit -n) so that it's more than 1024, likely unlimited. Otherwise, there can be odd indirect bugs. For example, I've seen compaction fail because of the too many open files error. -- 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-2854) Java Build Path is broken in Eclipse after running generate-eclipse-files Ant target
[ https://issues.apache.org/jira/browse/CASSANDRA-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13127026#comment-13127026 ] Jonathan Ellis commented on CASSANDRA-2854: --- David, can you submit a patch to address the : problem? Java Build Path is broken in Eclipse after running generate-eclipse-files Ant target Key: CASSANDRA-2854 URL: https://issues.apache.org/jira/browse/CASSANDRA-2854 Project: Cassandra Issue Type: Bug Components: Packaging Affects Versions: 0.8.1 Environment: Windows 7 64-bit, Eclipse Helios SR1, Subclipse Reporter: David Allsopp Priority: Minor Following the instructions in http://wiki.apache.org/cassandra/RunningCassandraInEclipse, but checking out v0.8.1: After running the 'generate-eclipse-files' Ant target, the build path is set up to include all the libraries in build/lib/jars, but each library has ;C (semicolon, letter C) appended to it, so Eclipse can't find the libraries - there are about 55 errors like: Project 'cassandra-0.8.1' is missing required library: '\Users\David\eclipse_workspace\cassandra-0.8.1\build\lib\jars\commons-cli-1.2.jar;C' -- 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] [Reopened] (CASSANDRA-3331) Apache Daemon missing from the binary tarball
[ https://issues.apache.org/jira/browse/CASSANDRA-3331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Evans reopened CASSANDRA-3331: --- I'd like to respectfully suggest that we _don't_ do this. I know that we're aiming to run out-of-the-box wherever possible, but there has to be a line between software we supply, and what is expected to already be there. I think this crosses that line, in the same way that jsvc (for unix hosts), or even the JVM itself, would. Apache Daemon missing from the binary tarball - Key: CASSANDRA-3331 URL: https://issues.apache.org/jira/browse/CASSANDRA-3331 Project: Cassandra Issue Type: Bug Affects Versions: 1.0.0 Reporter: Benjamin Coverston Assignee: Benjamin Coverston Fix For: 1.0.0 Attachments: 0001-add-files-to-src-and-bin-add-uninstall.patch, 0002-adding-daemon-directory.patch Apparently the tools used to run the binary release are missing from the binary tarball. I will verify that they are in the 1.0 branch, then update the ticket so we can ensure that they are included. Ben -- 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] [Resolved] (CASSANDRA-2700) Row cache provider options
[ https://issues.apache.org/jira/browse/CASSANDRA-2700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-2700. --- Resolution: Incomplete Assignee: (was: Chris Goffinet) Unsure what this had in mind other than the referenced tickets above. Row cache provider options -- Key: CASSANDRA-2700 URL: https://issues.apache.org/jira/browse/CASSANDRA-2700 Project: Cassandra Issue Type: Improvement Reporter: Chris Goffinet Priority: Minor -- 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-2634) .NET driver for CQL
[ https://issues.apache.org/jira/browse/CASSANDRA-2634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-2634. --- Resolution: Invalid We're moving CQL drivers to apache-extra now. (http://code.google.com/a/apache-extras.org/hosting/) .NET driver for CQL --- Key: CASSANDRA-2634 URL: https://issues.apache.org/jira/browse/CASSANDRA-2634 Project: Cassandra Issue Type: Sub-task Components: API Affects Versions: 0.8 beta 1 Reporter: Michal Augustýn Priority: Minor The goal is to create ADO.NET driver for Cassandra, using CQL. So we have to implement [IDbConnection|http://msdn.microsoft.com/en-us/library/system.data.idbconnection.aspx] interface and all related interfaces (i.e. [IDbCommand|http://msdn.microsoft.com/en-us/library/system.data.idbcommand.aspx]). We must ensure that the connection is pooled. The implementation will be probably similar to CASSANDRA-1710. -- 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-3302) stop Cassandra result in hang
[ https://issues.apache.org/jira/browse/CASSANDRA-3302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13127041#comment-13127041 ] Jackson Chung commented on CASSANDRA-3302: -- smoke test quickly repeating the same step except swaps with 1.0.0 jars cannot reproduce the problem stop Cassandra result in hang - Key: CASSANDRA-3302 URL: https://issues.apache.org/jira/browse/CASSANDRA-3302 Project: Cassandra Issue Type: Bug Affects Versions: 1.0.1 Reporter: Jackson Chung Assignee: T Jake Luciani testing this under trunk via a hacked package (replacing jars from 0.8.6 deb installation) When calling service cassandra stop, the Cassandra process hang: http://aep.appspot.com/display/i6aIUCkt4kz0HG5l2VszMM7QvLo/ The following logs is observed in the C* log: INFO [main] 2011-10-03 23:20:46,434 AbstractCassandraDaemon.java (line 270) Cassandra shutting down... INFO [main] 2011-10-03 23:20:46,434 CassandraDaemon.java (line 218) Stop listening to thrift clients Re-run this using 1.0.0 branch, (following the same hack procedure), C* stop properly, and the following is observed in the log: INFO [main] 2011-10-04 05:02:08,048 AbstractCassandraDaemon.java (line 270) Cassandra shutting down... INFO [main] 2011-10-04 05:02:08,049 CassandraDaemon.java (line 218) Stop listening to thrift clients INFO [Thread-2] 2011-10-04 05:02:08,318 MessagingService.java (line 482) Shutting down MessageService... INFO [Thread-2] 2011-10-04 05:02:08,319 MessagingService.java (line 497) Waiting for in-progress requests to complete INFO [ACCEPT-/10.83.77.171] 2011-10-04 05:02:08,319 MessagingService.java (line 637) MessagingService shutting down server thread. could this be related to CASSANDRA-3261 ? -- 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] [Resolved] (CASSANDRA-3321) Node joins/Node moves should build caches
[ https://issues.apache.org/jira/browse/CASSANDRA-3321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-3321. --- Resolution: Duplicate duplicate of CASSANDRA-2443 Node joins/Node moves should build caches -- Key: CASSANDRA-3321 URL: https://issues.apache.org/jira/browse/CASSANDRA-3321 Project: Cassandra Issue Type: New Feature Reporter: Edward Capriolo Priority: Minor Cassandra use case: high rate of low latency reads served mostly from caches. When a new node is joined data is streamed to it. However it is born into a 'cold world'. It does not have the benefit of saved caches. Clients with auto-discovery will find it and start sending requests it's way. If the request rate is high enough and clients are aggressive enough the Cassandra node could run out of sockets. This feature would build 'best effort' caches possibly by sampling entries from the caches of nodes the data was streamed from. With this even a newly joined node should have cache warming. -- 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-3331) Apache Daemon missing from the binary tarball
[ https://issues.apache.org/jira/browse/CASSANDRA-3331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13127057#comment-13127057 ] Jonathan Ellis commented on CASSANDRA-3331: --- I'm fine with reverting this. (IIRC though there were some quoting fixes to the .bat file, as well as the UNINSTALL option, so it should be a little more surgical than just doing a svn reverse-merge.) Apache Daemon missing from the binary tarball - Key: CASSANDRA-3331 URL: https://issues.apache.org/jira/browse/CASSANDRA-3331 Project: Cassandra Issue Type: Bug Affects Versions: 1.0.0 Reporter: Benjamin Coverston Assignee: Benjamin Coverston Fix For: 1.0.0 Attachments: 0001-add-files-to-src-and-bin-add-uninstall.patch, 0002-adding-daemon-directory.patch Apparently the tools used to run the binary release are missing from the binary tarball. I will verify that they are in the 1.0 branch, then update the ticket so we can ensure that they are included. Ben -- 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-2470) Secondary Indexes Build Very Slowly
[ https://issues.apache.org/jira/browse/CASSANDRA-2470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13127061#comment-13127061 ] Jonathan Ellis commented on CASSANDRA-2470: --- ... Now that 2324 and 2498 are both done, how does index build look? Secondary Indexes Build Very Slowly --- Key: CASSANDRA-2470 URL: https://issues.apache.org/jira/browse/CASSANDRA-2470 Project: Cassandra Issue Type: Improvement Reporter: Benjamin Coverston Labels: repair, secondary_index While running repair I noticed that the time it took to run was easily dominated by building the secondary indexes. They currently build at a rate of 200KB/Second. This means that indexing a 500MB file takes nearly an hour to index the file. Because this happens on the compaction thread it also causes repair to back up in general, which for very active systems is a very bad thing. I suggest we look at it in the hope that we can improve the rate in which we build the indexes by an order of magnitude. -- 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-2466) bloom filters should avoid huge array allocations to avoid fragmentation concerns
[ https://issues.apache.org/jira/browse/CASSANDRA-2466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13127065#comment-13127065 ] Jonathan Ellis commented on CASSANDRA-2466: --- The main problem with moving BF off-heap is that single-item gets from direct buffers are about 1/2 the speed of accessing an on-heap byte[]. That's a pretty big hit to take. bloom filters should avoid huge array allocations to avoid fragmentation concerns - Key: CASSANDRA-2466 URL: https://issues.apache.org/jira/browse/CASSANDRA-2466 Project: Cassandra Issue Type: Bug Reporter: Peter Schuller Priority: Minor The fact that bloom filters are backed by single large arrays of longs is expected to interact badly with promotion of objects into old gen with CMS, due to fragmentation concerns (as discussed in CASSANDRA-2463). It should be less of an issue than CASSANDRA-2463 in the sense that you need to have a lot of rows before the array sizes become truly huge. For comparison, the ~ 143 million row key limit implied by the use of 'int' in BitSet prior to the switch to OpenBitSet translates roughly to 238 MB (assuming the limitation factor there was the addressability of the bits with a 32 bit int, which is my understanding). Having a preliminary look at OpenBitSet with an eye towards replacing the single long[] with multiple arrays, it seems that if we're willing to drop some of the functionality that is not used for bloom filter purposes, the bits[i] indexing should be pretty easy to augment with modulo to address an appropriate smaller array. Locality is not an issue since the bloom filter case is the worst possible case for locality anyway, and it doesn't matter whether it's one huge array or a number of ~ 64k arrays. Callers may be affected like BloomFilterSerializer which cares about the underlying bit array. If the full functionality of OpenBitSet is to be maintained (e.g., xorCount) some additional acrobatics would be necessary and presumably at a noticable performance cost if such operations were to be used in performance critical places. An argument against touching OpenBitSet is that it seems to be pretty carefully written and tested and has some non-trivial details and people have seemingly benchmarked it quite carefully. On the other hand, the improvement would then apply to other things as well, such as the bitsets used to keep track of in-core pages (off the cuff for scale, a 64 gig sstable should imply a 2 mb bit set, with one bit per 4k page). -- 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-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:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-2407:
--
Component/s: Core
Fix Version/s: 1.0.1
Assignee: Pavel Yaskevich
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: Pavel Yaskevich
Priority: Minor
Labels: compaction
Fix For: 1.0.1
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] [Updated] (CASSANDRA-2392) Saving IndexSummaries to disk
[ https://issues.apache.org/jira/browse/CASSANDRA-2392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2392: -- Affects Version/s: (was: 0.8 beta 1) Fix Version/s: 1.1 Assignee: Pavel Yaskevich Saving IndexSummaries to disk - Key: CASSANDRA-2392 URL: https://issues.apache.org/jira/browse/CASSANDRA-2392 Project: Cassandra Issue Type: Improvement Reporter: Chris Goffinet Assignee: Pavel Yaskevich Priority: Minor Fix For: 1.1 For nodes with millions of keys, doing rolling restarts that take over 10 minutes per node can be painful if you have 100 node cluster. All of our time is spent on doing index summary computations on startup. It would be great if we could save those to disk as well. Our indexes are quite large. -- 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-2443) Stream key/row caches during bootstrap
[ https://issues.apache.org/jira/browse/CASSANDRA-2443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13127073#comment-13127073 ] Jonathan Ellis commented on CASSANDRA-2443: --- Doesn't dynamic snitch solve this problem? Stream key/row caches during bootstrap -- Key: CASSANDRA-2443 URL: https://issues.apache.org/jira/browse/CASSANDRA-2443 Project: Cassandra Issue Type: Improvement Reporter: Chris Goffinet Priority: Minor Labels: ponies When adding new nodes to an existing cluster, if we streamed key and row caches over right before node came into cluster, we could minimize the impact of a cold node, and reduce the time for the node to get 'warmed' up. -- 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-2348) Allow periods in secondary index column names
[
https://issues.apache.org/jira/browse/CASSANDRA-2348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13127074#comment-13127074
]
Jonathan Ellis commented on CASSANDRA-2348:
---
why not just use food_fruit_a?
Allow periods in secondary index column names
-
Key: CASSANDRA-2348
URL: https://issues.apache.org/jira/browse/CASSANDRA-2348
Project: Cassandra
Issue Type: Wish
Components: API
Reporter: David Semeria
Priority: Minor
Labels: index, json
Premise: it is natural to map JSON objects to column names using periods to
denote the object hierarchy.
For example {food:{fruit;{a:apples,b:bananas,c:cherries}}}
Would map to the following CF names: food.fruit.a, food.fruit.b, food.fruit.c
However, secondary index names cannot contain periods which means workarounds
(ie denormalization) must be used to index such columns.
It would be nice if this restriction could be removed.
--
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-2357) Load spikes on coordinators since upgrade from 0.6.8 to 0.7
[ https://issues.apache.org/jira/browse/CASSANDRA-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-2357. - Resolution: Not A Problem Load spikes on coordinators since upgrade from 0.6.8 to 0.7 --- Key: CASSANDRA-2357 URL: https://issues.apache.org/jira/browse/CASSANDRA-2357 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.4 Reporter: Jason Harvey Attachments: thread_dump.txt Since our move from 0.6.8 to 0.7, all of the nodes which speak with clients have been having periodic, abrupt load spikes going into the hundreds. We have been seeing these load spikes 1 to 2 times per hour on every node which clients are speaking with. The load graph for a typical spike: http://i.imgur.com/jY8AV.png I have verified that client connections are not spiking at the same time via TCP statistics. I have also verified that we aren't seeing any spikes in reads/mutations/etc. We were using the DynamicSnitch, but I turned that off as a troubleshooting step. The issue was unchanged. When the spikes occur, the box's responsiveness slows to a crawl so I am unable to do much in terms of real-time diagnostics. I was able to get a thread dump a few seconds after a spike, which I have attached to this ticket. Not sure if it will show anything since I couldn't capture it immediately during the spike. I should note that David King noticed a similar problem (#2058) when he tried moving us from 0.6.8 to 0.6.10. The main issue at the time was a long-lasting load spike, but he also saw occasional abrupt load spikes like we are seeing now. When we moved back to 0.6.8, we didn't see the problem again, until the move to 0.7. I realize this information is somewhat nebulous. If there is any further info I can provide, please let me know. The spikes are causing quite a bit of instability, so we are considering retreating back to 0.6.8. I'd like to investigate every possible solution before we resort to 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] [Resolved] (CASSANDRA-2275) Allow the configuration of Cassandra to be imported into the database so that it can be updated and acted upon dynamically
[ https://issues.apache.org/jira/browse/CASSANDRA-2275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-2275. --- Resolution: Won't Fix It sounds like you specifically care about the auth settings. See the discussion over on CASSANDRA-3319 -- I'm fine with an auth provider that stores its data natively in Cassandra. If you want to work on that, feel free to open a ticket for it. Allow the configuration of Cassandra to be imported into the database so that it can be updated and acted upon dynamically -- Key: CASSANDRA-2275 URL: https://issues.apache.org/jira/browse/CASSANDRA-2275 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.2 Reporter: Andrew Schiefelbein OpenLDAP has a nice feature that allows you to create the operational parameters of the LDAP to be in a configuration LDAP so that you can update it on the fly (ie set debug levels, etc etc). It would be a nice feature if you could incorporate at least the passwd.properties and access.properties as well some of the cassandra.yaml into the database so you can manipulate them in real time by a properly authenticated and authorized user. -- 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
