[jira] [Commented] (CASSANDRA-4242) Name of parameters should be available in CqlPreparedResult
[
https://issues.apache.org/jira/browse/CASSANDRA-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13276521#comment-13276521
]
Pierre Chalamet commented on CASSANDRA-4242:
bq. Well, yes, it's definitely designed around data sources that give you
ordered values instead. This fits at the least JDBC, Python DBAPI, and Ruby
DBI. What are you using that can't work with this paradigm?
There are basically 2 use cases:
* micro-orm like (mapping object to and from a query)
* feeding from external data source (like a rowset which usually support
ordered and named columns).
Version in trunk of cassandra-sharp (my cassandra .net client) support actually
a micro-orm interface (with this patch) - it is still under development but
this will probably looks like this:
{code}
[Schema(TestKeyspace, Comment = People table, Name=People)]
public class PeopleSchema
{
[Index(Name = birthyear)]
public int Birthyear;
[Key(Name = firstname)]
public string FirstName;
[Column(Name = lastname)]
public string LastName;
}
cluster.CreatePeopleSchema();
cluster.Execute(insert into People (firstname, lastname, birthyear) values (?,
?, ?),
new {firstname = pierre, lastname = chalamet, birthyear =
1973});
{code}
I do not want this framework to be user driven (ie: the user provides the
parameters and knows the nitty gritty details of his query) - instead I want
this framework to be query driven for parameters feeding (ie: the query
determines what is necessary to complete the execution). This way, the user can
change its query without changing the parameters order - it is still the plain
old .net object exposing unordered properties. You can refactor as you want the
query or the .net object, it should still work.
The other interface I'd like to setup in the micro-orm area is something like
the on in Gigaspaces (query template with plain old object) - the interface is
really good for getting results. For extended queries, it is also required to
be able to map parameters.
The second use case is less obvious, but suppose I need to transfer data
between a database and C*.
I would select on one side and insert on the other side - using something like
a data reader in .net.
For that, I still do not want to rely on order of the column in the rowset - I
would prefer to discover the structure and bind parameters accordingly using a
the data reader metadata (basically column names).
I do believe it is good functionality client side. This will allow more way to
interact with C* in safer way without much cost anyway.
Compared to the cost of the i/o, retrieving the column names in
CqlPreparedResult and mapping client side is really cheap.
I've also read CASSANDRA-2474 - quite interesting thanks for the link. But I
really would prefer to have binary in column name instead of string. That's why
in the new patch I did not changed this. I'm not really clear on this, I had to
think more about it, but as is, I have the feeling that C* is moving away from
sliced query on binary column names (a strong feature in my opinion). It might
does stand when considering hadoop, hive and co... I might be the only guy
using C* alone anyway.
Moreover, CqlMetadata exposes column names as binary - I would also prefer
something symmetrical (weak argument anyway).
Name of parameters should be available in CqlPreparedResult
---
Key: CASSANDRA-4242
URL: https://issues.apache.org/jira/browse/CASSANDRA-4242
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.0
Reporter: Pierre Chalamet
Priority: Minor
Attachments: 4242.txt, 4242_2.txt
Client side, it could be nice to have the name of parameters in
CqlPreparedResult. This could allow parameters mapping by name instead of by
index.
{code}
struct CqlNameType {
1: required binary key,
2: required string type
}
struct CqlPreparedResult {
1: required i32 itemId,
2: required i32 count,
3: optional liststring variable_types,
4: optional listCqlNameType name_types
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4242) Name of parameters should be available in CqlPreparedResult
[
https://issues.apache.org/jira/browse/CASSANDRA-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Chalamet updated CASSANDRA-4242:
---
Attachment: 4242_3.txt
ensure compatibility with cql 3 client.
Name of parameters should be available in CqlPreparedResult
---
Key: CASSANDRA-4242
URL: https://issues.apache.org/jira/browse/CASSANDRA-4242
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.0
Reporter: Pierre Chalamet
Priority: Minor
Attachments: 4242.txt, 4242_2.txt, 4242_3.txt
Client side, it could be nice to have the name of parameters in
CqlPreparedResult. This could allow parameters mapping by name instead of by
index.
{code}
struct CqlNameType {
1: required binary key,
2: required string type
}
struct CqlPreparedResult {
1: required i32 itemId,
2: required i32 count,
3: optional liststring variable_types,
4: optional listCqlNameType name_types
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4242) Name of parameters should be available in CqlPreparedResult
[
https://issues.apache.org/jira/browse/CASSANDRA-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13276563#comment-13276563
]
Sylvain Lebresne commented on CASSANDRA-4242:
-
I can see the point of returning the names in the CqlPreparedResult. However,
despite Jonathan's suggestion, I actually prefered the original one (except for
the binary-string), i.e.:
{noformat}
struct CqlPreparedResult {
1: required i32 itemId,
2: required i32 count,
3: optional liststring variable_types
+4: optional liststring variable_names
}
{noformat}
The reason is mainly that I don't see the point in breaking CQL3 clients. I
agree CqlMetadata is overkill for CQL3, but imo CASSANDRA-2478 is where we
should bother fixing this.
Also, the variable_types in CqlPreparedResult is actually not a CQL2 thing, but
a CQL3 thing exclusively, so deprecating it in say 1.1.1 when it was introduced
in 1.1.0 feels again a bit harsh on the client writers for no good reasons.
bq. I have the feeling that C* is moving away from sliced query on binary
column names (a strong feature in my opinion)
It does not. The difference is that a column name *in CQL3* does not
necessarily map to a internal column name. So CQL3 column names *are* strings
and this without any loss of generality.
bq. Moreover, CqlMetadata exposes column names as binary
Yes, but that part is due to the difference between CQL2 and CQL3. Concretely,
CQL3 will *never* return anything else than UTF8 bytes (which is why Jonathan
suggested replacing CqlMetadata by a mapstring, string for CQL3, but see my
argument above). In any case, given that the variable names will be CQL3 only
(we cannot, even if we wanted to, do it in CQL2), I don't think there is a
point in returning binary.
Name of parameters should be available in CqlPreparedResult
---
Key: CASSANDRA-4242
URL: https://issues.apache.org/jira/browse/CASSANDRA-4242
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.0
Reporter: Pierre Chalamet
Priority: Minor
Attachments: 4242.txt, 4242_2.txt, 4242_3.txt
Client side, it could be nice to have the name of parameters in
CqlPreparedResult. This could allow parameters mapping by name instead of by
index.
{code}
struct CqlNameType {
1: required binary key,
2: required string type
}
struct CqlPreparedResult {
1: required i32 itemId,
2: required i32 count,
3: optional liststring variable_types,
4: optional listCqlNameType name_types
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4249) LOGGING: Info log is not displaying number of rows read from saved cache at startup
sankalp kohli created CASSANDRA-4249: Summary: LOGGING: Info log is not displaying number of rows read from saved cache at startup Key: CASSANDRA-4249 URL: https://issues.apache.org/jira/browse/CASSANDRA-4249 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.0 Reporter: sankalp kohli Priority: Trivial Fix For: 1.2 As part of commit with revision c9270f4e info logging for number of rows read from saved cache is not working. This is happening because we are not incrementing the counter cachedRowsRead in ColumnFamilyStore.initRowCache(). -- 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-3779) need forked language document
[
https://issues.apache.org/jira/browse/CASSANDRA-3779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13276597#comment-13276597
]
Sylvain Lebresne commented on CASSANDRA-3779:
-
Any news on the review of this? I think it would be nice to get the doc out
quickly (even if it's not perfect).
need forked language document
-
Key: CASSANDRA-3779
URL: https://issues.apache.org/jira/browse/CASSANDRA-3779
Project: Cassandra
Issue Type: Sub-task
Components: API
Affects Versions: 1.1.0
Reporter: Eric Evans
Assignee: Sylvain Lebresne
Labels: cql
Fix For: 1.1.1
The language doc ({{doc/cql/CQL.textile}}) needs to be forked for CQLv3 and
updated accordingly.
--
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-4249) LOGGING: Info log is not displaying number of rows read from saved cache at startup
[ https://issues.apache.org/jira/browse/CASSANDRA-4249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sankalp kohli updated CASSANDRA-4249: - Attachment: trunk-4249.txt LOGGING: Info log is not displaying number of rows read from saved cache at startup --- Key: CASSANDRA-4249 URL: https://issues.apache.org/jira/browse/CASSANDRA-4249 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.0 Reporter: sankalp kohli Priority: Trivial Fix For: 1.2 Attachments: trunk-4249.txt Original Estimate: 0.1h Remaining Estimate: 0.1h As part of commit with revision c9270f4e info logging for number of rows read from saved cache is not working. This is happening because we are not incrementing the counter cachedRowsRead in ColumnFamilyStore.initRowCache(). -- 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-4250) Missing arrayOffset in FBUtilities.hash
Richard Low created CASSANDRA-4250: -- Summary: Missing arrayOffset in FBUtilities.hash Key: CASSANDRA-4250 URL: https://issues.apache.org/jira/browse/CASSANDRA-4250 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.0 Reporter: Richard Low Assignee: Richard Low Priority: Critical In CASSANDRA-3869, FBUtilities.hash was optimised to use the backing byte array if there is one. However, there is a missing +arrayOffset in the offset parameter. This can cause incorrect hashes resulting in data going to the wrong place, etc.. I haven't observed any errors directly attributable to this so maybe we are lucky and all backing arrays start at 0 but this could cause data loss in the worst case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4250) Missing arrayOffset in FBUtilities.hash
[ https://issues.apache.org/jira/browse/CASSANDRA-4250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Low updated CASSANDRA-4250: --- Attachment: CASSANDRA-4250-v1.patch Patch against 1.1.0 Missing arrayOffset in FBUtilities.hash --- Key: CASSANDRA-4250 URL: https://issues.apache.org/jira/browse/CASSANDRA-4250 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.0 Reporter: Richard Low Assignee: Richard Low Priority: Critical Fix For: 1.0.11 Attachments: CASSANDRA-4250-v1.patch In CASSANDRA-3869, FBUtilities.hash was optimised to use the backing byte array if there is one. However, there is a missing +arrayOffset in the offset parameter. This can cause incorrect hashes resulting in data going to the wrong place, etc.. I haven't observed any errors directly attributable to this so maybe we are lucky and all backing arrays start at 0 but this could cause data loss in the worst case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
git commit: Fix missing arrayOffset in FBUtilities.hash
Updated Branches:
refs/heads/cassandra-1.1 59a042167 - 1e8685d83
Fix missing arrayOffset in FBUtilities.hash
patch by Richard Low; reviewed by slebresne for CASSANDRA-4250
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/1e8685d8
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/1e8685d8
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/1e8685d8
Branch: refs/heads/cassandra-1.1
Commit: 1e8685d836fee9f65f976d4587da88bda3dbeca2
Parents: 59a0421
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Wed May 16 11:55:12 2012 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Wed May 16 11:55:12 2012 +0200
--
CHANGES.txt|1 +
.../org/apache/cassandra/utils/FBUtilities.java|2 +-
2 files changed, 2 insertions(+), 1 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/1e8685d8/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 211314f..4f1046b 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -45,6 +45,7 @@
* (cql3) Don't return range ghosts anymore (CASSANDRA-3982)
* fix the problem re-creating Keyspace/ColumnFamily (CASSANDRA-4219)
* fix SecondaryIndex LelevedManifest save upon snapshot (CASSANDRA-4230)
+ * fix missing arrayOffset in FBUtilities.hash (CASSANDRA-4250)
Merged from 1.0:
* Fix super columns bug where cache is not updated (CASSANDRA-4190)
* fix maxTimestamp to include row tombstones (CASSANDRA-4116)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/1e8685d8/src/java/org/apache/cassandra/utils/FBUtilities.java
--
diff --git a/src/java/org/apache/cassandra/utils/FBUtilities.java
b/src/java/org/apache/cassandra/utils/FBUtilities.java
index c0fe9bd..fb2adfe 100644
--- a/src/java/org/apache/cassandra/utils/FBUtilities.java
+++ b/src/java/org/apache/cassandra/utils/FBUtilities.java
@@ -221,7 +221,7 @@ public class FBUtilities
for (ByteBuffer block : data)
{
if (block.hasArray())
-messageDigest.update(block.array(), block.position(),
block.remaining());
+messageDigest.update(block.array(), block.arrayOffset() +
block.position(), block.remaining());
else
messageDigest.update(block.duplicate());
}
[jira] [Commented] (CASSANDRA-3881) reduce computational complexity of processing topology changes
[
https://issues.apache.org/jira/browse/CASSANDRA-3881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13276660#comment-13276660
]
Sam Overton commented on CASSANDRA-3881:
AbstractEndpointSnitch should handle every state change, not just onChange and
onRemove
[incremental
patch|https://github.com/acunu/cassandra/commit/c6d68ab925ef224f5d7bd84cc707932b40e1f2ea]
([raw
diff|https://github.com/acunu/cassandra/commit/c6d68ab925ef224f5d7bd84cc707932b40e1f2ea.diff])
reduce computational complexity of processing topology changes
--
Key: CASSANDRA-3881
URL: https://issues.apache.org/jira/browse/CASSANDRA-3881
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Peter Schuller
Assignee: Sam Overton
Labels: vnodes
This constitutes follow-up work from CASSANDRA-3831 where a partial
improvement was committed, but the fundamental issue was not fixed. The
maximum practical cluster size was significantly improved, but further work
is expected to be necessary as cluster sizes grow.
_Edit0: Appended patch information._
h3. Patches
||Compare||Raw diff||Description||
|[00_snitch_topology|https://github.com/acunu/cassandra/compare/refs/top-bases/p/3881/00_snitch_topology...p/3881/00_snitch_topology]|[00_snitch_topology.patch|https://github.com/acunu/cassandra/compare/refs/top-bases/p/3881/00_snitch_topology...p/3881/00_snitch_topology.diff]|Adds
some functionality to AbstractEndpointSnitch to track which endpoints and
racks exist in a DC.|
|[01_calc_natural_endpoints|https://github.com/acunu/cassandra/compare/refs/top-bases/p/3881/01_calc_natural_endpoints...p/3881/01_calc_natural_endpoints]|[01_calc_natural_endpoints.patch|https://github.com/acunu/cassandra/compare/refs/top-bases/p/3881/01_calc_natural_endpoints...p/3881/01_calc_natural_endpoints.diff]|Rewritten
O(logN) implementation of calculateNaturalEndpoints using the topology
information from the snitch.|
_Note: These are branches managed with TopGit. If you are applying the patch
output manually, you will either need to filter the TopGit metadata files
(i.e. {{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}),
or remove them afterward ({{rm .topmsg .topdeps}})._
--
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] [Comment Edited] (CASSANDRA-3881) reduce computational complexity of processing topology changes
[
https://issues.apache.org/jira/browse/CASSANDRA-3881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13276660#comment-13276660
]
Sam Overton edited comment on CASSANDRA-3881 at 5/16/12 11:07 AM:
--
AbstractEndpointSnitch should handle every state change, not just onChange and
onRemove
[incremental
patch|https://github.com/acunu/cassandra/commit/b462500e7b8edad0581c60b8e2011cf76e1c7a92]
([raw
diff|https://github.com/acunu/cassandra/commit/b462500e7b8edad0581c60b8e2011cf76e1c7a92.diff])
was (Author: soverton):
AbstractEndpointSnitch should handle every state change, not just onChange
and onRemove
[incremental
patch|https://github.com/acunu/cassandra/commit/c6d68ab925ef224f5d7bd84cc707932b40e1f2ea]
([raw
diff|https://github.com/acunu/cassandra/commit/c6d68ab925ef224f5d7bd84cc707932b40e1f2ea.diff])
reduce computational complexity of processing topology changes
--
Key: CASSANDRA-3881
URL: https://issues.apache.org/jira/browse/CASSANDRA-3881
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Peter Schuller
Assignee: Sam Overton
Labels: vnodes
This constitutes follow-up work from CASSANDRA-3831 where a partial
improvement was committed, but the fundamental issue was not fixed. The
maximum practical cluster size was significantly improved, but further work
is expected to be necessary as cluster sizes grow.
_Edit0: Appended patch information._
h3. Patches
||Compare||Raw diff||Description||
|[00_snitch_topology|https://github.com/acunu/cassandra/compare/refs/top-bases/p/3881/00_snitch_topology...p/3881/00_snitch_topology]|[00_snitch_topology.patch|https://github.com/acunu/cassandra/compare/refs/top-bases/p/3881/00_snitch_topology...p/3881/00_snitch_topology.diff]|Adds
some functionality to AbstractEndpointSnitch to track which endpoints and
racks exist in a DC.|
|[01_calc_natural_endpoints|https://github.com/acunu/cassandra/compare/refs/top-bases/p/3881/01_calc_natural_endpoints...p/3881/01_calc_natural_endpoints]|[01_calc_natural_endpoints.patch|https://github.com/acunu/cassandra/compare/refs/top-bases/p/3881/01_calc_natural_endpoints...p/3881/01_calc_natural_endpoints.diff]|Rewritten
O(logN) implementation of calculateNaturalEndpoints using the topology
information from the snitch.|
_Note: These are branches managed with TopGit. If you are applying the patch
output manually, you will either need to filter the TopGit metadata files
(i.e. {{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}),
or remove them afterward ({{rm .topmsg .topdeps}})._
--
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-3881) reduce computational complexity of processing topology changes
[
https://issues.apache.org/jira/browse/CASSANDRA-3881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13276678#comment-13276678
]
Sam Overton commented on CASSANDRA-3881:
Some remaining issues:
1. Handling changes to dc/rack assignment. Currently the topology maps would
get out of sync if any endpoint changes dc/rack. This will require Ec2Snitch
and PropertyFileSnitch to notify the superclass when they detect a topology
change.
2. Delegate getTopology in DynamicSnitch to the subsnitch.
reduce computational complexity of processing topology changes
--
Key: CASSANDRA-3881
URL: https://issues.apache.org/jira/browse/CASSANDRA-3881
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Peter Schuller
Assignee: Sam Overton
Labels: vnodes
This constitutes follow-up work from CASSANDRA-3831 where a partial
improvement was committed, but the fundamental issue was not fixed. The
maximum practical cluster size was significantly improved, but further work
is expected to be necessary as cluster sizes grow.
_Edit0: Appended patch information._
h3. Patches
||Compare||Raw diff||Description||
|[00_snitch_topology|https://github.com/acunu/cassandra/compare/refs/top-bases/p/3881/00_snitch_topology...p/3881/00_snitch_topology]|[00_snitch_topology.patch|https://github.com/acunu/cassandra/compare/refs/top-bases/p/3881/00_snitch_topology...p/3881/00_snitch_topology.diff]|Adds
some functionality to AbstractEndpointSnitch to track which endpoints and
racks exist in a DC.|
|[01_calc_natural_endpoints|https://github.com/acunu/cassandra/compare/refs/top-bases/p/3881/01_calc_natural_endpoints...p/3881/01_calc_natural_endpoints]|[01_calc_natural_endpoints.patch|https://github.com/acunu/cassandra/compare/refs/top-bases/p/3881/01_calc_natural_endpoints...p/3881/01_calc_natural_endpoints.diff]|Rewritten
O(logN) implementation of calculateNaturalEndpoints using the topology
information from the snitch.|
_Note: These are branches managed with TopGit. If you are applying the patch
output manually, you will either need to filter the TopGit metadata files
(i.e. {{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}),
or remove them afterward ({{rm .topmsg .topdeps}})._
--
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-4251) when loading schema make sure the key and value are not present in the cfIdMap (BiDiMap)
Dave Brosius created CASSANDRA-4251: --- Summary: when loading schema make sure the key and value are not present in the cfIdMap (BiDiMap) Key: CASSANDRA-4251 URL: https://issues.apache.org/jira/browse/CASSANDRA-4251 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.2 Reporter: Dave Brosius Priority: Trivial google bidimap throws an uncaught runtime exception with less than informative information when the cfid already exists in the cfIDMap has it as a value. Add a check to the preflight check of the Schema class instead, so there is better messaging. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4251) when loading schema make sure the key and value are not present in the cfIdMap (BiDiMap)
[ https://issues.apache.org/jira/browse/CASSANDRA-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Brosius updated CASSANDRA-4251: Attachment: better_schema_load_exs.diff java.lang.IllegalArgumentException: value already present: 1034 at com.google.common.base.Preconditions.checkArgument(Preconditions.java:115) at com.google.common.collect.AbstractBiMap.putInBothMaps(AbstractBiMap.java:111) at com.google.common.collect.AbstractBiMap.put(AbstractBiMap.java:96) at com.google.common.collect.HashBiMap.put(HashBiMap.java:84) at org.apache.cassandra.config.Schema.load(Schema.java:385) at org.apache.cassandra.config.Schema.load(Schema.java:106) at org.apache.cassandra.config.Schema.load(Schema.java:91) when loading schema make sure the key and value are not present in the cfIdMap (BiDiMap) Key: CASSANDRA-4251 URL: https://issues.apache.org/jira/browse/CASSANDRA-4251 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.2 Reporter: Dave Brosius Priority: Trivial Attachments: better_schema_load_exs.diff google bidimap throws an uncaught runtime exception with less than informative information when the cfid already exists in the cfIDMap has it as a value. Add a check to the preflight check of the Schema class instead, so there is better messaging. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4251) when loading schema make sure the key and value are not present in the cfIdMap (BiDiMap)
[ https://issues.apache.org/jira/browse/CASSANDRA-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Brosius updated CASSANDRA-4251: Attachment: (was: better_schema_load_exs.diff) when loading schema make sure the key and value are not present in the cfIdMap (BiDiMap) Key: CASSANDRA-4251 URL: https://issues.apache.org/jira/browse/CASSANDRA-4251 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.2 Reporter: Dave Brosius Priority: Trivial Attachments: better_schema_load_exs.diff google bidimap throws an uncaught runtime exception with less than informative information when the cfid already exists in the cfIDMap has it as a value. Add a check to the preflight check of the Schema class instead, so there is better messaging. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4251) when loading schema make sure the key and value are not present in the cfIdMap (BiDiMap)
[ https://issues.apache.org/jira/browse/CASSANDRA-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Brosius updated CASSANDRA-4251: Attachment: better_schema_load_exs.diff when loading schema make sure the key and value are not present in the cfIdMap (BiDiMap) Key: CASSANDRA-4251 URL: https://issues.apache.org/jira/browse/CASSANDRA-4251 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.2 Reporter: Dave Brosius Priority: Trivial Attachments: better_schema_load_exs.diff google bidimap throws an uncaught runtime exception with less than informative information when the cfid already exists in the cfIDMap has it as a value. Add a check to the preflight check of the Schema class instead, so there is better messaging. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4242) Name of parameters should be available in CqlPreparedResult
[
https://issues.apache.org/jira/browse/CASSANDRA-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13276799#comment-13276799
]
Jonathan Ellis commented on CASSANDRA-4242:
---
bq. I don't see the point in breaking CQL3 clients
fair enough.
Name of parameters should be available in CqlPreparedResult
---
Key: CASSANDRA-4242
URL: https://issues.apache.org/jira/browse/CASSANDRA-4242
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.0
Reporter: Pierre Chalamet
Priority: Minor
Attachments: 4242.txt, 4242_2.txt, 4242_3.txt
Client side, it could be nice to have the name of parameters in
CqlPreparedResult. This could allow parameters mapping by name instead of by
index.
{code}
struct CqlNameType {
1: required binary key,
2: required string type
}
struct CqlPreparedResult {
1: required i32 itemId,
2: required i32 count,
3: optional liststring variable_types,
4: optional listCqlNameType name_types
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3794) Change ColumnFamily identifiers to be UUIDs instead of sequential Integers.
[ https://issues.apache.org/jira/browse/CASSANDRA-3794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13276802#comment-13276802 ] Jonathan Ellis commented on CASSANDRA-3794: --- Sounds like we should prototype the just use cfname approach and see how bad the hit is in practice. If we're lucky it will be negligible and we can move on. Change ColumnFamily identifiers to be UUIDs instead of sequential Integers. --- Key: CASSANDRA-3794 URL: https://issues.apache.org/jira/browse/CASSANDRA-3794 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Pavel Yaskevich Assignee: Pavel Yaskevich Fix For: 1.1.1 Change ColumnFamily identifiers to be UUIDs instead of sequential Integers. Would be useful in the situation when nodes simultaneously trying to create ColumnFamilies. -- 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-2478) Custom CQL protocol/transport
[ https://issues.apache.org/jira/browse/CASSANDRA-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne reassigned CASSANDRA-2478: --- Assignee: Sylvain Lebresne Custom CQL protocol/transport - Key: CASSANDRA-2478 URL: https://issues.apache.org/jira/browse/CASSANDRA-2478 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Eric Evans Assignee: Sylvain Lebresne Priority: Minor Labels: cql Attachments: cql_binary_protocol A custom wire protocol would give us the flexibility to optimize for our specific use-cases, and eliminate a troublesome dependency (I'm referring to Thrift, but none of the others would be significantly better). Additionally, RPC is bad fit here, and we'd do better to move in the direction of something that natively supports streaming. I don't think this is as daunting as it might seem initially. Utilizing an existing server framework like Netty, combined with some copy-and-paste of bits from other FLOSS projects would probably get us 80% of the way there. -- 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-2478) Custom CQL protocol/transport
[ https://issues.apache.org/jira/browse/CASSANDRA-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-2478: Attachment: cql_binary_protocol Attaching cql_binary_protocol as a draft for such a custom binary protocol (CQL3 only). The protocol follows more or less Rick's outline above. It is frame based, each frame has a small header indicating amongst other the opcode for the message that defines what the body of said message must contain. A typical communication start by a small handshake/authentication phase, after which queries (and preparation/execution) can be performed. The protocol support a form of 'cursor' api for queries. Given a select query, the client can ask the server to return only a handful of rows first, and then the client can fetch more rows at his own rate using a NEXT message. Outside of the cursor thing, the protocol as described here pretty much expose the same things than the thrift transport (as far as CQL is concerned) but not much more (a small exception is that CASSANDRA-3707 is included). I plan on experimenting next with a few additional features, like allowing clients to register to events like 'a new node joined' and be notified when such event happen, but I'll leave that to follow up tickets. I've push at https://github.com/pcmanus/cassandra/commits/2478 an initial implementation of this protocol (using netty). Almost all of the protocol is implemented except for the NEXT message, but I'll get to that. There is currently mainly 4 patches: * the first one is the bulk of the new server * the second one is a simple client, along with a small debug console (whose code is ugly), that allow to send message to test the server. This does not necessarily have to make it in the final commit, but it is useful for testing. * the third one replace the use of CqlResult in the CQL3 code to directly build the new messages. And for the thrift interface, it simply translate those message to CqlResult. I've done it that way (instead of generating CqlResult and convert that to messages of the native protocol) because I think that is the direction we want to go. However currently that means that there is a few info that don't make it anymore in the CqlResult, namely the timestamp of the columns. Anywa, imo CASSANDRA-4217 is a much better way to access the timestamp and I'm not sure existing client were exposing the timestamp, but if there is complaints, that can be fixe is a much better way to access the timestamp and I'm not sure existing client were exposing the timestamp, but if there is complaints, that can be fixed. * the last one changes our CassandraDaemon business so that we can run a server with both the thrift and native protocol server running cleanly. Other than that, I have really benchmarked this (but that should be done). I meant to update stress to use the new server but realized that stress doesn't work for CQL3 at all, so that will be a separate ticket probably. Custom CQL protocol/transport - Key: CASSANDRA-2478 URL: https://issues.apache.org/jira/browse/CASSANDRA-2478 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Eric Evans Assignee: Sylvain Lebresne Priority: Minor Labels: cql Attachments: cql_binary_protocol A custom wire protocol would give us the flexibility to optimize for our specific use-cases, and eliminate a troublesome dependency (I'm referring to Thrift, but none of the others would be significantly better). Additionally, RPC is bad fit here, and we'd do better to move in the direction of something that natively supports streaming. I don't think this is as daunting as it might seem initially. Utilizing an existing server framework like Netty, combined with some copy-and-paste of bits from other FLOSS projects would probably get us 80% of the way there. -- 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-3794) Change ColumnFamily identifiers to be UUIDs instead of sequential Integers.
[ https://issues.apache.org/jira/browse/CASSANDRA-3794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13276804#comment-13276804 ] Pavel Yaskevich commented on CASSANDRA-3794: It doesn't really help tho if the same CF created on the different nodes simultaneously. Change ColumnFamily identifiers to be UUIDs instead of sequential Integers. --- Key: CASSANDRA-3794 URL: https://issues.apache.org/jira/browse/CASSANDRA-3794 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Pavel Yaskevich Assignee: Pavel Yaskevich Fix For: 1.1.1 Change ColumnFamily identifiers to be UUIDs instead of sequential Integers. Would be useful in the situation when nodes simultaneously trying to create ColumnFamilies. -- 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-4245) Provide a UT8Type (case insensitive) comparator
[ https://issues.apache.org/jira/browse/CASSANDRA-4245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13276807#comment-13276807 ] Jonathan Ellis commented on CASSANDRA-4245: --- bq. I think 3 columns is what we want In that case, I think our message should be, call toLowerCase client side. It's virtually painless and doesn't expose us to the mess that is case-insensitive but case-preserving, which is what I think you're suggesting. bq. There is a default case insensitive comparator in java Note that this Comparator does not take locale into account, and will result in an unsatisfactory ordering for certain locales. The java.text package provides Collators to allow locale-sensitive ordering. I'm starting to think that Brandon is right, and trying to do this in a unicode-aware world is a world of hurt. In particular, a single case-insensitive comparator will never provide the right ordering for all locales. And providing a comparator per locale is clearly insane. Provide a UT8Type (case insensitive) comparator --- Key: CASSANDRA-4245 URL: https://issues.apache.org/jira/browse/CASSANDRA-4245 Project: Cassandra Issue Type: New Feature Reporter: Ertio Lew Priority: Minor It is a common use case to use a bunch of entity names as column names then use the row as a search index, using search by range. For such use cases others, it is useful to have a UTF8 comparator that provides case insensitive ordering of columns. -- 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-3794) Change ColumnFamily identifiers to be UUIDs instead of sequential Integers.
[ https://issues.apache.org/jira/browse/CASSANDRA-3794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13276808#comment-13276808 ] Jonathan Ellis commented on CASSANDRA-3794: --- As long as everyone agrees on one of the CF definitions eventually, or even a combination of the two, that's totally fine. Change ColumnFamily identifiers to be UUIDs instead of sequential Integers. --- Key: CASSANDRA-3794 URL: https://issues.apache.org/jira/browse/CASSANDRA-3794 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Pavel Yaskevich Assignee: Pavel Yaskevich Fix For: 1.1.1 Change ColumnFamily identifiers to be UUIDs instead of sequential Integers. Would be useful in the situation when nodes simultaneously trying to create ColumnFamilies. -- 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-1974) PFEPS-like snitch that uses gossip instead of a property file
[ https://issues.apache.org/jira/browse/CASSANDRA-1974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13276841#comment-13276841 ] Wilfried Schobeiri commented on CASSANDRA-1974: --- For those of us not on ec2, it would be incredibly convenient to have changes to the topology propagate across the entire cluster instead of maintaining an additional rsync. +1 PFEPS-like snitch that uses gossip instead of a property file - Key: CASSANDRA-1974 URL: https://issues.apache.org/jira/browse/CASSANDRA-1974 Project: Cassandra Issue Type: New Feature Reporter: Brandon Williams Priority: Minor Now that we have an ec2 snitch that propagates its rack/dc info via gossip from CASSANDRA-1654, it doesn't make a lot of sense to use PFEPS where you have to rsync the property file across all the machines when you add a node. Instead, we could have a snitch where you specify its rack/dc in a property file, and propagate this via gossip like the ec2 snitch. In order to not break PFEPS, this should probably be a new snitch. -- 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-4249) LOGGING: Info log is not displaying number of rows read from saved cache at startup
[ https://issues.apache.org/jira/browse/CASSANDRA-4249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4249: -- Reviewer: jbellis Fix Version/s: (was: 1.2) 1.1.1 Assignee: sankalp kohli Labels: caching (was: ) LOGGING: Info log is not displaying number of rows read from saved cache at startup --- Key: CASSANDRA-4249 URL: https://issues.apache.org/jira/browse/CASSANDRA-4249 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.0 Reporter: sankalp kohli Assignee: sankalp kohli Priority: Trivial Labels: caching Fix For: 1.1.1 Attachments: trunk-4249.txt Original Estimate: 0.1h Remaining Estimate: 0.1h As part of commit with revision c9270f4e info logging for number of rows read from saved cache is not working. This is happening because we are not incrementing the counter cachedRowsRead in ColumnFamilyStore.initRowCache(). -- 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-1974) PFEPS-like snitch that uses gossip instead of a property file
[ https://issues.apache.org/jira/browse/CASSANDRA-1974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams reassigned CASSANDRA-1974: --- Assignee: Brandon Williams PFEPS-like snitch that uses gossip instead of a property file - Key: CASSANDRA-1974 URL: https://issues.apache.org/jira/browse/CASSANDRA-1974 Project: Cassandra Issue Type: New Feature Reporter: Brandon Williams Assignee: Brandon Williams Priority: Minor Now that we have an ec2 snitch that propagates its rack/dc info via gossip from CASSANDRA-1654, it doesn't make a lot of sense to use PFEPS where you have to rsync the property file across all the machines when you add a node. Instead, we could have a snitch where you specify its rack/dc in a property file, and propagate this via gossip like the ec2 snitch. In order to not break PFEPS, this should probably be a new snitch. -- 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-4221) Error while deleting a columnfamily that is being compacted.
[
https://issues.apache.org/jira/browse/CASSANDRA-4221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13276866#comment-13276866
]
Jonathan Ellis commented on CASSANDRA-4221:
---
Tyler, can you still reproduce after the recent schema fixes on the 1.1 branch?
Error while deleting a columnfamily that is being compacted.
Key: CASSANDRA-4221
URL: https://issues.apache.org/jira/browse/CASSANDRA-4221
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0
Environment: ccm, dtest, cassandra-1.1. The error does not happen in
cassandra-1.0.
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich
Fix For: 1.1.1
Attachments: CASSANDRA-4221.patch
The following dtest command produces an error:
{code}export CASSANDRA_VERSION=git:cassandra-1.1; nosetests --nocapture
--nologcapture
concurrent_schema_changes_test.py:TestConcurrentSchemaChanges.load_test{code}
Here is the error:
{code}
Error occured during compaction
java.util.concurrent.ExecutionException: java.io.IOError:
java.io.FileNotFoundException:
/tmp/dtest-6ECMgy/test/node1/data/Keyspace1/Standard1/Keyspace1-Standard1-hc-47-Data.db
(No such file or directory)
at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:252)
at java.util.concurrent.FutureTask.get(FutureTask.java:111)
at
org.apache.cassandra.db.compaction.CompactionManager.performMaximal(CompactionManager.java:239)
at
org.apache.cassandra.db.ColumnFamilyStore.forceMajorCompaction(ColumnFamilyStore.java:1580)
at
org.apache.cassandra.service.StorageService.forceTableCompaction(StorageService.java:1770)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:111)
at
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:45)
at
com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:226)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:251)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:857)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:795)
at
javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1450)
at
javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:90)
at
javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1285)
at
javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1383)
at
javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:807)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
at sun.rmi.transport.Transport$1.run(Transport.java:177)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
Caused by: java.io.IOError: java.io.FileNotFoundException:
/tmp/dtest-6ECMgy/test/node1/data/Keyspace1/Standard1/Keyspace1-Standard1-hc-47-Data.db
(No such file or directory)
at
org.apache.cassandra.io.sstable.SSTableScanner.init(SSTableScanner.java:61)
at
org.apache.cassandra.io.sstable.SSTableReader.getDirectScanner(SSTableReader.java:839)
at
org.apache.cassandra.io.sstable.SSTableReader.getDirectScanner(SSTableReader.java:851)
at
[jira] [Commented] (CASSANDRA-4208) ColumnFamilyOutputFormat should support writing to multiple column families
[ https://issues.apache.org/jira/browse/CASSANDRA-4208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13276874#comment-13276874 ] Robbie Strickland commented on CASSANDRA-4208: -- Any word on this? ColumnFamilyOutputFormat should support writing to multiple column families --- Key: CASSANDRA-4208 URL: https://issues.apache.org/jira/browse/CASSANDRA-4208 Project: Cassandra Issue Type: Improvement Components: Hadoop Affects Versions: 1.1.0 Reporter: Robbie Strickland Attachments: cassandra-1.1-4208-v2.txt, cassandra-1.1-4208-v3.txt, cassandra-1.1-4208.txt, trunk-4208-v2.txt, trunk-4208.txt It is not currently possible to output records to more than one column family in a single reducer. Considering that writing values to Cassandra often involves multiple column families (i.e. updating your index when you insert a new value), this seems overly restrictive. I am submitting a patch that moves the specification of column family from the job configuration to the write() call in ColumnFamilyRecordWriter. -- 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
[2/4] git commit: log number of rows read from saved cache patch by Sankalp Kohli; reviewed by jbellis for CASSANDRA-4249
log number of rows read from saved cache patch by Sankalp Kohli; reviewed by jbellis for CASSANDRA-4249 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/7dae25d8 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/7dae25d8 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/7dae25d8 Branch: refs/heads/cassandra-1.1 Commit: 7dae25d87e77208c471c59b1851981bf34acaafb Parents: 1e8685d Author: Jonathan Ellis jbel...@apache.org Authored: Wed May 16 11:08:05 2012 -0500 Committer: Jonathan Ellis jbel...@apache.org Committed: Wed May 16 11:08:05 2012 -0500 -- CHANGES.txt|1 + .../org/apache/cassandra/db/ColumnFamilyStore.java |1 + 2 files changed, 2 insertions(+), 0 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/7dae25d8/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 4f1046b..d59480a 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 1.1.1-dev + * log number of rows read from saved cache (CASSANDRA-4249) * calculate exact size required for cleanup operations (CASSANDRA-1404) * avoid blocking additional writes during flush when the commitlog gets behind temporarily (CASSANDRA-1991) http://git-wip-us.apache.org/repos/asf/cassandra/blob/7dae25d8/src/java/org/apache/cassandra/db/ColumnFamilyStore.java -- diff --git a/src/java/org/apache/cassandra/db/ColumnFamilyStore.java b/src/java/org/apache/cassandra/db/ColumnFamilyStore.java index 4cfe041..c55d924 100644 --- a/src/java/org/apache/cassandra/db/ColumnFamilyStore.java +++ b/src/java/org/apache/cassandra/db/ColumnFamilyStore.java @@ -418,6 +418,7 @@ public class ColumnFamilyStore implements ColumnFamilyStoreMBean Integer.MIN_VALUE, true); CacheService.instance.rowCache.put(new RowCacheKey(metadata.cfId, key), data); +cachedRowsRead++; } if (cachedRowsRead 0)
[4/4] git commit: Fix missing arrayOffset in FBUtilities.hash
Fix missing arrayOffset in FBUtilities.hash
patch by Richard Low; reviewed by slebresne for CASSANDRA-4250
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/1e8685d8
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/1e8685d8
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/1e8685d8
Branch: refs/heads/trunk
Commit: 1e8685d836fee9f65f976d4587da88bda3dbeca2
Parents: 59a0421
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Wed May 16 11:55:12 2012 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Wed May 16 11:55:12 2012 +0200
--
CHANGES.txt|1 +
.../org/apache/cassandra/utils/FBUtilities.java|2 +-
2 files changed, 2 insertions(+), 1 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/1e8685d8/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 211314f..4f1046b 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -45,6 +45,7 @@
* (cql3) Don't return range ghosts anymore (CASSANDRA-3982)
* fix the problem re-creating Keyspace/ColumnFamily (CASSANDRA-4219)
* fix SecondaryIndex LelevedManifest save upon snapshot (CASSANDRA-4230)
+ * fix missing arrayOffset in FBUtilities.hash (CASSANDRA-4250)
Merged from 1.0:
* Fix super columns bug where cache is not updated (CASSANDRA-4190)
* fix maxTimestamp to include row tombstones (CASSANDRA-4116)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/1e8685d8/src/java/org/apache/cassandra/utils/FBUtilities.java
--
diff --git a/src/java/org/apache/cassandra/utils/FBUtilities.java
b/src/java/org/apache/cassandra/utils/FBUtilities.java
index c0fe9bd..fb2adfe 100644
--- a/src/java/org/apache/cassandra/utils/FBUtilities.java
+++ b/src/java/org/apache/cassandra/utils/FBUtilities.java
@@ -221,7 +221,7 @@ public class FBUtilities
for (ByteBuffer block : data)
{
if (block.hasArray())
-messageDigest.update(block.array(), block.position(),
block.remaining());
+messageDigest.update(block.array(), block.arrayOffset() +
block.position(), block.remaining());
else
messageDigest.update(block.duplicate());
}
[1/4] git commit: Merge branch 'cassandra-1.1' into trunk
Updated Branches: refs/heads/cassandra-1.1 1e8685d83 - 7dae25d87 refs/heads/trunk 34bdc7cc9 - 71b38b094 Merge branch 'cassandra-1.1' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/71b38b09 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/71b38b09 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/71b38b09 Branch: refs/heads/trunk Commit: 71b38b09428abd95a9d70ae29ae9fd0061c5a0f4 Parents: 34bdc7c 7dae25d Author: Jonathan Ellis jbel...@apache.org Authored: Wed May 16 11:52:57 2012 -0500 Committer: Jonathan Ellis jbel...@apache.org Committed: Wed May 16 11:52:57 2012 -0500 -- CHANGES.txt|2 ++ .../org/apache/cassandra/db/ColumnFamilyStore.java |1 + .../org/apache/cassandra/utils/FBUtilities.java|2 +- 3 files changed, 4 insertions(+), 1 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/71b38b09/CHANGES.txt -- diff --cc CHANGES.txt index 38c78f7,d59480a..27c5e58 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,14 -1,5 +1,15 @@@ +1.2-dev + * Track tombstone expiration and compact when tombstone content is + higher than a configurable threshold, default 20% (CASSANDRA-3442) + * update MurmurHash to version 3 (CASSANDRA-2975) + * (CLI) track elapsed time for `delete' operation (CASSANDRA-4060) + * (CLI) jline version is bumped to 1.0 to properly support + 'delete' key function (CASSANDRA-4132) + * Save IndexSummary into new SSTable 'Summary' component (CASSANDRA-2392) + + 1.1.1-dev + * log number of rows read from saved cache (CASSANDRA-4249) * calculate exact size required for cleanup operations (CASSANDRA-1404) * avoid blocking additional writes during flush when the commitlog gets behind temporarily (CASSANDRA-1991) http://git-wip-us.apache.org/repos/asf/cassandra/blob/71b38b09/src/java/org/apache/cassandra/db/ColumnFamilyStore.java -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/71b38b09/src/java/org/apache/cassandra/utils/FBUtilities.java --
[3/4] git commit: log number of rows read from saved cache patch by Sankalp Kohli; reviewed by jbellis for CASSANDRA-4249
log number of rows read from saved cache patch by Sankalp Kohli; reviewed by jbellis for CASSANDRA-4249 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/7dae25d8 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/7dae25d8 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/7dae25d8 Branch: refs/heads/trunk Commit: 7dae25d87e77208c471c59b1851981bf34acaafb Parents: 1e8685d Author: Jonathan Ellis jbel...@apache.org Authored: Wed May 16 11:08:05 2012 -0500 Committer: Jonathan Ellis jbel...@apache.org Committed: Wed May 16 11:08:05 2012 -0500 -- CHANGES.txt|1 + .../org/apache/cassandra/db/ColumnFamilyStore.java |1 + 2 files changed, 2 insertions(+), 0 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/7dae25d8/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 4f1046b..d59480a 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 1.1.1-dev + * log number of rows read from saved cache (CASSANDRA-4249) * calculate exact size required for cleanup operations (CASSANDRA-1404) * avoid blocking additional writes during flush when the commitlog gets behind temporarily (CASSANDRA-1991) http://git-wip-us.apache.org/repos/asf/cassandra/blob/7dae25d8/src/java/org/apache/cassandra/db/ColumnFamilyStore.java -- diff --git a/src/java/org/apache/cassandra/db/ColumnFamilyStore.java b/src/java/org/apache/cassandra/db/ColumnFamilyStore.java index 4cfe041..c55d924 100644 --- a/src/java/org/apache/cassandra/db/ColumnFamilyStore.java +++ b/src/java/org/apache/cassandra/db/ColumnFamilyStore.java @@ -418,6 +418,7 @@ public class ColumnFamilyStore implements ColumnFamilyStoreMBean Integer.MIN_VALUE, true); CacheService.instance.rowCache.put(new RowCacheKey(metadata.cfId, key), data); +cachedRowsRead++; } if (cachedRowsRead 0)
[jira] [Commented] (CASSANDRA-4150) Looks like Maximum amount of cache available in 1.1 is 2 GB
[
https://issues.apache.org/jira/browse/CASSANDRA-4150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13276879#comment-13276879
]
Jonathan Ellis commented on CASSANDRA-4150:
---
{code}
. EntryWeigherKeyCacheKey, RowIndexEntry weigher = new
EntryWeigherKeyCacheKey, RowIndexEntry()
{
public int weightOf(KeyCacheKey key, RowIndexEntry value)
{
return key.serializedSize() + value.serializedSize();
}
};
ICacheKeyCacheKey, RowIndexEntry kc =
ConcurrentLinkedHashCache.create(keyCacheInMemoryCapacity, weigher);
{code}
Using the serialized size for a non-serialized cache looks fishy to me.
Looks like Maximum amount of cache available in 1.1 is 2 GB
---
Key: CASSANDRA-4150
URL: https://issues.apache.org/jira/browse/CASSANDRA-4150
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0
Reporter: Vijay
Assignee: Vijay
Attachments: 0001-CASSANDRA-4139-v2.patch, 0001-CASSANDRA-4150.patch,
0002-Use-EntryWeigher-for-HeapCache.patch,
0002-add-bytes-written-metric-v2.patch, concurrentlinkedhashmap-lru-1.3.jar
The problem is that capacity is a Integer which can maximum hold 2 GB,
I will post a fix to CLHM in the mean time we might want to remove the
maximumWeightedCapacity code path (atleast for Serializing cache) and
implement it in our code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4251) when loading schema make sure the key and value are not present in the cfIdMap (BiDiMap)
[ https://issues.apache.org/jira/browse/CASSANDRA-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13276901#comment-13276901 ] Jonathan Ellis commented on CASSANDRA-4251: --- Can you reproduce this? Multiple CFs w/ the same id sounds like a pretty nasty bug. when loading schema make sure the key and value are not present in the cfIdMap (BiDiMap) Key: CASSANDRA-4251 URL: https://issues.apache.org/jira/browse/CASSANDRA-4251 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.2 Reporter: Dave Brosius Priority: Trivial Attachments: better_schema_load_exs.diff google bidimap throws an uncaught runtime exception with less than informative information when the cfid already exists in the cfIDMap has it as a value. Add a check to the preflight check of the Schema class instead, so there is better messaging. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4251) when loading schema make sure the key and value are not present in the cfIdMap (BiDiMap)
[ https://issues.apache.org/jira/browse/CASSANDRA-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13276922#comment-13276922 ] Brandon Williams commented on CASSANDRA-4251: - Saw this on irc: Guest89350 hello, please help, after upgrading my cluster from 1.0.8 to 1.1.0 startup fails with: java.lang.IllegalArgumentException: value already present:1034 when loading schema make sure the key and value are not present in the cfIdMap (BiDiMap) Key: CASSANDRA-4251 URL: https://issues.apache.org/jira/browse/CASSANDRA-4251 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.2 Reporter: Dave Brosius Priority: Trivial Attachments: better_schema_load_exs.diff google bidimap throws an uncaught runtime exception with less than informative information when the cfid already exists in the cfIDMap has it as a value. Add a check to the preflight check of the Schema class instead, so there is better messaging. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2701) Memcache Row Cache Provider
[ https://issues.apache.org/jira/browse/CASSANDRA-2701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13276939#comment-13276939 ] sankalp kohli commented on CASSANDRA-2701: -- I am not supporting memcache here but coherence problem can be fixed by removing keys from memcache when applying commit log during startup. I have not seen the entire code but it might lead to some cross dependancies during startup. Memcache Row Cache Provider --- Key: CASSANDRA-2701 URL: https://issues.apache.org/jira/browse/CASSANDRA-2701 Project: Cassandra Issue Type: Improvement Reporter: Chris Goffinet Priority: Trivial Create a row cache provider that uses memcached. We would like to contribute our provider we wrote that we use in production. We co-locate memcached on every node, and utilize Cassandra's ability to do replication + routing. -- 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-4251) when loading schema make sure the key and value are not present in the cfIdMap (BiDiMap)
[ https://issues.apache.org/jira/browse/CASSANDRA-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13276949#comment-13276949 ] Jonathan Ellis commented on CASSANDRA-4251: --- We don't change CF IDs during the upgrade. So does that mean after upgrading and doing concurrent schema updates and hitting CASSANDRA-3794? Or something else entirely? when loading schema make sure the key and value are not present in the cfIdMap (BiDiMap) Key: CASSANDRA-4251 URL: https://issues.apache.org/jira/browse/CASSANDRA-4251 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.2 Reporter: Dave Brosius Priority: Trivial Attachments: better_schema_load_exs.diff google bidimap throws an uncaught runtime exception with less than informative information when the cfid already exists in the cfIDMap has it as a value. Add a check to the preflight check of the Schema class instead, so there is better messaging. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4242) Name of parameters should be available in CqlPreparedResult
[
https://issues.apache.org/jira/browse/CASSANDRA-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Chalamet updated CASSANDRA-4242:
---
Attachment: 4242_4.txt
Reverting to 2 lists in CqlPreparedResult
Column names are String now
Name of parameters should be available in CqlPreparedResult
---
Key: CASSANDRA-4242
URL: https://issues.apache.org/jira/browse/CASSANDRA-4242
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.0
Reporter: Pierre Chalamet
Priority: Minor
Attachments: 4242.txt, 4242_2.txt, 4242_3.txt, 4242_4.txt
Client side, it could be nice to have the name of parameters in
CqlPreparedResult. This could allow parameters mapping by name instead of by
index.
{code}
struct CqlNameType {
1: required binary key,
2: required string type
}
struct CqlPreparedResult {
1: required i32 itemId,
2: required i32 count,
3: optional liststring variable_types,
4: optional listCqlNameType name_types
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2819) Split rpc timeout for read and write ops
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2819: -- Attachment: 2819-v8.txt v8 adds truncate timeout and rebases. I don't think separate gossip or socket timeouts are crucial. Happy to leave them using the generic one. Updated the repair waits to use write timeout. Still todo: - handle expiringmap somehow. max(timeouts) would be technically correct but with truncate taking a (much) longer timeout (since it has to wait for compaction to finish), that could leave a lot of garbage in the map Split rpc timeout for read and write ops Key: CASSANDRA-2819 URL: https://issues.apache.org/jira/browse/CASSANDRA-2819 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Stu Hood Assignee: Melvin Wang Fix For: 1.1.1 Attachments: 2819-v4.txt, 2819-v5-rebased.txt, 2819-v8.txt, c2819-v6, c2819-v7, c2819.patch, rpc-jira.patch Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally. -- 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-4242) Name of parameters should be available in CqlPreparedResult
[
https://issues.apache.org/jira/browse/CASSANDRA-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-4242:
--
Reviewer: slebresne
Assignee: Pierre Chalamet
Name of parameters should be available in CqlPreparedResult
---
Key: CASSANDRA-4242
URL: https://issues.apache.org/jira/browse/CASSANDRA-4242
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.0
Reporter: Pierre Chalamet
Assignee: Pierre Chalamet
Priority: Minor
Fix For: 1.1.1
Attachments: 4242.txt, 4242_2.txt, 4242_3.txt, 4242_4.txt
Client side, it could be nice to have the name of parameters in
CqlPreparedResult. This could allow parameters mapping by name instead of by
index.
{code}
struct CqlNameType {
1: required binary key,
2: required string type
}
struct CqlPreparedResult {
1: required i32 itemId,
2: required i32 count,
3: optional liststring variable_types,
4: optional listCqlNameType name_types
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4242) Name of parameters should be available in CqlPreparedResult
[
https://issues.apache.org/jira/browse/CASSANDRA-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-4242:
--
Fix Version/s: 1.1.1
Name of parameters should be available in CqlPreparedResult
---
Key: CASSANDRA-4242
URL: https://issues.apache.org/jira/browse/CASSANDRA-4242
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.0
Reporter: Pierre Chalamet
Assignee: Pierre Chalamet
Priority: Minor
Fix For: 1.1.1
Attachments: 4242.txt, 4242_2.txt, 4242_3.txt, 4242_4.txt
Client side, it could be nice to have the name of parameters in
CqlPreparedResult. This could allow parameters mapping by name instead of by
index.
{code}
struct CqlNameType {
1: required binary key,
2: required string type
}
struct CqlPreparedResult {
1: required i32 itemId,
2: required i32 count,
3: optional liststring variable_types,
4: optional listCqlNameType name_types
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-2973) fatal errrors after nodetool cleanup
[ https://issues.apache.org/jira/browse/CASSANDRA-2973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-2973. --- Resolution: Cannot Reproduce Assignee: (was: Sylvain Lebresne) fatal errrors after nodetool cleanup Key: CASSANDRA-2973 URL: https://issues.apache.org/jira/browse/CASSANDRA-2973 Project: Cassandra Issue Type: Bug Affects Versions: 0.8.1 Reporter: Wojciech Meler after adding nodes to cluster running cleanup I get scaring exceptions in log: 2011-07-30 00:00:05:506 CEST ERROR [ReadStage:2335][org.apache.cassandra.service.AbstractCassandraDaemon] Fatal exception in thread Thread[ReadStage:2335,5,main] java.io.IOError: java.io.IOException: mmap segment underflow; remaining is 4394 but 60165 requested at org.apache.cassandra.db.columniterator.IndexedSliceReader.init(IndexedSliceReader.java:80) at org.apache.cassandra.db.columniterator.SSTableSliceIterator.createReader(SSTableSliceIterator.java:91) at org.apache.cassandra.db.columniterator.SSTableSliceIterator.init(SSTableSliceIterator.java:67) at org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:66) at org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:80) at org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1292) at org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1189) at org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1146) at org.apache.cassandra.db.Table.getRow(Table.java:385) at org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:61) at org.apache.cassandra.db.ReadVerbHandler.doVerb(ReadVerbHandler.java:69) at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:72) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: java.io.IOException: mmap segment underflow; remaining is 4394 but 60165 requested at org.apache.cassandra.io.util.MappedFileDataInput.readBytes(MappedFileDataInput.java:117) at org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:389) at org.apache.cassandra.utils.ByteBufferUtil.readWithShortLength(ByteBufferUtil.java:368) at org.apache.cassandra.io.sstable.IndexHelper$IndexInfo.deserialize(IndexHelper.java:194) at org.apache.cassandra.io.sstable.IndexHelper.deserializeIndex(IndexHelper.java:83) at org.apache.cassandra.db.columniterator.IndexedSliceReader.init(IndexedSliceReader.java:73) ... 14 more exceptions disappeared after running scrub -- 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-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=13277154#comment-13277154 ] Jonathan Ellis commented on CASSANDRA-2967: --- Alex, are you still working on 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 Reporter: Joaquin Casares Assignee: Alex Araujo Priority: Minor Labels: lhf Attachments: cassandra-0.8-2967.txt, cassandra-1.0-2967-v2.txt, cassandra-1.0-2967-v3.txt, cassandra-1.0-2967-v4.txt 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-2930) corrupt commitlog
[ https://issues.apache.org/jira/browse/CASSANDRA-2930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-2930. --- Resolution: Cannot Reproduce Assignee: (was: Rick Branson) corrupt commitlog - Key: CASSANDRA-2930 URL: https://issues.apache.org/jira/browse/CASSANDRA-2930 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.1 Environment: Linux, amd64. Java(TM) SE Runtime Environment (build 1.6.0_26-b03) Reporter: ivan Labels: datastax_qa Attachments: CommitLog-1310637513214.log We get Exception encountered during startup error while Cassandra starts. Error messages: INFO 13:56:28,736 Finished reading /var/lib/cassandra/commitlog/CommitLog-1310637513214.log ERROR 13:56:28,736 Exception encountered during startup. java.io.IOError: java.io.EOFException at org.apache.cassandra.io.util.ColumnIterator.deserializeNext(ColumnSortedMap.java:265) at org.apache.cassandra.io.util.ColumnIterator.next(ColumnSortedMap.java:281) at org.apache.cassandra.io.util.ColumnIterator.next(ColumnSortedMap.java:236) at java.util.concurrent.ConcurrentSkipListMap.buildFromSorted(ConcurrentSkipListMap.java:1493) at java.util.concurrent.ConcurrentSkipListMap.init(ConcurrentSkipListMap.java:1443) at org.apache.cassandra.db.SuperColumnSerializer.deserialize(SuperColumn.java:419) at org.apache.cassandra.db.ColumnFamilySerializer.deserializeColumns(ColumnFamilySerializer.java:139) at org.apache.cassandra.db.ColumnFamilySerializer.deserialize(ColumnFamilySerializer.java:127) at org.apache.cassandra.db.RowMutation$RowMutationSerializer.deserialize(RowMutation.java:382) at org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:278) at org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:158) at org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:175) at org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:368) at org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:80) Caused by: java.io.EOFException at java.io.DataInputStream.readFully(DataInputStream.java:180) at java.io.DataInputStream.readFully(DataInputStream.java:152) at org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:394) at org.apache.cassandra.utils.ByteBufferUtil.readWithShortLength(ByteBufferUtil.java:368) at org.apache.cassandra.db.ColumnSerializer.deserialize(ColumnSerializer.java:87) at org.apache.cassandra.io.util.ColumnIterator.deserializeNext(ColumnSortedMap.java:261) ... 13 more Exception encountered during startup. java.io.IOError: java.io.EOFException at org.apache.cassandra.io.util.ColumnIterator.deserializeNext(ColumnSortedMap.java:265) at org.apache.cassandra.io.util.ColumnIterator.next(ColumnSortedMap.java:281) at org.apache.cassandra.io.util.ColumnIterator.next(ColumnSortedMap.java:236) at java.util.concurrent.ConcurrentSkipListMap.buildFromSorted(ConcurrentSkipListMap.java:1493) at java.util.concurrent.ConcurrentSkipListMap.init(ConcurrentSkipListMap.java:1443) at org.apache.cassandra.db.SuperColumnSerializer.deserialize(SuperColumn.java:419) at org.apache.cassandra.db.ColumnFamilySerializer.deserializeColumns(ColumnFamilySerializer.java:139) at org.apache.cassandra.db.ColumnFamilySerializer.deserialize(ColumnFamilySerializer.java:127) at org.apache.cassandra.db.RowMutation$RowMutationSerializer.deserialize(RowMutation.java:382) at org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:278) at org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:158) at org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:175) at org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:368) at org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:80) Caused by: java.io.EOFException at java.io.DataInputStream.readFully(DataInputStream.java:180) at java.io.DataInputStream.readFully(DataInputStream.java:152) at org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:394) at org.apache.cassandra.utils.ByteBufferUtil.readWithShortLength(ByteBufferUtil.java:368) at org.apache.cassandra.db.ColumnSerializer.deserialize(ColumnSerializer.java:87) at
[jira] [Updated] (CASSANDRA-2858) make request dropping more accurate
[ https://issues.apache.org/jira/browse/CASSANDRA-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2858: -- Fix Version/s: 1.2 make request dropping more accurate --- Key: CASSANDRA-2858 URL: https://issues.apache.org/jira/browse/CASSANDRA-2858 Project: Cassandra Issue Type: Improvement Reporter: Ryan King Assignee: Melvin Wang Priority: Minor Fix For: 1.2 Based on the discussion in https://issues.apache.org/jira/browse/CASSANDRA-2819, we can make the bookkeeping for request times more accurate. -- 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-2828) CommitLog tool
[ https://issues.apache.org/jira/browse/CASSANDRA-2828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13277164#comment-13277164 ] Jonathan Ellis commented on CASSANDRA-2828: --- Is this worth updating for 1.1? My impression is that CASSANDRA-2427 has made this problem go away. CommitLog tool -- Key: CASSANDRA-2828 URL: https://issues.apache.org/jira/browse/CASSANDRA-2828 Project: Cassandra Issue Type: New Feature Components: Core Affects Versions: 0.7.6 Reporter: Aaron Morton Assignee: Aaron Morton Priority: Minor Attachments: 0001-2828-07.patch I wrote this for 0.7.6-2 because I had a need to see what log segment headers were preventing logs from flushing. I've not had a chance to look at it in 0.8 yet. We dont not has header files anymore, so I could turn this into a function on the StorageServiceMBean. For my use case i pulled the log headers off a server that had gone into a spin after it filled the commit log volume. nodetool was not running so these was the best solution for me. Posting here to see if there is any interest or need. I think the best approach may be to add a function to the StorageService MBean to find out which CF's are dirty in the active log segments. -- 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-2782) Create a debian package for the CQL drivers
[ https://issues.apache.org/jira/browse/CASSANDRA-2782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-2782. --- Resolution: Invalid CQL drivers have moved out of tree. Create a debian package for the CQL drivers --- Key: CASSANDRA-2782 URL: https://issues.apache.org/jira/browse/CASSANDRA-2782 Project: Cassandra Issue Type: Wish Components: Packaging Reporter: Sylvain Lebresne Priority: Minor Since the CQL drivers are not release in lockstep with Cassandra, they are excluded from the Cassandra debian package. Creating a debian package for them could make debian user's live a bit easier. -- 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-2977) add paging to multiget_count
[ https://issues.apache.org/jira/browse/CASSANDRA-2977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-2977. --- Resolution: Won't Fix Wontfixing because I'd rather spend the time improving CQL. add paging to multiget_count Key: CASSANDRA-2977 URL: https://issues.apache.org/jira/browse/CASSANDRA-2977 Project: Cassandra Issue Type: Improvement Reporter: Jonathan Ellis Priority: Minor CASSANDRA-2894 added paging to the single-row get_count. But, this does not help multiget_count since they are different code paths. Options: - do nothing; multiget_count is a fairly obscure call, and there is no sane way to support it in CQL so will become even more obscure - translate multiget_count into a series of get_count calls; high-latency, if done naively - translate get_count into a single multiget_count, and perform the paging in StorageProxy. HIGHLY painful to manage paging multiple rows independently, in the general case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4252) Set operation mode to MOVING earlier
Nick Bailey created CASSANDRA-4252: -- Summary: Set operation mode to MOVING earlier Key: CASSANDRA-4252 URL: https://issues.apache.org/jira/browse/CASSANDRA-4252 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.0 Reporter: Nick Bailey Priority: Minor Right now when moving a node we set the OperationMode only once we've calculated the necessary ranges to transfer and if there actually are ranges to transfer. Due to the sleep for ring settling this means there are 30 seconds where the node is moving but the operation mode isn't set accordingly. Additionally if it turns out no data needs to be transferred then the move will complete without ever switching the OperationMode to moving. -- 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-4253) Add support for specifying composites for comparator, key_validation_class and default_validation_class in cli
Dave Brosius created CASSANDRA-4253: --- Summary: Add support for specifying composites for comparator, key_validation_class and default_validation_class in cli Key: CASSANDRA-4253 URL: https://issues.apache.org/jira/browse/CASSANDRA-4253 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 1.2 Reporter: Dave Brosius Priority: Trivial Attachments: specify_composites_for_cfs_in_cli.diff like create column family foo with comparator=(UTF8Type, LongType) and key_validation_class=(AsciiType,BytesType) and default_validation_class=(UTF8Type, LongType) etc. on trunk -- 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-4253) Add support for specifying composites for comparator, key_validation_class and default_validation_class in cli
[ https://issues.apache.org/jira/browse/CASSANDRA-4253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Brosius updated CASSANDRA-4253: Attachment: specify_composites_for_cfs_in_cli.diff Add support for specifying composites for comparator, key_validation_class and default_validation_class in cli -- Key: CASSANDRA-4253 URL: https://issues.apache.org/jira/browse/CASSANDRA-4253 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 1.2 Reporter: Dave Brosius Priority: Trivial Attachments: specify_composites_for_cfs_in_cli.diff like create column family foo with comparator=(UTF8Type, LongType) and key_validation_class=(AsciiType,BytesType) and default_validation_class=(UTF8Type, LongType) etc. on trunk -- 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-4253) Add support for specifying composites for comparator, key_validation_class and default_validation_class in cli
[ https://issues.apache.org/jira/browse/CASSANDRA-4253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13277475#comment-13277475 ] Dave Brosius commented on CASSANDRA-4253: - bah, just realised you can use comparator= 'CompositeType(UTF8Type, UTF8Type)' Add support for specifying composites for comparator, key_validation_class and default_validation_class in cli -- Key: CASSANDRA-4253 URL: https://issues.apache.org/jira/browse/CASSANDRA-4253 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 1.2 Reporter: Dave Brosius Priority: Trivial Attachments: specify_composites_for_cfs_in_cli.diff like create column family foo with comparator=(UTF8Type, LongType) and key_validation_class=(AsciiType,BytesType) and default_validation_class=(UTF8Type, LongType) etc. on trunk -- 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-4253) Add support for specifying composites for comparator, key_validation_class and default_validation_class in cli
[ https://issues.apache.org/jira/browse/CASSANDRA-4253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Brosius resolved CASSANDRA-4253. - Resolution: Not A Problem Add support for specifying composites for comparator, key_validation_class and default_validation_class in cli -- Key: CASSANDRA-4253 URL: https://issues.apache.org/jira/browse/CASSANDRA-4253 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 1.2 Reporter: Dave Brosius Priority: Trivial Attachments: specify_composites_for_cfs_in_cli.diff like create column family foo with comparator=(UTF8Type, LongType) and key_validation_class=(AsciiType,BytesType) and default_validation_class=(UTF8Type, LongType) etc. on trunk -- 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-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=13277513#comment-13277513 ] Alex Araujo commented on CASSANDRA-2967: I haven't looked at this since Nov. Perhaps I should have unassigned it. Is this still something that's needed? I can take a stab at finishing/testing the missing options if there's a preference on -javaagent vs cassandra.yml. 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 Reporter: Joaquin Casares Assignee: Alex Araujo Priority: Minor Labels: lhf Attachments: cassandra-0.8-2967.txt, cassandra-1.0-2967-v2.txt, cassandra-1.0-2967-v3.txt, cassandra-1.0-2967-v4.txt 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] [Created] (CASSANDRA-4254) Add nodetool ability to inject a STS major into compaction
Brandon Williams created CASSANDRA-4254: --- Summary: Add nodetool ability to inject a STS major into compaction Key: CASSANDRA-4254 URL: https://issues.apache.org/jira/browse/CASSANDRA-4254 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Brandon Williams Fix For: 1.1.1 I've seen this more than once now: LCS got its butt kicked, and now it's going to take forever to catch up. To speed this process, you can switch to STS via jmx, force a major, then go back to LCS. It'd be nice to make this more convenient without the headache that we call jmx. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4221) Error while deleting a columnfamily that is being compacted.
[
https://issues.apache.org/jira/browse/CASSANDRA-4221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13277537#comment-13277537
]
Tyler Patterson commented on CASSANDRA-4221:
Yes, the error just happened again for me. I did a fresh pull on branch branch
cassandra-1.1.
Error while deleting a columnfamily that is being compacted.
Key: CASSANDRA-4221
URL: https://issues.apache.org/jira/browse/CASSANDRA-4221
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0
Environment: ccm, dtest, cassandra-1.1. The error does not happen in
cassandra-1.0.
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich
Fix For: 1.1.1
Attachments: CASSANDRA-4221.patch
The following dtest command produces an error:
{code}export CASSANDRA_VERSION=git:cassandra-1.1; nosetests --nocapture
--nologcapture
concurrent_schema_changes_test.py:TestConcurrentSchemaChanges.load_test{code}
Here is the error:
{code}
Error occured during compaction
java.util.concurrent.ExecutionException: java.io.IOError:
java.io.FileNotFoundException:
/tmp/dtest-6ECMgy/test/node1/data/Keyspace1/Standard1/Keyspace1-Standard1-hc-47-Data.db
(No such file or directory)
at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:252)
at java.util.concurrent.FutureTask.get(FutureTask.java:111)
at
org.apache.cassandra.db.compaction.CompactionManager.performMaximal(CompactionManager.java:239)
at
org.apache.cassandra.db.ColumnFamilyStore.forceMajorCompaction(ColumnFamilyStore.java:1580)
at
org.apache.cassandra.service.StorageService.forceTableCompaction(StorageService.java:1770)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:111)
at
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:45)
at
com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:226)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:251)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:857)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:795)
at
javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1450)
at
javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:90)
at
javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1285)
at
javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1383)
at
javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:807)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
at sun.rmi.transport.Transport$1.run(Transport.java:177)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
Caused by: java.io.IOError: java.io.FileNotFoundException:
/tmp/dtest-6ECMgy/test/node1/data/Keyspace1/Standard1/Keyspace1-Standard1-hc-47-Data.db
(No such file or directory)
at
org.apache.cassandra.io.sstable.SSTableScanner.init(SSTableScanner.java:61)
at
org.apache.cassandra.io.sstable.SSTableReader.getDirectScanner(SSTableReader.java:839)
at
org.apache.cassandra.io.sstable.SSTableReader.getDirectScanner(SSTableReader.java:851)
at
