[jira] [Created] (CASSANDRA-3652) correct and improve stream protocol mismatch error
correct and improve stream protocol mismatch error -- Key: CASSANDRA-3652 URL: https://issues.apache.org/jira/browse/CASSANDRA-3652 Project: Cassandra Issue Type: Bug Reporter: Peter Schuller Assignee: Peter Schuller Priority: Minor The message (and code comment) claims it got a newer version despite the fact that the check only determines that it is non-equal. Fix that, and also print the actual version gotten and expected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-3652) correct and improve stream protocol mismatch error
[ https://issues.apache.org/jira/browse/CASSANDRA-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Schuller updated CASSANDRA-3652: -- Attachment: CASSANDRA-3652-1.0.txt Patch attached. correct and improve stream protocol mismatch error -- Key: CASSANDRA-3652 URL: https://issues.apache.org/jira/browse/CASSANDRA-3652 Project: Cassandra Issue Type: Bug Reporter: Peter Schuller Assignee: Peter Schuller Priority: Minor Attachments: CASSANDRA-3652-1.0.txt The message (and code comment) claims it got a newer version despite the fact that the check only determines that it is non-equal. Fix that, and also print the actual version gotten and expected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-3610) Checksum improvement for CompressedRandomAccessReader
[ https://issues.apache.org/jira/browse/CASSANDRA-3610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173038#comment-13173038 ] Sylvain Lebresne commented on CASSANDRA-3610: - Let's not bother with CRC32C for now. Checksum improvement for CompressedRandomAccessReader - Key: CASSANDRA-3610 URL: https://issues.apache.org/jira/browse/CASSANDRA-3610 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.1 Environment: JVM Reporter: Vijay Assignee: Vijay Priority: Minor Fix For: 1.1 Attachments: 0001-use-pure-java-CRC32.patch When compression is on, Currently we see checksum taking up about 40% of the CPU more than snappy library. Looks like hadoop solved it by implementing their own checksum, we can either use it or implement something like that. http://images.slidesharecdn.com/1toddlipconyanpeichen-cloudera-hadoopandperformance-final-10132228-phpapp01-slide-15-768.jpg?1321043717 in our test env it provided 50% improvement over native implementation which uses jni to call the OS. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3415) show schema fails
[
https://issues.apache.org/jira/browse/CASSANDRA-3415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173058#comment-13173058
]
Radim Kolar commented on CASSANDRA-3415:
This is fixed in 0.8 and 1.0 branches. Close ticket
show schema fails
-
Key: CASSANDRA-3415
URL: https://issues.apache.org/jira/browse/CASSANDRA-3415
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 0.8.4
Environment: freebsd
Reporter: Radim Kolar
Assignee: Jonathan Ellis
Priority: Minor
Fix For: 1.0.7
following command breaks show schema cli command with error A long is
exactly 8 bytes: 5
create column family resultcache with column_type = 'Super' and comparator =
'LongType' and key_validation_class = 'UTF8Type' and subcomparator =
'AsciiType' and replicate_on_write = false and rows_cached = 700 and
keys_cached = 3 and key_cache_save_period = 0 and column_metadata = [
{column_name: id, validation_class: LongType}, {column_name: name,
validation_class: 'AsciiType'}, {column_name: crc32, validation_class:
LongType}, {column_name: size, validation_class: LongType} ];
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-3415) show schema fails
[
https://issues.apache.org/jira/browse/CASSANDRA-3415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams resolved CASSANDRA-3415.
-
Resolution: Fixed
Fix Version/s: 0.8.10
show schema fails
-
Key: CASSANDRA-3415
URL: https://issues.apache.org/jira/browse/CASSANDRA-3415
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 0.8.4
Environment: freebsd
Reporter: Radim Kolar
Assignee: Jonathan Ellis
Priority: Minor
Fix For: 0.8.10, 1.0.7
following command breaks show schema cli command with error A long is
exactly 8 bytes: 5
create column family resultcache with column_type = 'Super' and comparator =
'LongType' and key_validation_class = 'UTF8Type' and subcomparator =
'AsciiType' and replicate_on_write = false and rows_cached = 700 and
keys_cached = 3 and key_cache_save_period = 0 and column_metadata = [
{column_name: id, validation_class: LongType}, {column_name: name,
validation_class: 'AsciiType'}, {column_name: crc32, validation_class:
LongType}, {column_name: size, validation_class: LongType} ];
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3554) Hints are not replayed unless node was marked down
[
https://issues.apache.org/jira/browse/CASSANDRA-3554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173128#comment-13173128
]
Brandon Williams commented on CASSANDRA-3554:
-
I'm not sure how exactly, but obviously the keys being passed here are not
quite what we think they are:
{noformat}
DEBUG 11:57:03,907 Started scheduleAllDeliveries
DEBUG 11:57:03,907 deliverHints to /7fff:::::::fffe
DEBUG 11:57:03,908 deliverHints to /:::::::5554
DEBUG 11:57:03,908 Checking remote(/7fff:::::::fffe)
schema before delivering hints
DEBUG 11:57:03,908 Finished scheduleAllDeliveries
ERROR 11:57:03,909 Fatal exception in thread Thread[HintedHandoff:3,1,main]
java.lang.NullPointerException
at
org.apache.cassandra.db.HintedHandOffManager.waitForSchemaAgreement(HintedHandOffManager.java:206)
at
org.apache.cassandra.db.HintedHandOffManager.deliverHintsToEndpoint(HintedHandOffManager.java:238)
at
org.apache.cassandra.db.HintedHandOffManager.access$200(HintedHandOffManager.java:84)
at
org.apache.cassandra.db.HintedHandOffManager$3.runMayThrow(HintedHandOffManager.java:383)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
{noformat}
Hints are not replayed unless node was marked down
--
Key: CASSANDRA-3554
URL: https://issues.apache.org/jira/browse/CASSANDRA-3554
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.0.0
Reporter: Jonathan Ellis
Assignee: Jonathan Ellis
Labels: hintedhandoff, jmx
Fix For: 1.0.7
Attachments: 0001-cleanup.patch, 0002-deliver.patch, 3554-1.0.txt
If B drops a write from A because it is overwhelmed (but not dead), A will
hint the write. But it will never get notified that B is back up (since it
was never down), so it will never attempt hint delivery.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-3641) inconsistent/corrupt counters w/ broken shards never converge
[ https://issues.apache.org/jira/browse/CASSANDRA-3641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173138#comment-13173138 ] Sylvain Lebresne commented on CASSANDRA-3641: - Let's open a separate ticket to discuss that. So far we've use the log only for recording errors so let's keep it at that for this ticket. inconsistent/corrupt counters w/ broken shards never converge - Key: CASSANDRA-3641 URL: https://issues.apache.org/jira/browse/CASSANDRA-3641 Project: Cassandra Issue Type: Bug Reporter: Peter Schuller Assignee: Peter Schuller Attachments: 3641-0.8-internal-not-for-inclusion.txt, 3641-trunk.txt We ran into a case (which MIGHT be related to CASSANDRA-3070) whereby we had counters that were corrupt (hopefully due to CASSANDRA-3178). The corruption was that there would exist shards with the *same* node_id, *same* clock id, but *different* counts. The counter column diffing and reconciliation code assumes that this never happens, and ignores the count. The problem with this is that if there is an inconsistency, the result of a reconciliation will depend on the order of the shards. In our case for example, we would see the value of the counter randomly fluctuating on a CL.ALL read, but we would get consistent (whatever the node had) on CL.ONE (submitted to one of the nodes in the replica set for the key). In addition, read repair would not work despite digest mismatches because the diffing algorithm also did not care about the counts when determining the differences to send. I'm attaching patches that fixes this. The first patch is against our 0.8 branch, which is not terribly useful to people, but I include it because it is the well-tested version that we have used on the production cluster which was subject to this corruption. The other patch is against trunk, and contains the same change. What the patch does is: * On diffing, treat as DISJOINT if there is a count discrepancy. * On reconciliation, look at the count and *deterministically* pick the higher one, and: ** log the fact that we detected a corrupt counter ** increment a JMX observable counter for monitoring purposes A cluster which is subject to such corruption and has this patch, will fix itself with and AES + compact (or just repeated compactions assuming the replicate-on-compact is able to deliver correctly). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-3651) Truncate shouldn't rethrow timeouts as UA
[ https://issues.apache.org/jira/browse/CASSANDRA-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-3651: Attachment: 0002-truncate-throws-TOE-on-timeout.txt 0001-Update-thrift-definition.txt Truncate shouldn't rethrow timeouts as UA - Key: CASSANDRA-3651 URL: https://issues.apache.org/jira/browse/CASSANDRA-3651 Project: Cassandra Issue Type: Bug Components: Core Reporter: Brandon Williams Assignee: Brandon Williams Fix For: 1.0.7 Attachments: 0001-Update-thrift-definition.txt, 0002-truncate-throws-TOE-on-timeout.txt Truncate is a very easy operation to timeout, but the timeouts rethrow as UnavailableException which is somewhat confusing. Instead it should throw TimedOutException. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3631) While sleeping for RING_DELAY, bootstrapping nodes do not show as joining in the ring (or at all)
[ https://issues.apache.org/jira/browse/CASSANDRA-3631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173142#comment-13173142 ] Brandon Williams commented on CASSANDRA-3631: - bq. the problem with making the default to be joining is that it will mark the server up I had another thought. When replacing a token, don't we know that up front with DD.getReplaceToken? So we can use that as a check as to whether we should start up in hibernate or joining. (I still like the idea of hibernate showing up as initializing though) While sleeping for RING_DELAY, bootstrapping nodes do not show as joining in the ring (or at all) - Key: CASSANDRA-3631 URL: https://issues.apache.org/jira/browse/CASSANDRA-3631 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.0 Reporter: Brandon Williams Assignee: Vijay Priority: Minor Fix For: 1.0.7 As the title says, the nodes do not show in the ring until they are actually in the token selection/streaming phase. This appears due to CASSANDRA-957, but now can be further exacerbated by longer sleep times for CASSANDRA-3629. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3649) Code style changes, aka The Big Reformat
[ https://issues.apache.org/jira/browse/CASSANDRA-3649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173160#comment-13173160 ] Sylvain Lebresne commented on CASSANDRA-3649: - I'm +1 on the remove of underscores in private variables. We don't do that anymore since a long time and this will bring consistency to the code base. I would also like replacing tabs by spaces in the few places where tabs are used (again consistency) and remove all end-of-line spaces (but that's to please my OCD, I'll live if we don't do it). But moving from brace-on-newline, not really fond of the idea. The code base is actually pretty consistent in its use of brace-on-newline, so moving from it won't add any consistency, it will just change the style. Ultimately style is a very subjective thing; I, for one, prefer brace-on-newlines. And I understand that the oracle conventions is to not have braces on new lines, and I would be fine with that argument alone if we were discussing the style of a new project, but changing this now means that no patch from before the refactor will ever apply, including everything that will be committed to some older version and merged up and every patches attached to JIRA at the time of the refactor. The other refactorings suggested above don't even come close to that because they are just about making minor parts of the code base more consistent with the vast majority of it. So following the definitions from http://www.apache.org/foundation/voting.html, I'm -0.9 for moving from brace-on-newlines. Code style changes, aka The Big Reformat Key: CASSANDRA-3649 URL: https://issues.apache.org/jira/browse/CASSANDRA-3649 Project: Cassandra Issue Type: Wish Components: Core Reporter: Brandon Williams Fix For: 1.2 With a new major release coming soon and not having a ton of huge pending patches that have prevented us from doing this in the past, post-freeze looks like a good time to finally do this. Mostly this will include the removal of underscores in private variables, and no more brace-on-newline policy. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-3649) Code style changes, aka The Big Reformat
[ https://issues.apache.org/jira/browse/CASSANDRA-3649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173168#comment-13173168 ] Brandon Williams commented on CASSANDRA-3649: - bq. I would also like replacing tabs by spaces in the few places where tabs are used (again consistency) and remove all end-of-line spaces (but that's to please my OCD, I'll live if we don't do it). +1 bq. Ultimately style is a very subjective thing; I, for one, prefer brace-on-newlines. I don't, or at least I used to not, but I've done it for so long now because of this inherited style that I'm pretty used to it, so I don't have any especially strong feelings either way here. bq. but changing this now means that no patch from before the refactor will ever apply, including everything that will be committed to some older version and merged up and every patches attached to JIRA at the time of the refactor Jonathan suggested that we reformat 1.0 as well to get around this problem, fwiw. Code style changes, aka The Big Reformat Key: CASSANDRA-3649 URL: https://issues.apache.org/jira/browse/CASSANDRA-3649 Project: Cassandra Issue Type: Wish Components: Core Reporter: Brandon Williams Fix For: 1.2 With a new major release coming soon and not having a ton of huge pending patches that have prevented us from doing this in the past, post-freeze looks like a good time to finally do this. Mostly this will include the removal of underscores in private variables, and no more brace-on-newline policy. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-2474) CQL support for compound columns
[
https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-2474:
Attachment: raw_composite.txt
bq. True, but none of the other proposals even come close to being as friendly
as this one for typical cases
Playing devils advocate I would say that 'sucking much less' doesn't
necessarily make it 'the right solution'.
Now, don't get me wrong, I like the TRANSPOSED idea for composite. But I think
you made 2 proposals:
# a reasonably generic way to access CF with composite comparator in a CQL-ish
way: the TRANSPOSED part.
# an attempt at some special handling for the case of composites where the last
component takes only a know number of values: the SPARSE thing.
I do like the first part. Though I'd like to mention some remarks on the
following comment:
bq. We're using TRANSPOSED AS similarly to how databases have used storage
hints like CLUSTERED. It doesn't affect the relational model of the data, but
it gives you different performance characteristics
While I understand what you mean, I don't think it's completely true. Because
in the transposed case, the order of definition matters, which has a
consequence on what you can do, both in terms of writes and reads.
Consider the two definitions:
{noformat}
CREATE TABLE test1 (
key text primary key,
prop1 int,
prop2 int,
prop3 int
)
{noformat}
and
{noformat}
CREATE TABLE test2 (
key int primary key,
prop1 int,
prop2 int,
prop3 int
) TRANSPOSED AS (prop1, prop2)
{noformat}
Those two definitions don't only differ from a performance standpoint.
Typically, you can do
{noformat}
UPDATE test1 SET prop2 = 42 WHERE key = 'someKey';
{noformat}
but you cannot do the same query on test2. Btw, for test2, you don't
necessarily have to specify prop2 for every row, but you need at least prop1
and prop3 each time. My point being that you do have to understand a bit what
is going on underneath to understand the limitation we will have to put on this.
You also have the similar thing for gets: you can do
{noformat}
SELECT prop2 FROM test1 WHERE key = 'someKey';
{noformat}
but this make no sense with test2 (or rather there is no way we can do this
efficiently, i.e, without reading the row fully).
That being said, I'll reiter that I'm reasonably convinced by this
transposition notion, even though I'll probably prefer to write it as
{noformat}
CREATE TRANSPOSED TABLE test2 (
key int primary key,
prop1 int,
prop2 int,
prop3 int
)
{noformat}
as was suggested in some comments above.
On the SPARSE thing, I am much less convinced that this is the right solution.
I think that having at the same 'level' variables that are just names to
identify values in the resultset (posted_at) and literals (posted_by) is
confusing (and ugly). (As a side note, I don't understand the choice of the
SPARSE word).
Overall, I'm afraid we'll end up doing some bad choice by trying to do too much
at once. The first problem we have is that CQL, that we'd like to push as the
de-facto way to access Cassandra, doesn't allow access to composite columns at
all. It seems to me that the transposed alone fixes that (again, except for the
dynamic composite type). The SPARSE don't add any new possibility, it just adds
a presumably better syntax for a specific case. I would be in favor of moving
this to a second step (which would be less urgent and would allow refocusing
the discussion on that very specific optimisation).
Lastly, and for the record, I would actually be in favor of having the first
step on this being the addition of a very simple 'raw' notation to access
composites. Something that could look like the example in the attached file
'raw_composite.txt' (put separatly because this comment is way too long
already). The advantages being that: it's super simple to do, it'll be natural
for users coming from thrift and it'll have not specific limitation (in
particular it'll handle dynamic composites). Then, a second step would be to
add more limited but more user-friendly notation to deal with specific cases
(like the transposed and the sparse thing).
CQL support for compound columns
Key: CASSANDRA-2474
URL: https://issues.apache.org/jira/browse/CASSANDRA-2474
Project: Cassandra
Issue Type: New Feature
Components: API, Core
Reporter: Eric Evans
Assignee: Pavel Yaskevich
Labels: cql
Fix For: 1.1
Attachments: 2474-transposed-1.PNG, 2474-transposed-raw.PNG,
2474-transposed-select.PNG, raw_composite.txt, screenshot-1.jpg,
screenshot-2.jpg
For the most part, this boils down to supporting the specification of
compound column names (the CQL syntax is colon-delimted terms), and then
teaching the
[jira] [Commented] (CASSANDRA-3649) Code style changes, aka The Big Reformat
[ https://issues.apache.org/jira/browse/CASSANDRA-3649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173224#comment-13173224 ] Jonathan Ellis commented on CASSANDRA-3649: --- bq. no patch from before the refactor will ever apply This is why we haven't done it in the past, but we don't have an outstanding backlog of large patches now. Additionally, if someone has a private set of Truly Epic patches, or if we want to resurrect an older one like CASSANDRA-678, we can always do it by reformatting the code the patch was generated against pre- and post- patch to get a modern-formatted patch. *I note, for vim users, that this is less than two minutes worth with a modern IDE. :) Not something I'd want to do every day, but like I said, we don't have a patch backlog large enough that this scares me. bq. including everything that will be committed to some older version and merged up As Brandon mentioned, I think we should reformat the 1.0 branch (just the brace-on-newline part) to make this no more of an issue than if we were sticking to just underscore removal etc. I think 0.7 and 0.8 are inactive enough that we don't merge from them anymore, but we could include them in the reformat too if you like. 0.8 could make sense, but we'll see where we are in a month after 0.8.10. Code style changes, aka The Big Reformat Key: CASSANDRA-3649 URL: https://issues.apache.org/jira/browse/CASSANDRA-3649 Project: Cassandra Issue Type: Wish Components: Core Reporter: Brandon Williams Fix For: 1.2 With a new major release coming soon and not having a ton of huge pending patches that have prevented us from doing this in the past, post-freeze looks like a good time to finally do this. Mostly this will include the removal of underscores in private variables, and no more brace-on-newline policy. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-3649) Code style changes, aka The Big Reformat
[ https://issues.apache.org/jira/browse/CASSANDRA-3649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173234#comment-13173234 ] Sylvain Lebresne commented on CASSANDRA-3649: - We'll still incur some pain to every contributor that'll have a patch attached, even if that pain is as minor as going into some menu to change the style, or spending the 2 weeks after that refactor having every reviewer having to ask for a rebase of existing patches. My problem is that I don't see *any* benefits. Outside of course pleasing the aesthetic side of some, but that will be at the cost of annoying the one of others, including the ones that don't care one way or the other but will still have to rebase some patches. There is also something about applying some probably megabytes patch to a stable release, even if that's a trivial and generated one, that make me uneasy. But that's probably an unreasonable fear and maybe people-that-don't-care-about-brace-style-or-actually-prefer-brace-on-newlines is just a minority I happen to be part of. Code style changes, aka The Big Reformat Key: CASSANDRA-3649 URL: https://issues.apache.org/jira/browse/CASSANDRA-3649 Project: Cassandra Issue Type: Wish Components: Core Reporter: Brandon Williams Fix For: 1.2 With a new major release coming soon and not having a ton of huge pending patches that have prevented us from doing this in the past, post-freeze looks like a good time to finally do this. Mostly this will include the removal of underscores in private variables, and no more brace-on-newline policy. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-2893) Add row-level isolation
[ https://issues.apache.org/jira/browse/CASSANDRA-2893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-2893: Attachment: 0003-Add-AtomicSortedColumn-and-snapTree-v2.patch 0002-Make-memtable-use-CF.addAll-v2.patch 0001-Move-deletion-infos-into-ISortedColumns-v2.patch Rebased Add row-level isolation --- Key: CASSANDRA-2893 URL: https://issues.apache.org/jira/browse/CASSANDRA-2893 Project: Cassandra Issue Type: Improvement Reporter: Jonathan Ellis Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.1 Attachments: 0001-Move-deletion-infos-into-ISortedColumns-v2.patch, 0001-Move-deletion-infos-into-ISortedColumns.patch, 0002-Make-memtable-use-CF.addAll-v2.patch, 0002-Make-memtable-use-CF.addAll.patch, 0003-Add-AtomicSortedColumn-and-snapTree-v2.patch, 0003-Add-AtomicSortedColumn-and-snapTree.patch, snaptree-0.1-SNAPSHOT.jar This could be done using an the atomic ConcurrentMap operations from the Memtable and something like http://code.google.com/p/pcollections/ to replace the ConcurrentSkipListMap in ThreadSafeSortedColumns. The trick is that pcollections does not provide a SortedMap, so we probably need to write our own. Googling [persistent sortedmap] I found http://code.google.com/p/actord/source/browse/trunk/actord/src/main/scala/ff/collection (in scala) and http://clojure.org/data_structures#Data Structures-Maps. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2474) CQL support for compound columns
[
https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-2474:
--
Attachment: 2474-transposed-select-no-sparse.PNG
bq. I would say that 'sucking much less' doesn't necessarily make it 'the right
solution'.
This is more than sucking less. This is adapting exactly to the relational
philosophy that SQL is about sets of records and predicates that deal with
them, and how things are stored is an implementation detail. I don't see how
we can do better than this or something like it.
bq. Typically, you can do {{UPDATE test1 SET prop2 = 42 WHERE key = 'someKey'}}
but you cannot do the same [statement] on test2.
That's a good point, although I think the limitations are fairly easy to
explain, along with the effect on ordering.
bq. The SPARSE don't add any new possibility, it just adds a presumably better
syntax for a specific case.
Technically that is true, but that is akin to arguing that because PHP is
Turing complete it's as good as Java to write databases in. :)
Consider my timeline example. If we defined the table without SPARSE, as
{noformat}
CREATE TABLE timeline (
userid int primary key,
posted_at uuid,
column string,
value blob
) TRANSPOSED
{noformat}
The query {{SELECT * FROM timeline WHERE user_id = 'tjefferson' AND posted_at
1770}} would give us
!2474-transposed-select-no-sparse.PNG!
I don't see how this is usable in any reasonable sense of the word. Am I
missing something?
(And no, just model it with dense composites is not an option for the mview
use case, where adding new columns requires rebuilding the entire CF. That's a
big win for us, and I'm not willing to give it up.)
bq. I would actually be in favor of having the first step on this being the
addition of a very simple 'raw' notation to access composites.
I'm strongly against this or any row slicing notation, it's a terrible fit
for anything that wants to deal with resultsets of rows sharing a common set of
columns (i.e., CQL and its drivers). Unless this actually returns rows instead
of columns which is not at all implied by the syntax. Strongly against that
too. :)
CQL support for compound columns
Key: CASSANDRA-2474
URL: https://issues.apache.org/jira/browse/CASSANDRA-2474
Project: Cassandra
Issue Type: New Feature
Components: API, Core
Reporter: Eric Evans
Assignee: Pavel Yaskevich
Labels: cql
Fix For: 1.1
Attachments: 2474-transposed-1.PNG, 2474-transposed-raw.PNG,
2474-transposed-select-no-sparse.PNG, 2474-transposed-select.PNG,
raw_composite.txt, screenshot-1.jpg, screenshot-2.jpg
For the most part, this boils down to supporting the specification of
compound column names (the CQL syntax is colon-delimted terms), and then
teaching the decoders (drivers) to create structures from the results.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2474) CQL support for compound columns
[
https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173246#comment-13173246
]
Jonathan Ellis edited comment on CASSANDRA-2474 at 12/20/11 3:29 PM:
-
bq. I would say that 'sucking much less' doesn't necessarily make it 'the right
solution'.
This is more than sucking less. This is adapting exactly to the relational
philosophy that SQL is about sets of records and predicates that deal with
them, and how things are stored is an implementation detail. I don't see how
we can do better than this or something like it.
bq. Typically, you can do {{UPDATE test1 SET prop2 = 42 WHERE key = 'someKey'}}
but you cannot do the same [statement] on test2.
That's a good point, although I think the limitations are fairly easy to
explain, along with the effect on ordering.
bq. The SPARSE don't add any new possibility, it just adds a presumably better
syntax for a specific case.
Technically that is true, but that is akin to arguing that because PHP is
Turing complete it's as good as Java to write databases in. :)
Consider my timeline example. If we defined the table without SPARSE, as
{noformat}
CREATE TABLE timeline (
userid int primary key,
posted_at uuid,
column string,
value blob
) TRANSPOSED
{noformat}
The query {{SELECT * FROM timeline WHERE user_id = 'tjefferson' AND posted_at
1770}} would give us
!2474-transposed-select-no-sparse.PNG!
I don't see how this is usable in any reasonable sense of the word. Am I
missing something?
(Edit: it's actually worse than that, since you can't even use 'posted_at' in
the query. I've actually written SQL with dynamic columns like this and I
cannot overemphasize how badly it sucks.)
(And no, just model it with dense composites is not an option for the mview
use case, where adding new columns requires rebuilding the entire CF. That's a
big win for us, and I'm not willing to give it up.)
bq. I would actually be in favor of having the first step on this being the
addition of a very simple 'raw' notation to access composites.
I'm strongly against this or any row slicing notation, it's a terrible fit
for anything that wants to deal with resultsets of rows sharing a common set of
columns (i.e., CQL and its drivers). Unless this actually returns rows instead
of columns which is not at all implied by the syntax. Strongly against that
too. :)
was (Author: jbellis):
bq. I would say that 'sucking much less' doesn't necessarily make it 'the
right solution'.
This is more than sucking less. This is adapting exactly to the relational
philosophy that SQL is about sets of records and predicates that deal with
them, and how things are stored is an implementation detail. I don't see how
we can do better than this or something like it.
bq. Typically, you can do {{UPDATE test1 SET prop2 = 42 WHERE key = 'someKey'}}
but you cannot do the same [statement] on test2.
That's a good point, although I think the limitations are fairly easy to
explain, along with the effect on ordering.
bq. The SPARSE don't add any new possibility, it just adds a presumably better
syntax for a specific case.
Technically that is true, but that is akin to arguing that because PHP is
Turing complete it's as good as Java to write databases in. :)
Consider my timeline example. If we defined the table without SPARSE, as
{noformat}
CREATE TABLE timeline (
userid int primary key,
posted_at uuid,
column string,
value blob
) TRANSPOSED
{noformat}
The query {{SELECT * FROM timeline WHERE user_id = 'tjefferson' AND posted_at
1770}} would give us
!2474-transposed-select-no-sparse.PNG!
I don't see how this is usable in any reasonable sense of the word. Am I
missing something?
(And no, just model it with dense composites is not an option for the mview
use case, where adding new columns requires rebuilding the entire CF. That's a
big win for us, and I'm not willing to give it up.)
bq. I would actually be in favor of having the first step on this being the
addition of a very simple 'raw' notation to access composites.
I'm strongly against this or any row slicing notation, it's a terrible fit
for anything that wants to deal with resultsets of rows sharing a common set of
columns (i.e., CQL and its drivers). Unless this actually returns rows instead
of columns which is not at all implied by the syntax. Strongly against that
too. :)
CQL support for compound columns
Key: CASSANDRA-2474
URL: https://issues.apache.org/jira/browse/CASSANDRA-2474
Project: Cassandra
Issue Type: New Feature
Components: API, Core
Reporter: Eric Evans
Assignee: Pavel Yaskevich
Labels: cql
Fix For: 1.1
[jira] [Commented] (CASSANDRA-3649) Code style changes, aka The Big Reformat
[ https://issues.apache.org/jira/browse/CASSANDRA-3649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173250#comment-13173250 ] Jonathan Ellis commented on CASSANDRA-3649: --- bq. My problem is that I don't see *any* benefits You don't spend enough time on a laptop or small monitor, then. Losing 20% of vertical space to brace-on-newline is a real barrier to my productivity on a daily basis. Code style changes, aka The Big Reformat Key: CASSANDRA-3649 URL: https://issues.apache.org/jira/browse/CASSANDRA-3649 Project: Cassandra Issue Type: Wish Components: Core Reporter: Brandon Williams Fix For: 1.2 With a new major release coming soon and not having a ton of huge pending patches that have prevented us from doing this in the past, post-freeze looks like a good time to finally do this. Mostly this will include the removal of underscores in private variables, and no more brace-on-newline policy. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-3452) Create an 'infinite bootstrap' mode for sampling live traffic
[ https://issues.apache.org/jira/browse/CASSANDRA-3452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-3452: Attachment: 0002-Allow-survey-only-mode-after-bootstrapping.txt 0001-Ability-to-set-compaction-strategy-via-mbean.txt Patch to create a write survey mode enabled via -Dcassandra.write_survey=true, where the node will bootstrap as usual but NOT join the ring unless SS.joinRing is called later (as you would with cassandra.join_ring=false. Also a patch jmx-enable the setting of the compaction strategy on a CF so these are more useful as a whole. Create an 'infinite bootstrap' mode for sampling live traffic - Key: CASSANDRA-3452 URL: https://issues.apache.org/jira/browse/CASSANDRA-3452 Project: Cassandra Issue Type: New Feature Reporter: Brandon Williams Assignee: Brandon Williams Attachments: 0001-Ability-to-set-compaction-strategy-via-mbean.txt, 0002-Allow-survey-only-mode-after-bootstrapping.txt You may want to, for example, test a new compaction strategy with live traffic to see how it will fare. In this mode, the node would follow the bootstrap procedure as normal, but never fully join the ring. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3649) Code style changes, aka The Big Reformat
[ https://issues.apache.org/jira/browse/CASSANDRA-3649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173261#comment-13173261 ] Eric Evans commented on CASSANDRA-3649: --- OCD (and low-res displays) notwithstanding, this change is going to Suck. Mightily. Just saying. Code style changes, aka The Big Reformat Key: CASSANDRA-3649 URL: https://issues.apache.org/jira/browse/CASSANDRA-3649 Project: Cassandra Issue Type: Wish Components: Core Reporter: Brandon Williams Fix For: 1.2 With a new major release coming soon and not having a ton of huge pending patches that have prevented us from doing this in the past, post-freeze looks like a good time to finally do this. Mostly this will include the removal of underscores in private variables, and no more brace-on-newline policy. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-3649) Code style changes, aka The Big Reformat
[ https://issues.apache.org/jira/browse/CASSANDRA-3649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173264#comment-13173264 ] T Jake Luciani commented on CASSANDRA-3649: --- bq. My problem is that I don't see any benefits maintaining a custom codestyle just for cassandra sucks. If we simply adopted java standard then new contributors and people who work on multiple java projects don't need to worry about codestyle since it's the default. Code style changes, aka The Big Reformat Key: CASSANDRA-3649 URL: https://issues.apache.org/jira/browse/CASSANDRA-3649 Project: Cassandra Issue Type: Wish Components: Core Reporter: Brandon Williams Fix For: 1.2 With a new major release coming soon and not having a ton of huge pending patches that have prevented us from doing this in the past, post-freeze looks like a good time to finally do this. Mostly this will include the removal of underscores in private variables, and no more brace-on-newline policy. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-2474) CQL support for compound columns
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173278#comment-13173278 ] Sylvain Lebresne commented on CASSANDRA-2474: - bq. This is adapting exactly to the relational philosophy that SQL is about sets of records and predicates that deal with them I suppose this sums up my objections and why I can't get myself to be fully convinced by those propositions. I had though at first that the goal of CQL was to use a query language because this was making it much more easy to make it evolve without breaking clients (and why not a syntax close to SQL as long as it doesn't constrain us in any way -- though that was fishy from the start). But I didn't though the goal was to 'adapt to the relational philosophy'. I don't like that idea (for a number of reasons but it's not the place for those), I think we are impoverishing Cassandra going this road, and truth is, it's not the first time I've had a bad feeling about this. But it's very possible that fitting to the relational philosophy is good for adoption, and that it's the best solution for CQL at this point (I should probably have cared for CQL and object to it sooner anyway), so ranting being made, I'll shut up and try to first embrace the relational philosophy to hopefully make more constructive criticisms :) CQL support for compound columns Key: CASSANDRA-2474 URL: https://issues.apache.org/jira/browse/CASSANDRA-2474 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Eric Evans Assignee: Pavel Yaskevich Labels: cql Fix For: 1.1 Attachments: 2474-transposed-1.PNG, 2474-transposed-raw.PNG, 2474-transposed-select-no-sparse.PNG, 2474-transposed-select.PNG, raw_composite.txt, screenshot-1.jpg, screenshot-2.jpg For the most part, this boils down to supporting the specification of compound column names (the CQL syntax is colon-delimted terms), and then teaching the decoders (drivers) to create structures from the results. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-3649) Code style changes, aka The Big Reformat
[ https://issues.apache.org/jira/browse/CASSANDRA-3649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173275#comment-13173275 ] Jonathan Ellis commented on CASSANDRA-3649: --- bq. If we simply adopted java standard then new contributors and people who work on multiple java projects don't need to worry about codestyle since it's the default. Changing brace policy will help, but it won't be a magic bullet. Partly because we have other idiosyncracies, such as alignment of multiline method arguments (which I think is a *huge* improvement over the Oracle standard) and partly because many people who think they are following Oracle style, don't. Especially with respect to spacing around parenthesis and operators. Code style changes, aka The Big Reformat Key: CASSANDRA-3649 URL: https://issues.apache.org/jira/browse/CASSANDRA-3649 Project: Cassandra Issue Type: Wish Components: Core Reporter: Brandon Williams Fix For: 1.2 With a new major release coming soon and not having a ton of huge pending patches that have prevented us from doing this in the past, post-freeze looks like a good time to finally do this. Mostly this will include the removal of underscores in private variables, and no more brace-on-newline policy. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-3571) make stream throttling configurable at runtime with nodetool
[ https://issues.apache.org/jira/browse/CASSANDRA-3571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173291#comment-13173291 ] Yuki Morishita commented on CASSANDRA-3571: --- +1 make stream throttling configurable at runtime with nodetool Key: CASSANDRA-3571 URL: https://issues.apache.org/jira/browse/CASSANDRA-3571 Project: Cassandra Issue Type: Improvement Reporter: Peter Schuller Assignee: Peter Schuller Priority: Minor Attachments: CASSANDRA-3571-1.0-rebased-v2.txt, CASSANDRA-3571-1.0-rebased.txt, CASSANDRA-3571-1.0.txt Attaching patch that does this, against 1.0. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-3559) CFMetaData conversions to Thrift/Avro should probably be inverse one of the other
[
https://issues.apache.org/jira/browse/CASSANDRA-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173290#comment-13173290
]
Pavel Yaskevich commented on CASSANDRA-3559:
CASSANDRA-1391 is also scheduled for 1.1 and it will remove all {to/from}Avro()
methods
CFMetaData conversions to Thrift/Avro should probably be inverse one of the
other
-
Key: CASSANDRA-3559
URL: https://issues.apache.org/jira/browse/CASSANDRA-3559
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
Labels: avro, thrift
Fix For: 1.1
Attachments: 3559.patch
In other word, it would probably be a idea to have:
{noformat}
cfm == CFMetadata.fromThrift(cfm.toThrift())
cfm == CFMetadata.fromAvro(cfm.toAvro())
{noformat}
In particular, we could have unit tests to check that, which would avoid
things like CASSANDRA-3558.
It is not the case today for thrift because of the keyAlias. For some reason,
if the keyAlias is not set, we return with toThrift() the default alias. I
don't think this serves any purpose though.
The goal of this ticket is to both fix that (unless there is a compelling
reason not to) and add unit tests for this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns
[
https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173294#comment-13173294
]
T Jake Luciani commented on CASSANDRA-2474:
---
One possibility that could avoid SPARSE/DENSE syntax would be:
{code:sql}
--DENSE transposed format
--column names are used directly in comparator
CREATE TABLE msg (
user text primary key,
sender text,
thread text,
tid int,
bodytext
)
WITH comparator = composite(sender,thread,tid);
{code}
{code:sql}
--SPARSE transposed format
--composite comparator with no specified columns will be a dynamic comparator
--and includes the column name as part of the dynamic column name
CREATE TABLE msg (
user text primary key,
sender text,
thread text,
tid int,
body text
)
WITH comparator = composite;
{code}
{code:sql}
--Finally in the case of both SPARSE/DENSE
CREATE TABLE timeline (
userid int primary key,
posted_at uuid,
column string,
value blob
)
WITH comparator = composite(posted_at,*);
{code}
CQL support for compound columns
Key: CASSANDRA-2474
URL: https://issues.apache.org/jira/browse/CASSANDRA-2474
Project: Cassandra
Issue Type: New Feature
Components: API, Core
Reporter: Eric Evans
Assignee: Pavel Yaskevich
Labels: cql
Fix For: 1.1
Attachments: 2474-transposed-1.PNG, 2474-transposed-raw.PNG,
2474-transposed-select-no-sparse.PNG, 2474-transposed-select.PNG,
raw_composite.txt, screenshot-1.jpg, screenshot-2.jpg
For the most part, this boils down to supporting the specification of
compound column names (the CQL syntax is colon-delimted terms), and then
teaching the decoders (drivers) to create structures from the results.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-3559) CFMetaData conversions to Thrift/Avro should probably be inverse one of the other
[
https://issues.apache.org/jira/browse/CASSANDRA-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173300#comment-13173300
]
Sylvain Lebresne commented on CASSANDRA-3559:
-
True. I'm fine waiting to see if it makes it for 1.1 and close that one if so.
CFMetaData conversions to Thrift/Avro should probably be inverse one of the
other
-
Key: CASSANDRA-3559
URL: https://issues.apache.org/jira/browse/CASSANDRA-3559
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
Labels: avro, thrift
Fix For: 1.1
Attachments: 3559.patch
In other word, it would probably be a idea to have:
{noformat}
cfm == CFMetadata.fromThrift(cfm.toThrift())
cfm == CFMetadata.fromAvro(cfm.toAvro())
{noformat}
In particular, we could have unit tests to check that, which would avoid
things like CASSANDRA-3558.
It is not the case today for thrift because of the keyAlias. For some reason,
if the keyAlias is not set, we return with toThrift() the default alias. I
don't think this serves any purpose though.
The goal of this ticket is to both fix that (unless there is a compelling
reason not to) and add unit tests for this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3424) Selecting just the row_key returns nil instead of just the row_key
[
https://issues.apache.org/jira/browse/CASSANDRA-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173306#comment-13173306
]
Eric Evans commented on CASSANDRA-3424:
---
This change didn't do what it was supposed to, and it introduced a breaking CQL
change, (which has since made it into stable release updates(!)). If we'd have
caught this before it was rolled into a release, I'd say it warranted an
immediate -1 and a revert.
We haven't been doing nearly as well as I'd hoped in keeping stability
promises, but I might be satisfied to call the original behavior buggy, and the
intended behavior of this change as the fix, if it could be made to work the
way intended (to return the result _if_ the row exists). Can anyone see a way
to accomplish that?
Selecting just the row_key returns nil instead of just the row_key
--
Key: CASSANDRA-3424
URL: https://issues.apache.org/jira/browse/CASSANDRA-3424
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.0
Reporter: Kelley Reynolds
Assignee: Jonathan Ellis
Priority: Minor
Labels: cql
Fix For: 1.0.3
Attachments: 3424-v2.txt, CASSANDRA-3424.patch
CREATE KEYSPACE CassandraCQLTestKeyspace WITH
strategy_class='org.apache.cassandra.locator.SimpleStrategy' AND
strategy_options:replication_factor=1
USE CassandraCQLTestKeyspace
CREATE COLUMNFAMILY row_key_validation_cf_ascii (id ascii PRIMARY KEY,
test_column text)
INSERT INTO row_key_validation_cf_ascii (id, test_column) VALUES ('test
string', 'test')
# Works as expected
SELECT * FROM row_key_validation_cf_ascii WHERE id = 'test string'
# Returns an empty result, unexpected
SELECT id FROM row_key_validation_cf_ascii WHERE id = 'test string'
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-3143) Global caches (key/row)
[ https://issues.apache.org/jira/browse/CASSANDRA-3143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173317#comment-13173317 ] Sylvain Lebresne commented on CASSANDRA-3143: - A few comments after quickly reading through the last patches: * CacheKey could have a serializeSize() method for use rather needlessly creating ByteBuffers just to get there size in estimateSizeToSave. * CacheKey.serialize() is unused. * Since that for saving each cache, we do n+1 iterations through the whole cache where n is the number of column families. It seems rather inefficient, we could probably write all caches (for all CFs) simultaneously for a more efficient process. * When reading the cache, it seems we decorate each key just to validate saved data (we discard the DK object afterwards). But I don't think decorating a key entails any kind of validation of the key so this feel useless. * Do we care about reloading the row cache? Jonathan was right that reloading a cache is probably pretty useless. Global caches (key/row) --- Key: CASSANDRA-3143 URL: https://issues.apache.org/jira/browse/CASSANDRA-3143 Project: Cassandra Issue Type: Improvement Reporter: Pavel Yaskevich Assignee: Pavel Yaskevich Priority: Minor Labels: Core Fix For: 1.1 Attachments: 0001-global-key-cache.patch, 0002-global-row-cache-and-ASC.readSaved-changed-to-abstra.patch, 0003-CacheServiceMBean-and-correct-key-cache-loading.patch, 0004-key-row-cache-tests-and-tweaks.patch, 0005-cleanup-of-the-CFMetaData-and-thrift-avro-CfDef-and-.patch, 0006-row-key-cache-improvements-according-to-Sylvain-s-co.patch, 0007-caches-made-backward-compatible-second-round-of-chan.patch, 0008-row-key-cache-to-use-raw-key-instead-of-decorated.patch Caches are difficult to configure well as ColumnFamilies are added, similar to how memtables were difficult pre-CASSANDRA-2006. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-3143) Global caches (key/row)
[ https://issues.apache.org/jira/browse/CASSANDRA-3143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173331#comment-13173331 ] Pavel Yaskevich commented on CASSANDRA-3143: bq. Since that for saving each cache, we do n+1 iterations through the whole cache where n is the number of column families. It seems rather inefficient, we could probably write all caches (for all CFs) simultaneously for a more efficient process. I was thinking about that - it would require to keep all of the files open, do we want that? bq. Do we care about reloading the row cache? Jonathan was right that reloading a cache is probably pretty useless. Ok, lets just drop it completely then. Global caches (key/row) --- Key: CASSANDRA-3143 URL: https://issues.apache.org/jira/browse/CASSANDRA-3143 Project: Cassandra Issue Type: Improvement Reporter: Pavel Yaskevich Assignee: Pavel Yaskevich Priority: Minor Labels: Core Fix For: 1.1 Attachments: 0001-global-key-cache.patch, 0002-global-row-cache-and-ASC.readSaved-changed-to-abstra.patch, 0003-CacheServiceMBean-and-correct-key-cache-loading.patch, 0004-key-row-cache-tests-and-tweaks.patch, 0005-cleanup-of-the-CFMetaData-and-thrift-avro-CfDef-and-.patch, 0006-row-key-cache-improvements-according-to-Sylvain-s-co.patch, 0007-caches-made-backward-compatible-second-round-of-chan.patch, 0008-row-key-cache-to-use-raw-key-instead-of-decorated.patch Caches are difficult to configure well as ColumnFamilies are added, similar to how memtables were difficult pre-CASSANDRA-2006. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-3579) AssertionError in hintedhandoff - 1.0.5
[ https://issues.apache.org/jira/browse/CASSANDRA-3579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173334#comment-13173334 ] Terry Cumaranatunge commented on CASSANDRA-3579: I ran into this problem as well. I don't know if it is related, but I started to see Gossip errors for the node being down and up constantly even when I'm not writing to Cassandra. Restarting Cassandra fixed the problem. INFO [CompactionExecutor:648] 2011-12-19 20:41:17,399 CompactionController.java (line 133) Compacting large row system/HintsColumnFamily: 7770 (73427721 bytes) incrementally INFO [FlushWriter:99] 2011-12-19 20:41:17,410 Memtable.java (line 275) Completed flushing /data/data/system/HintsColumnFamily-hb-141-Data .db (3022 bytes) ERROR [CompactionExecutor:648] 2011-12-19 20:41:19,445 AbstractCassandraDaemon.java (line 133) Fatal exception in thread Thread[Compaction Executor:648,1,main] java.lang.AssertionError: originally calculated column size of 66102951 but now it is 66009419 at org.apache.cassandra.db.compaction.LazilyCompactedRow.write(LazilyCompactedRow.java:124) at org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:160) at org.apache.cassandra.db.compaction.CompactionTask.execute(CompactionTask.java:158) at org.apache.cassandra.db.compaction.CompactionManager$6.call(CompactionManager.java:275) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) ERROR [HintedHandoff:1] 2011-12-19 20:41:19,445 AbstractCassandraDaemon.java (line 133) Fatal exception in thread Thread[HintedHandoff:1,1 ,main] java.lang.RuntimeException: java.lang.RuntimeException: java.util.concurrent.ExecutionException: java.lang.AssertionError: originally calc ulated column size of 66102951 but now it is 66009419 at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:34) 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.lang.RuntimeException: java.util.concurrent.ExecutionException: java.lang.AssertionError: originally calculated column siz e of 66102951 but now it is 66009419 at org.apache.cassandra.db.HintedHandOffManager.deliverHintsToEndpoint(HintedHandOffManager.java:330) at org.apache.cassandra.db.HintedHandOffManager.access$100(HintedHandOffManager.java:81) at org.apache.cassandra.db.HintedHandOffManager.access$100(HintedHandOffManager.java:81) at org.apache.cassandra.db.HintedHandOffManager$2.runMayThrow(HintedHandOffManager.java:353) at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30) ... 3 more Caused by: java.util.concurrent.ExecutionException: java.lang.AssertionError: originally calculated column size of 66102951 but now it is66009419 at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222) at java.util.concurrent.FutureTask.get(FutureTask.java:83) at org.apache.cassandra.db.HintedHandOffManager.deliverHintsToEndpoint(HintedHandOffManager.java:326) ... 6 more Caused by: java.lang.AssertionError: originally calculated column size of 66102951 but now it is 66009419 at org.apache.cassandra.db.compaction.LazilyCompactedRow.write(LazilyCompactedRow.java:124) at org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:160) at org.apache.cassandra.db.compaction.CompactionTask.execute(CompactionTask.java:158) at org.apache.cassandra.db.compaction.CompactionManager$6.call(CompactionManager.java:275) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) ... 3 more AssertionError in hintedhandoff - 1.0.5 --- Key: CASSANDRA-3579 URL: https://issues.apache.org/jira/browse/CASSANDRA-3579 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.5 Environment: RHEL 6.1 64 bit, 32 GB RAM, 8 GB allocated to JVM, running XFS filesystem for commit/data directories Reporter: Ramesh Natarajan Fix For: 1.0.7 We are running a 8 node cassandra cluster running cassandra 1.0.5. All our CF use leveled compaction. We ran a test where we did a lot of inserts for 3
[jira] [Commented] (CASSANDRA-3511) Supercolumn key caches are not saved
[ https://issues.apache.org/jira/browse/CASSANDRA-3511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173338#comment-13173338 ] Radim Kolar commented on CASSANDRA-3511: ponto:(filezco)~/cassandrash cass-test [default@unknown] drop keyspace Keyspace1; 3c8015f0-2b2f-11e1--d14dd490cdfc Waiting for schema agreement... ... schemas agree across the cluster [default@unknown] Connected to: Prod on localhost/9160 Unable to create stress keyspace: Keyspace names must be case-insensitively unique (Keyspace1 conflicts with Keyspace1) total,interval_op_rate,interval_key_rate,avg_latency,elapsed_time 116911,11691,11691,0.003197124308234469,10 216552,9964,9964,0.0021934344296022723,20 361227,14467,14467,0.004738966649386556,30 436233,7500,7500,0.006396488280937525,40 50,6376,6376,0.0019556510420750545,43 END total,interval_op_rate,interval_key_rate,avg_latency,elapsed_time 51781,5178,5178,0.008967517042930804,10 198084,14630,14630,0.003021592175143367,20 365241,16715,16715,0.002720592018282214,30 50,13475,13475,0.002616522829644031,38 END Key cache size: 109093 Row cache size: 600 I will wait if keycache will be saved Supercolumn key caches are not saved Key: CASSANDRA-3511 URL: https://issues.apache.org/jira/browse/CASSANDRA-3511 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.2, 1.0.3 Reporter: Radim Kolar Priority: Minor Labels: supercolumns Attachments: failed-to-save-after-load-KeyCache, rapidshare-resultcache-KeyCache cache saving seems to be broken in 1.0.2 and 1.0.3 i have 2 CF in keyspace with enabled cache saving and only one gets its key cache saved. It worked perfectly in 0.8, both were saved. This one works: create column family query2 with column_type = 'Standard' and comparator = 'AsciiType' and default_validation_class = 'BytesType' and key_validation_class = 'UTF8Type' and rows_cached = 500.0 and row_cache_save_period = 0 and row_cache_keys_to_save = 2147483647 and keys_cached = 20.0 and key_cache_save_period = 14400 and read_repair_chance = 1.0 and gc_grace = 864000 and min_compaction_threshold = 5 and max_compaction_threshold = 10 and replicate_on_write = false and row_cache_provider = 'ConcurrentLinkedHashCacheProvider' and compaction_strategy = 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy' This does not create column family dkb13 with column_type = 'Super' and comparator = 'LongType' and subcomparator = 'AsciiType' and default_validation_class = 'BytesType' and key_validation_class = 'UTF8Type' and rows_cached = 600.0 and row_cache_save_period = 0 and row_cache_keys_to_save = 2147483647 and keys_cached = 20.0 and key_cache_save_period = 14400 and read_repair_chance = 1.0 and gc_grace = 864000 and min_compaction_threshold = 5 and max_compaction_threshold = 10 and replicate_on_write = false and row_cache_provider = 'ConcurrentLinkedHashCacheProvider' and compaction_strategy = 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy' in second test system i created these 2 column families and none of them got single cache key saved. Both have save period 30 seoonds - their cache should save often. Its not that standard column family works while super does not. create column family test1 with column_type = 'Standard' and comparator = 'BytesType' and default_validation_class = 'BytesType' and key_validation_class = 'BytesType' and rows_cached = 0.0 and row_cache_save_period = 0 and row_cache_keys_to_save = 2147483647 and keys_cached = 20.0 and key_cache_save_period = 30 and read_repair_chance = 1.0 and gc_grace = 864000 and min_compaction_threshold = 4 and max_compaction_threshold = 32 and replicate_on_write = true and row_cache_provider = 'SerializingCacheProvider' and compaction_strategy = 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'; create column family test2 with column_type = 'Standard' and comparator = 'BytesType' and default_validation_class = 'BytesType' and key_validation_class = 'BytesType' and rows_cached = 0.0 and row_cache_save_period = 0 and row_cache_keys_to_save = 2147483647 and keys_cached = 20.0 and key_cache_save_period = 30 and read_repair_chance = 1.0 and gc_grace = 864000 and min_compaction_threshold = 4 and max_compaction_threshold = 32 and replicate_on_write = true and row_cache_provider = 'SerializingCacheProvider' and compaction_strategy = 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'; If this is done on purpose for example cassandra 1.0 is
[jira] [Commented] (CASSANDRA-3143) Global caches (key/row)
[ https://issues.apache.org/jira/browse/CASSANDRA-3143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173349#comment-13173349 ] Sylvain Lebresne commented on CASSANDRA-3143: - bq. I was thinking about that - it would require to keep all of the files open, do we want that? Is that a big deal? I suppose if you have 1000 CFs it's starting to be a big number of fds open, but even then it doesn't sound like such a big deal, especially given it's for a very short time. Or did you had other concerns in mind? Global caches (key/row) --- Key: CASSANDRA-3143 URL: https://issues.apache.org/jira/browse/CASSANDRA-3143 Project: Cassandra Issue Type: Improvement Reporter: Pavel Yaskevich Assignee: Pavel Yaskevich Priority: Minor Labels: Core Fix For: 1.1 Attachments: 0001-global-key-cache.patch, 0002-global-row-cache-and-ASC.readSaved-changed-to-abstra.patch, 0003-CacheServiceMBean-and-correct-key-cache-loading.patch, 0004-key-row-cache-tests-and-tweaks.patch, 0005-cleanup-of-the-CFMetaData-and-thrift-avro-CfDef-and-.patch, 0006-row-key-cache-improvements-according-to-Sylvain-s-co.patch, 0007-caches-made-backward-compatible-second-round-of-chan.patch, 0008-row-key-cache-to-use-raw-key-instead-of-decorated.patch Caches are difficult to configure well as ColumnFamilies are added, similar to how memtables were difficult pre-CASSANDRA-2006. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-3143) Global caches (key/row)
[ https://issues.apache.org/jira/browse/CASSANDRA-3143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173353#comment-13173353 ] Pavel Yaskevich commented on CASSANDRA-3143: If you say so, I was just concerned about additional amount of fds open. Will change that in upcoming patch #9. Global caches (key/row) --- Key: CASSANDRA-3143 URL: https://issues.apache.org/jira/browse/CASSANDRA-3143 Project: Cassandra Issue Type: Improvement Reporter: Pavel Yaskevich Assignee: Pavel Yaskevich Priority: Minor Labels: Core Fix For: 1.1 Attachments: 0001-global-key-cache.patch, 0002-global-row-cache-and-ASC.readSaved-changed-to-abstra.patch, 0003-CacheServiceMBean-and-correct-key-cache-loading.patch, 0004-key-row-cache-tests-and-tweaks.patch, 0005-cleanup-of-the-CFMetaData-and-thrift-avro-CfDef-and-.patch, 0006-row-key-cache-improvements-according-to-Sylvain-s-co.patch, 0007-caches-made-backward-compatible-second-round-of-chan.patch, 0008-row-key-cache-to-use-raw-key-instead-of-decorated.patch Caches are difficult to configure well as ColumnFamilies are added, similar to how memtables were difficult pre-CASSANDRA-2006. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-3143) Global caches (key/row)
[ https://issues.apache.org/jira/browse/CASSANDRA-3143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173361#comment-13173361 ] Pavel Yaskevich commented on CASSANDRA-3143: bq. When reading the cache, it seems we decorate each key just to validate saved data (we discard the DK object afterwards). But I don't think decorating a key entails any kind of validation of the key so this feel useless. We need a DecoratedKey there for key cache as SSTableReader operates on the DecoratedKey instances in load method. Global caches (key/row) --- Key: CASSANDRA-3143 URL: https://issues.apache.org/jira/browse/CASSANDRA-3143 Project: Cassandra Issue Type: Improvement Reporter: Pavel Yaskevich Assignee: Pavel Yaskevich Priority: Minor Labels: Core Fix For: 1.1 Attachments: 0001-global-key-cache.patch, 0002-global-row-cache-and-ASC.readSaved-changed-to-abstra.patch, 0003-CacheServiceMBean-and-correct-key-cache-loading.patch, 0004-key-row-cache-tests-and-tweaks.patch, 0005-cleanup-of-the-CFMetaData-and-thrift-avro-CfDef-and-.patch, 0006-row-key-cache-improvements-according-to-Sylvain-s-co.patch, 0007-caches-made-backward-compatible-second-round-of-chan.patch, 0008-row-key-cache-to-use-raw-key-instead-of-decorated.patch Caches are difficult to configure well as ColumnFamilies are added, similar to how memtables were difficult pre-CASSANDRA-2006. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-3623) use MMapedBuffer in CompressedSegmentedFile.getSegment
[ https://issues.apache.org/jira/browse/CASSANDRA-3623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173365#comment-13173365 ] Vijay commented on CASSANDRA-3623: -- This gets complicated because the rows boundary is not the chunk boundary, I tried to map more blocks than needed for a given boundary but there is a possibility of running out of memory, hence i am planning to do the following: Make boundaries for the chunk instead of the row position Chunks between the boundaries will over-lap. use MMapedBuffer in CompressedSegmentedFile.getSegment -- Key: CASSANDRA-3623 URL: https://issues.apache.org/jira/browse/CASSANDRA-3623 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.1 Reporter: Vijay Assignee: Vijay Fix For: 1.1 CompressedSegmentedFile.getSegment seem to open a new file and doesnt seem to use the MMap and hence a higher CPU on the nodes and higher latencies on reads. This ticket is to implement the TODO mentioned in CompressedRandomAccessReader // TODO refactor this to separate concept of buffer to avoid lots of read() syscalls and compression buffer but i think a separate class for the Buffer will be better. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-3610) Checksum improvement for CompressedRandomAccessReader
[ https://issues.apache.org/jira/browse/CASSANDRA-3610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vijay updated CASSANDRA-3610: - Attachment: 0001-use-pure-java-CRC32-v2.patch Attached is the patch for CRC32 without the dependency of Hadoop. Checksum improvement for CompressedRandomAccessReader - Key: CASSANDRA-3610 URL: https://issues.apache.org/jira/browse/CASSANDRA-3610 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.1 Environment: JVM Reporter: Vijay Assignee: Vijay Priority: Minor Fix For: 1.1 Attachments: 0001-use-pure-java-CRC32-v2.patch, 0001-use-pure-java-CRC32.patch When compression is on, Currently we see checksum taking up about 40% of the CPU more than snappy library. Looks like hadoop solved it by implementing their own checksum, we can either use it or implement something like that. http://images.slidesharecdn.com/1toddlipconyanpeichen-cloudera-hadoopandperformance-final-10132228-phpapp01-slide-15-768.jpg?1321043717 in our test env it provided 50% improvement over native implementation which uses jni to call the OS. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-3653) cqlsh cant select from super CF
cqlsh cant select from super CF --- Key: CASSANDRA-3653 URL: https://issues.apache.org/jira/browse/CASSANDRA-3653 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.0.6 Environment: Cassandra 1.0.6 Reporter: Radim Kolar Priority: Minor Selecting from Super CF returns error cqlsh:Keyspace1 select * from Keyspace1.Super1 limit 10; Internal application error cqlsh:Keyspace1 describe columnfamily Super1; CREATE COLUMNFAMILY Super1 ( KEY text PRIMARY KEY, crc32 bigint, id bigint, name ascii, size bigint ) WITH comment='' AND comparator=ascii AND row_cache_provider='ConcurrentLinkedHashCacheProvider' AND key_cache_size=20.00 AND row_cache_size=600.00 AND read_repair_chance=1.00 AND gc_grace_seconds=864000 AND default_validation=blob AND min_compaction_threshold=5 AND max_compaction_threshold=10 AND row_cache_save_period_in_seconds=0 AND key_cache_save_period_in_seconds=14400 AND replicate_on_write=False; -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3335) ThreadPoolExecutor creates threads as non-daemon and will block on shutdown by default
[ https://issues.apache.org/jira/browse/CASSANDRA-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173417#comment-13173417 ] Brandon Williams commented on CASSANDRA-3335: - +1 ThreadPoolExecutor creates threads as non-daemon and will block on shutdown by default -- Key: CASSANDRA-3335 URL: https://issues.apache.org/jira/browse/CASSANDRA-3335 Project: Cassandra Issue Type: Bug Components: Core Reporter: Brandon Williams Assignee: Jonathan Ellis Priority: Minor Fix For: 1.0.7 Attachments: 3335-v2.txt, 3335-v3.txt, 3335-v4.txt, 3335.txt, 3335v3_jstack.txt This is most obviously visible in OptionalTasks which should not block shutdown, but often does. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3424) Selecting just the row_key returns nil instead of just the row_key
[
https://issues.apache.org/jira/browse/CASSANDRA-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173427#comment-13173427
]
Jonathan Ellis commented on CASSANDRA-3424:
---
bq. This change didn't do what it was supposed to
To be clear, it *did* fix the reported problem, of rows not being returned when
they *did* exist. Of course, now we have the opposite problem, as reported in
CASSANDRA-3505.
Selecting just the row_key returns nil instead of just the row_key
--
Key: CASSANDRA-3424
URL: https://issues.apache.org/jira/browse/CASSANDRA-3424
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.0
Reporter: Kelley Reynolds
Assignee: Jonathan Ellis
Priority: Minor
Labels: cql
Fix For: 1.0.3
Attachments: 3424-v2.txt, CASSANDRA-3424.patch
CREATE KEYSPACE CassandraCQLTestKeyspace WITH
strategy_class='org.apache.cassandra.locator.SimpleStrategy' AND
strategy_options:replication_factor=1
USE CassandraCQLTestKeyspace
CREATE COLUMNFAMILY row_key_validation_cf_ascii (id ascii PRIMARY KEY,
test_column text)
INSERT INTO row_key_validation_cf_ascii (id, test_column) VALUES ('test
string', 'test')
# Works as expected
SELECT * FROM row_key_validation_cf_ascii WHERE id = 'test string'
# Returns an empty result, unexpected
SELECT id FROM row_key_validation_cf_ascii WHERE id = 'test string'
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-3424) Selecting just the row_key returns nil instead of just the row_key
[
https://issues.apache.org/jira/browse/CASSANDRA-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173432#comment-13173432
]
Pavel Yaskevich commented on CASSANDRA-3424:
I doesn't seem possible to distinguish between existing and non-existant keys
currently, would it be the good idea to revert this one? Or just close it and
move all discussion to CASSANDRA-3505?
Selecting just the row_key returns nil instead of just the row_key
--
Key: CASSANDRA-3424
URL: https://issues.apache.org/jira/browse/CASSANDRA-3424
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.0
Reporter: Kelley Reynolds
Assignee: Jonathan Ellis
Priority: Minor
Labels: cql
Fix For: 1.0.3
Attachments: 3424-v2.txt, CASSANDRA-3424.patch
CREATE KEYSPACE CassandraCQLTestKeyspace WITH
strategy_class='org.apache.cassandra.locator.SimpleStrategy' AND
strategy_options:replication_factor=1
USE CassandraCQLTestKeyspace
CREATE COLUMNFAMILY row_key_validation_cf_ascii (id ascii PRIMARY KEY,
test_column text)
INSERT INTO row_key_validation_cf_ascii (id, test_column) VALUES ('test
string', 'test')
# Works as expected
SELECT * FROM row_key_validation_cf_ascii WHERE id = 'test string'
# Returns an empty result, unexpected
SELECT id FROM row_key_validation_cf_ascii WHERE id = 'test string'
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-3610) Checksum improvement for CompressedRandomAccessReader
[ https://issues.apache.org/jira/browse/CASSANDRA-3610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173434#comment-13173434 ] Jonathan Ellis commented on CASSANDRA-3610: --- Didn't the Hadoop guys benchmark zip.CRC32 as being faster for 32 bytes? Checksum improvement for CompressedRandomAccessReader - Key: CASSANDRA-3610 URL: https://issues.apache.org/jira/browse/CASSANDRA-3610 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.1 Environment: JVM Reporter: Vijay Assignee: Vijay Priority: Minor Fix For: 1.1 Attachments: 0001-use-pure-java-CRC32-v2.patch, 0001-use-pure-java-CRC32.patch When compression is on, Currently we see checksum taking up about 40% of the CPU more than snappy library. Looks like hadoop solved it by implementing their own checksum, we can either use it or implement something like that. http://images.slidesharecdn.com/1toddlipconyanpeichen-cloudera-hadoopandperformance-final-10132228-phpapp01-slide-15-768.jpg?1321043717 in our test env it provided 50% improvement over native implementation which uses jni to call the OS. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-3653) cqlsh cant select from super CF
[ https://issues.apache.org/jira/browse/CASSANDRA-3653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-3653. --- Resolution: Not A Problem CQL does not support supercolumns, and won't until at least CASSANDRA-2474. (Which is really targetted at composites, so I say at least.) cqlsh cant select from super CF --- Key: CASSANDRA-3653 URL: https://issues.apache.org/jira/browse/CASSANDRA-3653 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.0.6 Environment: Cassandra 1.0.6 Reporter: Radim Kolar Priority: Minor Selecting from Super CF returns error cqlsh:Keyspace1 select * from Keyspace1.Super1 limit 10; Internal application error cqlsh:Keyspace1 describe columnfamily Super1; CREATE COLUMNFAMILY Super1 ( KEY text PRIMARY KEY, crc32 bigint, id bigint, name ascii, size bigint ) WITH comment='' AND comparator=ascii AND row_cache_provider='ConcurrentLinkedHashCacheProvider' AND key_cache_size=20.00 AND row_cache_size=600.00 AND read_repair_chance=1.00 AND gc_grace_seconds=864000 AND default_validation=blob AND min_compaction_threshold=5 AND max_compaction_threshold=10 AND row_cache_save_period_in_seconds=0 AND key_cache_save_period_in_seconds=14400 AND replicate_on_write=False; -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3143) Global caches (key/row)
[ https://issues.apache.org/jira/browse/CASSANDRA-3143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3143: --- Attachment: 0009-3rd-Sylvain-comment-changes.patch bq. CacheKey could have a serializeSize() method for use rather needlessly creating ByteBuffers just to get there size in estimateSizeToSave. added serializedSize() method to CacheKey interface. bq. CacheKey.serialize() is unused. removed serialize() in favor of serializeForStorage() bq. Since that for saving each cache, we do n+1 iterations through the whole cache where n is the number of column families. It seems rather inefficient, we could probably write all caches (for all CFs) simultaneously for a more efficient process. Changed write to O(n) by keeping writers cached. bq. When reading the cache, it seems we decorate each key just to validate saved data (we discard the DK object afterwards). But I don't think decorating a key entails any kind of validation of the key so this feel useless. Fixed bq. Do we care about reloading the row cache? Jonathan was right that reloading a cache is probably pretty useless. Key and Row cache reloading is not dropped. (key cache reloading was dropped by patch 7). Global caches (key/row) --- Key: CASSANDRA-3143 URL: https://issues.apache.org/jira/browse/CASSANDRA-3143 Project: Cassandra Issue Type: Improvement Reporter: Pavel Yaskevich Assignee: Pavel Yaskevich Priority: Minor Labels: Core Fix For: 1.1 Attachments: 0001-global-key-cache.patch, 0002-global-row-cache-and-ASC.readSaved-changed-to-abstra.patch, 0003-CacheServiceMBean-and-correct-key-cache-loading.patch, 0004-key-row-cache-tests-and-tweaks.patch, 0005-cleanup-of-the-CFMetaData-and-thrift-avro-CfDef-and-.patch, 0006-row-key-cache-improvements-according-to-Sylvain-s-co.patch, 0007-caches-made-backward-compatible-second-round-of-chan.patch, 0008-row-key-cache-to-use-raw-key-instead-of-decorated.patch, 0009-3rd-Sylvain-comment-changes.patch Caches are difficult to configure well as ColumnFamilies are added, similar to how memtables were difficult pre-CASSANDRA-2006. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-3610) Checksum improvement for CompressedRandomAccessReader
[ https://issues.apache.org/jira/browse/CASSANDRA-3610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173445#comment-13173445 ] Vijay commented on CASSANDRA-3610: -- I think it is other way around they benchmarked zip.CRC32 to be slower than pure java implementation. In my tests it reduces the CPU util by 20% without any other change. Checksum improvement for CompressedRandomAccessReader - Key: CASSANDRA-3610 URL: https://issues.apache.org/jira/browse/CASSANDRA-3610 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.1 Environment: JVM Reporter: Vijay Assignee: Vijay Priority: Minor Fix For: 1.1 Attachments: 0001-use-pure-java-CRC32-v2.patch, 0001-use-pure-java-CRC32.patch When compression is on, Currently we see checksum taking up about 40% of the CPU more than snappy library. Looks like hadoop solved it by implementing their own checksum, we can either use it or implement something like that. http://images.slidesharecdn.com/1toddlipconyanpeichen-cloudera-hadoopandperformance-final-10132228-phpapp01-slide-15-768.jpg?1321043717 in our test env it provided 50% improvement over native implementation which uses jni to call the OS. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-3610) Checksum improvement for CompressedRandomAccessReader
[ https://issues.apache.org/jira/browse/CASSANDRA-3610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173448#comment-13173448 ] Jonathan Ellis commented on CASSANDRA-3610: --- bq. The summary is that, on Sun's JDK (which most people use), the pure Java implementation is faster for all chunk sizes less than 32 bytes (by a high factor for the smaller end of the spectrum) and about 33% slower for chunk sizes larger than that. Checksum improvement for CompressedRandomAccessReader - Key: CASSANDRA-3610 URL: https://issues.apache.org/jira/browse/CASSANDRA-3610 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.1 Environment: JVM Reporter: Vijay Assignee: Vijay Priority: Minor Fix For: 1.1 Attachments: 0001-use-pure-java-CRC32-v2.patch, 0001-use-pure-java-CRC32.patch When compression is on, Currently we see checksum taking up about 40% of the CPU more than snappy library. Looks like hadoop solved it by implementing their own checksum, we can either use it or implement something like that. http://images.slidesharecdn.com/1toddlipconyanpeichen-cloudera-hadoopandperformance-final-10132228-phpapp01-slide-15-768.jpg?1321043717 in our test env it provided 50% improvement over native implementation which uses jni to call the OS. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-3424) Selecting just the row_key returns nil instead of just the row_key
[
https://issues.apache.org/jira/browse/CASSANDRA-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173432#comment-13173432
]
Pavel Yaskevich edited comment on CASSANDRA-3424 at 12/20/11 7:46 PM:
--
It doesn't seem possible to distinguish between existing and non-existant keys
currently, would it be the good idea to revert this one? Or just close it and
move all discussion to CASSANDRA-3505?
was (Author: xedin):
I doesn't seem possible to distinguish between existing and non-existant
keys currently, would it be the good idea to revert this one? Or just close it
and move all discussion to CASSANDRA-3505?
Selecting just the row_key returns nil instead of just the row_key
--
Key: CASSANDRA-3424
URL: https://issues.apache.org/jira/browse/CASSANDRA-3424
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.0
Reporter: Kelley Reynolds
Assignee: Jonathan Ellis
Priority: Minor
Labels: cql
Fix For: 1.0.3
Attachments: 3424-v2.txt, CASSANDRA-3424.patch
CREATE KEYSPACE CassandraCQLTestKeyspace WITH
strategy_class='org.apache.cassandra.locator.SimpleStrategy' AND
strategy_options:replication_factor=1
USE CassandraCQLTestKeyspace
CREATE COLUMNFAMILY row_key_validation_cf_ascii (id ascii PRIMARY KEY,
test_column text)
INSERT INTO row_key_validation_cf_ascii (id, test_column) VALUES ('test
string', 'test')
# Works as expected
SELECT * FROM row_key_validation_cf_ascii WHERE id = 'test string'
# Returns an empty result, unexpected
SELECT id FROM row_key_validation_cf_ascii WHERE id = 'test string'
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-3631) While sleeping for RING_DELAY, bootstrapping nodes do not show as joining in the ring (or at all)
[ https://issues.apache.org/jira/browse/CASSANDRA-3631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173464#comment-13173464 ] Vijay commented on CASSANDRA-3631: -- Hi Brandon, Thinking about it more, i think none of the above might help because there wont be a token set Untill we start to bootstrap (at this point we already overwritten the hibernate status), So instead of setting hibernate= false/true we can say hibernate=token this way we can at-least try to show it in nt ring... but this looks like this will cause additional handling in the code. What do u think? do we need it? While sleeping for RING_DELAY, bootstrapping nodes do not show as joining in the ring (or at all) - Key: CASSANDRA-3631 URL: https://issues.apache.org/jira/browse/CASSANDRA-3631 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.0 Reporter: Brandon Williams Assignee: Vijay Priority: Minor Fix For: 1.0.7 As the title says, the nodes do not show in the ring until they are actually in the token selection/streaming phase. This appears due to CASSANDRA-957, but now can be further exacerbated by longer sleep times for CASSANDRA-3629. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173469#comment-13173469 ] Jonathan Ellis commented on CASSANDRA-2474: --- Incidentally, a side benefit of having metadata that CF X is transposed is that we can start applying wide-row optimizations for it, e.g. skipping a column-level bloom filter. CQL support for compound columns Key: CASSANDRA-2474 URL: https://issues.apache.org/jira/browse/CASSANDRA-2474 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Eric Evans Assignee: Pavel Yaskevich Labels: cql Fix For: 1.1 Attachments: 2474-transposed-1.PNG, 2474-transposed-raw.PNG, 2474-transposed-select-no-sparse.PNG, 2474-transposed-select.PNG, raw_composite.txt, screenshot-1.jpg, screenshot-2.jpg For the most part, this boils down to supporting the specification of compound column names (the CQL syntax is colon-delimted terms), and then teaching the decoders (drivers) to create structures from the results. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1221467 - in /cassandra/branches/cassandra-1.0: ./ src/java/org/apache/cassandra/net/ src/java/org/apache/cassandra/service/ src/java/org/apache/cassandra/thrift/ src/java/org/apache/cass
Author: jbellis
Date: Tue Dec 20 20:08:20 2011
New Revision: 1221467
URL: http://svn.apache.org/viewvc?rev=1221467view=rev
Log:
stop thrift service in shutdown hook so we can quiesce MessagingService
patch by jbellis; reviewed by Brandon Williams for CASSANDRA-3335
Modified:
cassandra/branches/cassandra-1.0/CHANGES.txt
cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/net/MessagingService.java
cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/service/StorageService.java
cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java
cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/thrift/TCustomServerSocket.java
cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/utils/ExpiringMap.java
cassandra/branches/cassandra-1.0/test/unit/org/apache/cassandra/service/RemoveTest.java
Modified: cassandra/branches/cassandra-1.0/CHANGES.txt
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-1.0/CHANGES.txt?rev=1221467r1=1221466r2=1221467view=diff
==
--- cassandra/branches/cassandra-1.0/CHANGES.txt (original)
+++ cassandra/branches/cassandra-1.0/CHANGES.txt Tue Dec 20 20:08:20 2011
@@ -3,6 +3,8 @@
* more efficient allocation of small bloom filters (CASSANDRA-3618)
* CLibrary.createHardLinkWithExec() to check for errors (CASSANDRA-3101)
* Avoid creating empty and non cleaned writer during compaction
(CASSANDRA-3616)
+ * stop thrift service in shutdown hook so we can quiesce MessagingService
+ (CASSANDRA-3335)
Merged from 0.8:
* prevent new nodes from thinking down nodes are up forever (CASSANDRA-3626)
Modified:
cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/net/MessagingService.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/net/MessagingService.java?rev=1221467r1=1221466r2=1221467view=diff
==
---
cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/net/MessagingService.java
(original)
+++
cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/net/MessagingService.java
Tue Dec 20 20:08:20 2011
@@ -473,25 +473,20 @@ public final class MessagingService impl
callbacks.clear();
}
-public void shutdown()
+/**
+ * There isn't a good way to shut down the MessagingService. One problem
(but not the only one)
+ * is that StorageProxy has no way to communicate back to clients, I'm
nominally alive, but I can't
+ * send that request to the nodes with your data. Neither TimedOut nor
Unavailable is appropriate
+ * to return in that situation.
+ *
+ * So instead of shutting down MS and letting StorageProxy/clients cope
somehow, we shut down
+ * the Thrift service and then wait for all the outstanding requests to
finish or timeout.
+ */
+public void waitForCallbacks()
{
-logger_.info(Shutting down MessageService...);
+logger_.info(Waiting for messaging service to quiesce);
// We may need to schedule hints on the mutation stage, so it's
erroneous to shut down the mutation stage first
assert !StageManager.getStage(Stage.MUTATION).isShutdown();
-
-try
-{
-for (SocketThread th : socketThreads)
-th.close();
-}
-catch (IOException e)
-{
-throw new IOError(e);
-}
-
-streamExecutor_.shutdown();
-
-logger_.info(Waiting for in-progress requests to complete);
callbacks.shutdown();
}
Modified:
cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/service/StorageService.java
URL:
http://svn.apache.org/viewvc/cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/service/StorageService.java?rev=1221467r1=1221466r2=1221467view=diff
==
---
cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/service/StorageService.java
(original)
+++
cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/service/StorageService.java
Tue Dec 20 20:08:20 2011
@@ -347,7 +347,7 @@ public class StorageService implements I
Gossiper.instance.unregister(migrationManager);
Gossiper.instance.unregister(this);
Gossiper.instance.stop();
-MessagingService.instance().shutdown();
+MessagingService.instance().waitForCallbacks();
// give it a second so that task accepted before the MessagingService
shutdown gets submitted to the stage (to avoid RejectedExecutionException)
try { Thread.sleep(1000L); } catch (InterruptedException e) {}
StageManager.shutdownNow();
@@ -443,13 +443,15 @@ public class StorageService implements I
if (mutationStage.isShutdown())
[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173480#comment-13173480 ] Jonathan Ellis commented on CASSANDRA-2474: --- bq. I didn't though the goal was to 'adapt to the relational philosophy' All data is relational, the only question is implementation details. :) Seriously though, send a query, get back rows is a good design for a language + driver, and you simply can't represent slices of wide, composite rows sanely that way without something like transposition to expose the structure hidden underneath. bq. WITH comparator = composite(sender,thread,tid); Wouldn't you need body in the composite list too? bq. --Finally in the case of both SPARSE/DENSE So this is basically what I gave, right? It sounds like you're bikeshedding the TRANSPOSED / WITH COMPARATOR syntax but not really solving the problem I outlined. Maybe I'm missing something. CQL support for compound columns Key: CASSANDRA-2474 URL: https://issues.apache.org/jira/browse/CASSANDRA-2474 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Eric Evans Assignee: Pavel Yaskevich Labels: cql Fix For: 1.1 Attachments: 2474-transposed-1.PNG, 2474-transposed-raw.PNG, 2474-transposed-select-no-sparse.PNG, 2474-transposed-select.PNG, raw_composite.txt, screenshot-1.jpg, screenshot-2.jpg For the most part, this boils down to supporting the specification of compound column names (the CQL syntax is colon-delimted terms), and then teaching the decoders (drivers) to create structures from the results. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-2474) CQL support for compound columns
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173484#comment-13173484 ] T Jake Luciani commented on CASSANDRA-2474: --- bq. Wouldn't you need body in the composite list too? That would be the value of the composite column CQL support for compound columns Key: CASSANDRA-2474 URL: https://issues.apache.org/jira/browse/CASSANDRA-2474 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Eric Evans Assignee: Pavel Yaskevich Labels: cql Fix For: 1.1 Attachments: 2474-transposed-1.PNG, 2474-transposed-raw.PNG, 2474-transposed-select-no-sparse.PNG, 2474-transposed-select.PNG, raw_composite.txt, screenshot-1.jpg, screenshot-2.jpg For the most part, this boils down to supporting the specification of compound column names (the CQL syntax is colon-delimted terms), and then teaching the decoders (drivers) to create structures from the results. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-2474) CQL support for compound columns
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173487#comment-13173487 ] Jonathan Ellis commented on CASSANDRA-2474: --- bq. you simply can't represent slices of wide, composite rows sanely that way without something like transposition to expose the structure hidden underneath. Put another way: we've always said the right way to model is to have one atom of data per CF -- that is, data that is queried together should go in the same CF. But, we haven't enforced this in the API. From my perspective, that's a bug, not a feature. If we *do* have a single type of data (or type of record) per CF, then we can make relational-style resultsets out of it; the only question is, how do we expose that in the query language. And the conclusion I'm coming to is that we shouldn't have to change the language; CQL-modeled-on-SQL is already good at describing sets of a given type of data. So the right thing to do is to provide hints in the DDL that tell Cassandra how to represent it at definition time, rather than at query time. Document data doesn't change this, it's just an expansion of what we consider a record or atom. Should we be able to have wide rows of documents? Yes. (E.g., by having a column type json.) But I don't think we need to boil that ocean here. TLDR: I am totally fine with having some constructs technically representable using composite columns, that we don't actually allow building from the API. Total schema-freedom is not a design goal. CQL support for compound columns Key: CASSANDRA-2474 URL: https://issues.apache.org/jira/browse/CASSANDRA-2474 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Eric Evans Assignee: Pavel Yaskevich Labels: cql Fix For: 1.1 Attachments: 2474-transposed-1.PNG, 2474-transposed-raw.PNG, 2474-transposed-select-no-sparse.PNG, 2474-transposed-select.PNG, raw_composite.txt, screenshot-1.jpg, screenshot-2.jpg For the most part, this boils down to supporting the specification of compound column names (the CQL syntax is colon-delimted terms), and then teaching the decoders (drivers) to create structures from the results. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1221482 - in /cassandra/trunk: ./ contrib/ interface/thrift/gen-java/org/apache/cassandra/thrift/ src/java/org/apache/cassandra/net/ src/java/org/apache/cassandra/service/ src/java/org/ap
Author: jbellis Date: Tue Dec 20 20:39:50 2011 New Revision: 1221482 URL: http://svn.apache.org/viewvc?rev=1221482view=rev Log: merge #3335 from 1.0 Modified: cassandra/trunk/ (props changed) cassandra/trunk/CHANGES.txt cassandra/trunk/contrib/ (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/NotFoundException.java (props changed) cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/SuperColumn.java (props changed) cassandra/trunk/src/java/org/apache/cassandra/net/MessagingService.java cassandra/trunk/src/java/org/apache/cassandra/service/StorageService.java cassandra/trunk/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java cassandra/trunk/src/java/org/apache/cassandra/thrift/TCustomServerSocket.java cassandra/trunk/src/java/org/apache/cassandra/utils/ExpiringMap.java cassandra/trunk/test/unit/org/apache/cassandra/service/RemoveTest.java Propchange: cassandra/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Tue Dec 20 20:39:50 2011 @@ -4,7 +4,7 @@ /cassandra/branches/cassandra-0.8:1090934-1125013,1125019-1198724,1198726-1206097,1206099-1212854,1212938,1214916 /cassandra/branches/cassandra-0.8.0:1125021-1130369 /cassandra/branches/cassandra-0.8.1:1101014-1125018 -/cassandra/branches/cassandra-1.0:1167085-1221019 +/cassandra/branches/cassandra-1.0:1167085-1221481 /cassandra/branches/cassandra-1.0.0:1167104-1167229,1167232-1181093,1181741,1181816,1181820,1182951,1183243 /cassandra/branches/cassandra-1.0.5:1208016 /cassandra/tags/cassandra-0.7.0-rc3:1051699-1053689 Modified: cassandra/trunk/CHANGES.txt URL: http://svn.apache.org/viewvc/cassandra/trunk/CHANGES.txt?rev=1221482r1=1221481r2=1221482view=diff == --- cassandra/trunk/CHANGES.txt (original) +++ cassandra/trunk/CHANGES.txt Tue Dec 20 20:39:50 2011 @@ -34,6 +34,8 @@ * more efficient allocation of small bloom filters (CASSANDRA-3618) * CLibrary.createHardLinkWithExec() to check for errors (CASSANDRA-3101) * Avoid creating empty and non cleaned writer during compaction (CASSANDRA-3616) + * stop thrift service in shutdown hook so we can quiesce MessagingService + (CASSANDRA-3335) Merged from 0.8: * prevent new nodes from thinking down nodes are up forever (CASSANDRA-3626) Propchange: cassandra/trunk/contrib/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Tue Dec 20 20:39:50 2011 @@ -4,7 +4,7 @@ /cassandra/branches/cassandra-0.8/contrib:1090934-1125013,1125019-1198724,1198726-1206097,1206099-1212854,1212938,1214916 /cassandra/branches/cassandra-0.8.0/contrib:1125021-1130369 /cassandra/branches/cassandra-0.8.1/contrib:1101014-1125018 -/cassandra/branches/cassandra-1.0/contrib:1167085-1221019 +/cassandra/branches/cassandra-1.0/contrib:1167085-1221481 /cassandra/branches/cassandra-1.0.0/contrib:1167104-1167229,1167232-1181093,1181741,1181816,1181820,1182951,1183243 /cassandra/branches/cassandra-1.0.5/contrib:1208016 /cassandra/tags/cassandra-0.7.0-rc3/contrib:1051699-1053689 Propchange: cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java -- --- svn:mergeinfo (original) +++ svn:mergeinfo Tue Dec 20 20:39:50 2011 @@ -4,7 +4,7 @@ /cassandra/branches/cassandra-0.8/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1090934-1125013,1125019-1198724,1198726-1206097,1206099-1212854,1212938,1214916 /cassandra/branches/cassandra-0.8.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1125021-1130369 /cassandra/branches/cassandra-0.8.1/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1101014-1125018 -/cassandra/branches/cassandra-1.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1167085-1221019 +/cassandra/branches/cassandra-1.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1167085-1221481 /cassandra/branches/cassandra-1.0.0/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1167104-1167229,1167232-1181093,1181741,1181816,1181820,1182951,1183243 /cassandra/branches/cassandra-1.0.5/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1208016 /cassandra/tags/cassandra-0.7.0-rc3/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java:1051699-1053689 Propchange:
[jira] [Commented] (CASSANDRA-3631) While sleeping for RING_DELAY, bootstrapping nodes do not show as joining in the ring (or at all)
[ https://issues.apache.org/jira/browse/CASSANDRA-3631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173501#comment-13173501 ] Brandon Williams commented on CASSANDRA-3631: - bq. Thinking about it more, i think none of the above might help because there wont be a token set Untill we start to bootstrap (at this point we already overwritten the hibernate status) I don't understand, can you explain? ISTM if you're doing a replacement and need to hibernate, the token has to be specified before then. While sleeping for RING_DELAY, bootstrapping nodes do not show as joining in the ring (or at all) - Key: CASSANDRA-3631 URL: https://issues.apache.org/jira/browse/CASSANDRA-3631 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.0 Reporter: Brandon Williams Assignee: Vijay Priority: Minor Fix For: 1.0.7 As the title says, the nodes do not show in the ring until they are actually in the token selection/streaming phase. This appears due to CASSANDRA-957, but now can be further exacerbated by longer sleep times for CASSANDRA-3629. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
svn commit: r1221489 - /cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/tools/NodeCmd.java
Author: jbellis Date: Tue Dec 20 20:57:36 2011 New Revision: 1221489 URL: http://svn.apache.org/viewvc?rev=1221489view=rev Log: fix upgradesstables help text Modified: cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/tools/NodeCmd.java Modified: cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/tools/NodeCmd.java URL: http://svn.apache.org/viewvc/cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/tools/NodeCmd.java?rev=1221489r1=1221488r2=1221489view=diff == --- cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/tools/NodeCmd.java (original) +++ cassandra/branches/cassandra-1.0/src/java/org/apache/cassandra/tools/NodeCmd.java Tue Dec 20 20:57:36 2011 @@ -157,7 +157,7 @@ public class NodeCmd addCmdHelp(header, cleanup [keyspace] [cfnames], Run cleanup on one or more column family); addCmdHelp(header, compact [keyspace] [cfnames], Force a (major) compaction on one or more column family); addCmdHelp(header, scrub [keyspace] [cfnames], Scrub (rebuild sstables for) one or more column family); -addCmdHelp(header, upgradesstables [keyspace] [cfnames], Scrub (rebuild sstables for) one or more column family); +addCmdHelp(header, upgradesstables [keyspace] [cfnames], Upgrade sstables for one or more column family); addCmdHelp(header, invalidatekeycache [keyspace] [cfnames], Invalidate the key cache of one or more column family); addCmdHelp(header, invalidaterowcache [keyspace] [cfnames], Invalidate the key cache of one or more column family); addCmdHelp(header, getcompactionthreshold keyspace cfname, Print min and max compaction thresholds for a given column family);
[jira] [Created] (CASSANDRA-3654) Warn when the stored Gossip Generation is from the future
Warn when the stored Gossip Generation is from the future - Key: CASSANDRA-3654 URL: https://issues.apache.org/jira/browse/CASSANDRA-3654 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.0.6 Reporter: Aaron Morton Assignee: Aaron Morton Priority: Trivial I had a case where the server was first started with the current time set way in the future. So the gossip generation was initialized with a very high value (background http://thelastpickle.com/2011/12/15/Anatomy-of-a-Cassandra-Partition/) There were some other issues at play, but a log message warning of the high generation would have helped. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-3631) While sleeping for RING_DELAY, bootstrapping nodes do not show as joining in the ring (or at all)
[ https://issues.apache.org/jira/browse/CASSANDRA-3631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173506#comment-13173506 ] Vijay commented on CASSANDRA-3631: -- Hibernate code is helpful only when we replace a node with the same IP. When a node comes back with the same IP and token, other nodes in the cluster will mark it UP because they know the token before it went down, hence we are setting hibernate so they will still think the node is down. Meanwhile we will stream the data and once the stream is completed we will mark that node as normal which will trigger hints to be streamed in. For nodes which are not replaced with the same IP this code is useless and harmless as they are not in the tokenMetadata they will not be considered part of the ring or will be considered as up until we set the token. Makes sense? By removing the hibernate code we will not be able to do the above. As nt ring is looking for the getTokenToEndpointMap() and then looks for the nodes are up or down, Unless we change the way nt ring works to show nodes which are gossiping (This might include fat clients till they are removed). In a normal bootstrap case we still dont know the token, untill we have selected the token. hope i am making sense. While sleeping for RING_DELAY, bootstrapping nodes do not show as joining in the ring (or at all) - Key: CASSANDRA-3631 URL: https://issues.apache.org/jira/browse/CASSANDRA-3631 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.0 Reporter: Brandon Williams Assignee: Vijay Priority: Minor Fix For: 1.0.7 As the title says, the nodes do not show in the ring until they are actually in the token selection/streaming phase. This appears due to CASSANDRA-957, but now can be further exacerbated by longer sleep times for CASSANDRA-3629. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3143) Global caches (key/row)
[ https://issues.apache.org/jira/browse/CASSANDRA-3143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3143: --- Attachment: (was: 0009-3rd-Sylvain-comment-changes.patch) Global caches (key/row) --- Key: CASSANDRA-3143 URL: https://issues.apache.org/jira/browse/CASSANDRA-3143 Project: Cassandra Issue Type: Improvement Reporter: Pavel Yaskevich Assignee: Pavel Yaskevich Priority: Minor Labels: Core Fix For: 1.1 Attachments: 0001-global-key-cache.patch, 0002-global-row-cache-and-ASC.readSaved-changed-to-abstra.patch, 0003-CacheServiceMBean-and-correct-key-cache-loading.patch, 0004-key-row-cache-tests-and-tweaks.patch, 0005-cleanup-of-the-CFMetaData-and-thrift-avro-CfDef-and-.patch, 0006-row-key-cache-improvements-according-to-Sylvain-s-co.patch, 0007-caches-made-backward-compatible-second-round-of-chan.patch, 0008-row-key-cache-to-use-raw-key-instead-of-decorated.patch Caches are difficult to configure well as ColumnFamilies are added, similar to how memtables were difficult pre-CASSANDRA-2006. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-3143) Global caches (key/row)
[ https://issues.apache.org/jira/browse/CASSANDRA-3143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3143: --- Attachment: 0009-3rd-Sylvain-comment-changes.patch Global caches (key/row) --- Key: CASSANDRA-3143 URL: https://issues.apache.org/jira/browse/CASSANDRA-3143 Project: Cassandra Issue Type: Improvement Reporter: Pavel Yaskevich Assignee: Pavel Yaskevich Priority: Minor Labels: Core Fix For: 1.1 Attachments: 0001-global-key-cache.patch, 0002-global-row-cache-and-ASC.readSaved-changed-to-abstra.patch, 0003-CacheServiceMBean-and-correct-key-cache-loading.patch, 0004-key-row-cache-tests-and-tweaks.patch, 0005-cleanup-of-the-CFMetaData-and-thrift-avro-CfDef-and-.patch, 0006-row-key-cache-improvements-according-to-Sylvain-s-co.patch, 0007-caches-made-backward-compatible-second-round-of-chan.patch, 0008-row-key-cache-to-use-raw-key-instead-of-decorated.patch, 0009-3rd-Sylvain-comment-changes.patch Caches are difficult to configure well as ColumnFamilies are added, similar to how memtables were difficult pre-CASSANDRA-2006. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-3655) NPE when running upgradesstables
NPE when running upgradesstables Key: CASSANDRA-3655 URL: https://issues.apache.org/jira/browse/CASSANDRA-3655 Project: Cassandra Issue Type: Bug Affects Versions: 1.0.5 Environment: 1.0.5 + patch for https://issues.apache.org/jira/browse/CASSANDRA-3618 Reporter: Tupshin Harper Assignee: Tupshin Harper Fix For: 1.0.7 Running a test upgrade from 0.7(version f sstables) to 1.0. upgradesstables runs for about 40 minutes and then NPE's when trying to retrieve a key. No files have been succesfully upgraded. Likely related is that scrub (without having run upgrade) consumes all RAM and OOMs. Possible theory is that a lot of paths call IPartitioner's decorateKey, and, at least in the randompartitioner's implementation, if any of those callers pass a null ByteBuffer, they key will be null in the stack trace below. java.util.concurrent.ExecutionException: java.lang.NullPointerException at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222) at java.util.concurrent.FutureTask.get(FutureTask.java:83) at org.apache.cassandra.db.compaction.CompactionManager.performAllSSTableOperation(CompactionManager.java:203) at org.apache.cassandra.db.compaction.CompactionManager.performSSTableRewrite(CompactionManager.java:219) at org.apache.cassandra.db.ColumnFamilyStore.sstablesRewrite(ColumnFamilyStore.java:970) at org.apache.cassandra.service.StorageService.upgradeSSTables(StorageService.java:1540) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:93) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:27) at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208) at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:120) at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:262) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1427) at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1265) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1360) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:788) at sun.reflect.GeneratedMethodAccessor39.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305) at sun.rmi.transport.Transport$1.run(Transport.java:159) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:155) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: java.lang.NullPointerException at org.apache.cassandra.db.compaction.PrecompactedRow.removeDeletedAndOldShards(PrecompactedRow.java:65) at org.apache.cassandra.db.compaction.PrecompactedRow.init(PrecompactedRow.java:92) at org.apache.cassandra.db.compaction.CompactionController.getCompactedRow(CompactionController.java:137) at org.apache.cassandra.db.compaction.CompactionIterable$Reducer.getReduced(CompactionIterable.java:102) at org.apache.cassandra.db.compaction.CompactionIterable$Reducer.getReduced(CompactionIterable.java:87) at org.apache.cassandra.utils.MergeIterator$OneToOne.computeNext(MergeIterator.java:200) at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140) at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135)
[jira] [Commented] (CASSANDRA-3654) Warn when the stored Gossip Generation is from the future
[ https://issues.apache.org/jira/browse/CASSANDRA-3654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173588#comment-13173588 ] Brandon Williams commented on CASSANDRA-3654: - Can we mention this ticket in the patch so if people do encounter this they have an easier avenue to pursue? I'll go ahead and add a little note here quoting your blog post: bq. I think in theory there is a danger that if we removed node #23 from the ring and added another node with the same IP in less than 4 days it will have problems with it’s Generation not been seen as new. But thats a pretty small danger. Yes, that would definitely be a problem, because removed states are held until Gossiper.aVeryLongTime (after CASSANDRA-2496) which is 3 days (I quoted you 4 just to be safe.) If the removed generation is in the future and thus higher than the joining node, the new node won't be able to communicate any state for either that IP *or* that token. The easiest thing to do in this situation is bootstrap the new node on a different IP at token-1, removetoken the existing token, wait 3 days, and if you really care about having the old IP or token back move it after that. You can also use this as an alternate solution to the problem, though you _must_ wipe at least the system keyspace on the node before bootstrapping it back in. Warn when the stored Gossip Generation is from the future - Key: CASSANDRA-3654 URL: https://issues.apache.org/jira/browse/CASSANDRA-3654 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.0.6 Reporter: Aaron Morton Assignee: Aaron Morton Priority: Trivial Attachments: 0001-3654.patch I had a case where the server was first started with the current time set way in the future. So the gossip generation was initialized with a very high value (background http://thelastpickle.com/2011/12/15/Anatomy-of-a-Cassandra-Partition/) There were some other issues at play, but a log message warning of the high generation would have helped. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-3631) While sleeping for RING_DELAY, bootstrapping nodes do not show as joining in the ring (or at all)
[ https://issues.apache.org/jira/browse/CASSANDRA-3631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173587#comment-13173587 ] Vijay commented on CASSANDRA-3631: -- but other nodes in the cluster shouldn't be sending the data until the schema is settled and we are ready, by doing the wait for schema after update token that might be violated right? While sleeping for RING_DELAY, bootstrapping nodes do not show as joining in the ring (or at all) - Key: CASSANDRA-3631 URL: https://issues.apache.org/jira/browse/CASSANDRA-3631 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.0 Reporter: Brandon Williams Assignee: Vijay Priority: Minor Fix For: 1.0.7 As the title says, the nodes do not show in the ring until they are actually in the token selection/streaming phase. This appears due to CASSANDRA-957, but now can be further exacerbated by longer sleep times for CASSANDRA-3629. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3631) While sleeping for RING_DELAY, bootstrapping nodes do not show as joining in the ring (or at all)
[ https://issues.apache.org/jira/browse/CASSANDRA-3631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173590#comment-13173590 ] Brandon Williams commented on CASSANDRA-3631: - Crap, you're right. It would be harmless, but the spew of errors would worry people. I think you were right in the beginning, Initializing is the best thing to do here. :) While sleeping for RING_DELAY, bootstrapping nodes do not show as joining in the ring (or at all) - Key: CASSANDRA-3631 URL: https://issues.apache.org/jira/browse/CASSANDRA-3631 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.0 Reporter: Brandon Williams Assignee: Vijay Priority: Minor Fix For: 1.0.7 As the title says, the nodes do not show in the ring until they are actually in the token selection/streaming phase. This appears due to CASSANDRA-957, but now can be further exacerbated by longer sleep times for CASSANDRA-3629. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[wiki.cassandra-jdbc] push by - Edited wiki page HowToBuild through web user interface. on 2011-12-20 04:21 GMT
Revision: e39e08e90ee9
Author: john.eric.evans john.eric.ev...@gmail.com
Date: Mon Dec 19 20:21:47 2011
Log: Edited wiki page HowToBuild through web user interface.
http://code.google.com/a/apache-extras.org/p/cassandra-jdbc/source/detail?r=e39e08e90ee9repo=wiki
Modified:
/HowToBuild.wiki
===
--- /HowToBuild.wikiTue Dec 13 15:50:25 2011
+++ /HowToBuild.wikiMon Dec 19 20:21:47 2011
@@ -7,24 +7,12 @@
The JDBC driver has a dependency on two [http://cassandra.apache.org
Cassandra] jars, `cassandra-clientutil` and `cassandra-thrift`, neither of
which will be available through a Maven repository until the release of
Cassandra 1.1.0. In the meantime you must ~~shave a yak~~ satisfy this
dependency manually.
-First, download the source and build the jar artifacts.
+First, download the source and install the Cassandra jar artifacts.
{{{
$ svn checkout https://svn.apache.org/repos/asf/cassandra/trunk cassandra
$ cd cassandra
-$ ant jar
-}}}
-
-When complete, install the artifacts to `~/.m2`
-
-{{{
-mvn install:install-file -DgroupId=org.apache.cassandra \
--DartifactId=cassandra-clientutil -Dversion=1.1-dev-SNAPSHOT
-Dpackaging=jar \
--Dfile=build/apache-cassandra-clientutil-1.1-dev-SNAPSHOT.jar
-...
-mvn install:install-file -DgroupId=org.apache.cassandra \
--DartifactId=cassandra-thrift -Dversion=1.1-dev-SNAPSHOT
-Dpackaging=jar \
--Dfile=build/apache-cassandra-thrift-1.1-dev-SNAPSHOT.jar
+$ ant mvn-install
}}}
== Building ==
[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173624#comment-13173624 ] Jonathan Ellis commented on CASSANDRA-2474: --- bq. just model it with dense composites is not an option for the mview use case, where adding new columns requires rebuilding the entire CF. That's a big win for us, and I'm not willing to give it up. Eric raised an interesting point on IRC -- is there a technical reason why the dense CompositeType implementation can't just treat missing components as null, allowing adding new columns in a straightforward extension of the existing CT tuples? (Dropping columns is trickier but doable: we'd need to keep the CT definition the same, but add an ignore these parts of the tuple set to track columns that are no longer relevant.) If that's reasonable then I'm fine with dropping the whole sparse idea. CQL support for compound columns Key: CASSANDRA-2474 URL: https://issues.apache.org/jira/browse/CASSANDRA-2474 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Eric Evans Assignee: Pavel Yaskevich Labels: cql Fix For: 1.1 Attachments: 2474-transposed-1.PNG, 2474-transposed-raw.PNG, 2474-transposed-select-no-sparse.PNG, 2474-transposed-select.PNG, raw_composite.txt, screenshot-1.jpg, screenshot-2.jpg For the most part, this boils down to supporting the specification of compound column names (the CQL syntax is colon-delimted terms), and then teaching the decoders (drivers) to create structures from the results. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-3656) GC can take 0 ms
GC can take 0 ms Key: CASSANDRA-3656 URL: https://issues.apache.org/jira/browse/CASSANDRA-3656 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.7, 0.7.9 Reporter: Jonathan Ellis Priority: Trivial Fix For: 0.8.10, 1.0.7 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3656) GC can take 0 ms
[ https://issues.apache.org/jira/browse/CASSANDRA-3656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173856#comment-13173856 ] Jonathan Ellis commented on CASSANDRA-3656: --- (Michael's stacktrace is against 1.0.3.) GC can take 0 ms Key: CASSANDRA-3656 URL: https://issues.apache.org/jira/browse/CASSANDRA-3656 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.9, 0.8.7 Reporter: Jonathan Ellis Priority: Trivial Fix For: 0.8.10, 1.0.7 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3656) GC can take 0 ms
[
https://issues.apache.org/jira/browse/CASSANDRA-3656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173855#comment-13173855
]
Jonathan Ellis commented on CASSANDRA-3656:
---
As reported by Michael Vaknine on the mailing list,
{noformat}
STG-Cass4 ERROR [ScheduledTasks:1] 2011-12-12 22:55:26,554
java.lang.AssertionError
STG-Cass4 ERROR [ScheduledTasks:1] 2011-12-12 22:55:26,554 at
org.apache.cassandra.service.GCInspector.logGCResults(GCInspector.java:103)
STG-Cass4 ERROR [ScheduledTasks:1] 2011-12-12 22:55:26,554 at
org.apache.cassandra.service.GCInspector.access$000(GCInspector.java:41)
STG-Cass4 ERROR [ScheduledTasks:1] 2011-12-12 22:55:26,554 at
org.apache.cassandra.service.GCInspector$1.run(GCInspector.java:85)
{noformat}
GC can take 0 ms
Key: CASSANDRA-3656
URL: https://issues.apache.org/jira/browse/CASSANDRA-3656
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.7.9, 0.8.7
Reporter: Jonathan Ellis
Priority: Trivial
Fix For: 0.8.10, 1.0.7
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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-3511) Supercolumn key caches are not saved
[ https://issues.apache.org/jira/browse/CASSANDRA-3511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173899#comment-13173899 ] Radim Kolar commented on CASSANDRA-3511: Cache from test is still populated but was never saved. Column Family: Super1 SSTable count: 4 Space used (live): 101785086 Space used (total): 101785086 Number of Keys (estimate): 292500 Memtable Columns Count: 0 Memtable Data Size: 0 Memtable Switch Count: 12 Read Count: 292110 Read Latency: NaN ms. Write Count: 291682 Write Latency: NaN ms. Pending Tasks: 0 Bloom Filter False Postives: 628 Bloom Filter False Ratio: 0.0 Bloom Filter Space Used: 553840 Key cache capacity: 20 Key cache size: 109093 Key cache hit rate: NaN Row cache capacity: 600 Row cache size: 600 Row cache hit rate: NaN Compacted row minimum size: 311 Compacted row maximum size: 372 Compacted row mean size: 372 Supercolumn key caches are not saved Key: CASSANDRA-3511 URL: https://issues.apache.org/jira/browse/CASSANDRA-3511 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0.2, 1.0.3 Reporter: Radim Kolar Priority: Minor Labels: supercolumns Attachments: failed-to-save-after-load-KeyCache, rapidshare-resultcache-KeyCache cache saving seems to be broken in 1.0.2 and 1.0.3 i have 2 CF in keyspace with enabled cache saving and only one gets its key cache saved. It worked perfectly in 0.8, both were saved. This one works: create column family query2 with column_type = 'Standard' and comparator = 'AsciiType' and default_validation_class = 'BytesType' and key_validation_class = 'UTF8Type' and rows_cached = 500.0 and row_cache_save_period = 0 and row_cache_keys_to_save = 2147483647 and keys_cached = 20.0 and key_cache_save_period = 14400 and read_repair_chance = 1.0 and gc_grace = 864000 and min_compaction_threshold = 5 and max_compaction_threshold = 10 and replicate_on_write = false and row_cache_provider = 'ConcurrentLinkedHashCacheProvider' and compaction_strategy = 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy' This does not create column family dkb13 with column_type = 'Super' and comparator = 'LongType' and subcomparator = 'AsciiType' and default_validation_class = 'BytesType' and key_validation_class = 'UTF8Type' and rows_cached = 600.0 and row_cache_save_period = 0 and row_cache_keys_to_save = 2147483647 and keys_cached = 20.0 and key_cache_save_period = 14400 and read_repair_chance = 1.0 and gc_grace = 864000 and min_compaction_threshold = 5 and max_compaction_threshold = 10 and replicate_on_write = false and row_cache_provider = 'ConcurrentLinkedHashCacheProvider' and compaction_strategy = 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy' in second test system i created these 2 column families and none of them got single cache key saved. Both have save period 30 seoonds - their cache should save often. Its not that standard column family works while super does not. create column family test1 with column_type = 'Standard' and comparator = 'BytesType' and default_validation_class = 'BytesType' and key_validation_class = 'BytesType' and rows_cached = 0.0 and row_cache_save_period = 0 and row_cache_keys_to_save = 2147483647 and keys_cached = 20.0 and key_cache_save_period = 30 and read_repair_chance = 1.0 and gc_grace = 864000 and min_compaction_threshold = 4 and max_compaction_threshold = 32 and replicate_on_write = true and row_cache_provider = 'SerializingCacheProvider' and compaction_strategy = 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'; create column family test2 with column_type = 'Standard' and comparator = 'BytesType' and default_validation_class = 'BytesType' and key_validation_class = 'BytesType' and rows_cached = 0.0 and row_cache_save_period = 0 and row_cache_keys_to_save = 2147483647 and keys_cached = 20.0 and key_cache_save_period = 30 and read_repair_chance = 1.0 and gc_grace = 864000 and min_compaction_threshold = 4 and max_compaction_threshold = 32 and replicate_on_write = true and row_cache_provider = 'SerializingCacheProvider' and compaction_strategy =
