[jira] [Created] (CASSANDRA-14663) Cassandra logos need to be updated with mark information
Gary Dusbabek created CASSANDRA-14663: - Summary: Cassandra logos need to be updated with mark information Key: CASSANDRA-14663 URL: https://issues.apache.org/jira/browse/CASSANDRA-14663 Project: Cassandra Issue Type: Task Components: Documentation and Website Reporter: Gary Dusbabek Assignee: Gary Dusbabek Apache Cassandra logos should be updated to include the TM symbol (™) to reflect the trademark. The Cassandra logs can also only be found in SVN[1]. We should probably include a link in the website. 1. https://svn.apache.org/viewvc/cassandra/logo/ -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14395) C* Management process
[ https://issues.apache.org/jira/browse/CASSANDRA-14395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16442586#comment-16442586 ] Gary Dusbabek commented on CASSANDRA-14395: --- Would you mind relaxing the permissions on this document so that permission does not need to be requested by anyone who wishes to view it? > C* Management process > - > > Key: CASSANDRA-14395 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14395 > Project: Cassandra > Issue Type: New Feature >Reporter: Dinesh Joshi >Assignee: Dinesh Joshi >Priority: Major > > I would like to propose amending Cassandra's architecture to include a > management process. The detailed description is here: > https://docs.google.com/document/d/1UV9pE81NaIUF3g4L1wxq09nT11AkSQcMijgLFwGsY3s/edit > I'd like to propose seeding this with a few simple use-cases such as Health > Checks, Bulk Commands with a simple REST API interface. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-9259) Bulk Reading from Cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-9259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15214212#comment-15214212 ] Gary Dusbabek commented on CASSANDRA-9259: -- FWIW I experimented with domain sockets late last year. Domain sockets were faster, but not much faster than reading for eth0->eth0, which on modern linux distros goes over the loopback (try it). Experimental branches of the Datastax java driver and Cassandra: https://github.com/gdusbabek/cassandra/tree/cassandra-3.0.2-domain-socket and https://github.com/gdusbabek/java-driver/tree/domain_sockets_3.0 > Bulk Reading from Cassandra > --- > > Key: CASSANDRA-9259 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9259 > Project: Cassandra > Issue Type: New Feature > Components: Compaction, CQL, Local Write-Read Paths, Streaming and > Messaging, Testing >Reporter: Brian Hess >Assignee: Stefania >Priority: Critical > Fix For: 3.x > > Attachments: bulk-read-benchmark.1.html, > bulk-read-jfr-profiles.1.tar.gz, bulk-read-jfr-profiles.2.tar.gz > > > This ticket is following on from the 2015 NGCC. This ticket is designed to > be a place for discussing and designing an approach to bulk reading. > The goal is to have a bulk reading path for Cassandra. That is, a path > optimized to grab a large portion of the data for a table (potentially all of > it). This is a core element in the Spark integration with Cassandra, and the > speed at which Cassandra can deliver bulk data to Spark is limiting the > performance of Spark-plus-Cassandra operations. This is especially of > importance as Cassandra will (likely) leverage Spark for internal operations > (for example CASSANDRA-8234). > The core CQL to consider is the following: > SELECT a, b, c FROM myKs.myTable WHERE Token(partitionKey) > X AND > Token(partitionKey) <= Y > Here, we choose X and Y to be contained within one token range (perhaps > considering the primary range of a node without vnodes, for example). This > query pushes 50K-100K rows/sec, which is not very fast if we are doing bulk > operations via Spark (or other processing frameworks - ETL, etc). There are > a few causes (e.g., inefficient paging). > There are a few approaches that could be considered. First, we consider a > new "Streaming Compaction" approach. The key observation here is that a bulk > read from Cassandra is a lot like a major compaction, though instead of > outputting a new SSTable we would output CQL rows to a stream/socket/etc. > This would be similar to a CompactionTask, but would strip out some > unnecessary things in there (e.g., some of the indexing, etc). Predicates and > projections could also be encapsulated in this new "StreamingCompactionTask", > for example. > Another approach would be an alternate storage format. For example, we might > employ Parquet (just as an example) to store the same data as in the primary > Cassandra storage (aka SSTables). This is akin to Global Indexes (an > alternate storage of the same data optimized for a particular query). Then, > Cassandra can choose to leverage this alternate storage for particular CQL > queries (e.g., range scans). > These are just 2 suggestions to get the conversation going. > One thing to note is that it will be useful to have this storage segregated > by token range so that when you extract via these mechanisms you do not get > replications-factor numbers of copies of the data. That will certainly be an > issue for some Spark operations (e.g., counting). Thus, we will want > per-token-range storage (even for single disks), so this will likely leverage > CASSANDRA-6696 (though, we'll want to also consider the single disk case). > It is also worth discussing what the success criteria is here. It is > unlikely to be as fast as EDW or HDFS performance (though, that is still a > good goal), but being within some percentage of that performance should be > set as success. For example, 2x as long as doing bulk operations on HDFS > with similar node count/size/etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8777) Streaming operations should log both endpoint and port associated with the operation
[ https://issues.apache.org/jira/browse/CASSANDRA-8777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14651836#comment-14651836 ] Gary Dusbabek commented on CASSANDRA-8777: -- Easiest approach: Each stream session is used for a single `peer`, so you could log that and `connecting` in `onError()`. Another option would be to add a `logger.error()` to `DefaultConnectionFactory` right before the throw, and also `BulkLoadConnectionFactory`. Streaming operations should log both endpoint and port associated with the operation Key: CASSANDRA-8777 URL: https://issues.apache.org/jira/browse/CASSANDRA-8777 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jeremy Hanna Labels: lhf Fix For: 2.1.x Currently we log the endpoint for a streaming operation. If the port has been overridden, it would be valuable to know that that setting is getting picked up. Therefore, when logging the endpoint address, it would be nice to also log the port it's trying to use. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8817) Error handling in Cassandra logs in low memory scenarios could use improvement
[ https://issues.apache.org/jira/browse/CASSANDRA-8817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14591945#comment-14591945 ] Gary Dusbabek commented on CASSANDRA-8817: -- What would be appropriate levels for Y and Z? Error handling in Cassandra logs in low memory scenarios could use improvement -- Key: CASSANDRA-8817 URL: https://issues.apache.org/jira/browse/CASSANDRA-8817 Project: Cassandra Issue Type: Improvement Components: Core Environment: Ubuntu 14.04, VM originally created with 1 GB RAM, DSE 4.6.0 installed Reporter: Michael DeHaan Priority: Minor Labels: lhf Fix For: 2.1.x When running Cassandra with a low amount of RAM, in this case, using DataStax Enterprise 4.6.0 in a reasonably default configuration, I find that I get an error after starting and trying to use nodetool, namely that it cannot connect to 127.0.0.1. Originally this sends me up a creek, looking for why Cassandra is not listening on 7199. The truth ends up being a bit more cryptic - that Cassandra isn't running. Upon looking at the Cassandra system logs, I see the last thing that it did was print out the (very long) class path. This confused me as basically I'm seeing no errors in the log at all. I am proposing that Cassandra should check the amount of available RAM and issue a warning in the log, or possibly an error, because in this scenario Cassandra is going to oomkill and probably could have predicted this in advance. Something like: Found X MB of RAM, expecting at least Y MB of RAM, Z MB recommended, may crash, adjust SETTINGS or something similar would be a possible solution. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-6846) Provide standard interface for deep application server integration
[ https://issues.apache.org/jira/browse/CASSANDRA-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13933296#comment-13933296 ] Gary Dusbabek commented on CASSANDRA-6846: -- +1 I support this. I have believed for a long time that components of Cassandra could be extracted to create an excellent platform for building distributed systems in general. This kind of thinking gets us pointed in that direction. Even though it is designed to be a database, I would support the standardization of a few internal APIs. Practically speaking this will be hard, and I would expect a bumpy road, as the API would occasionally be trampled by new database features. A few good tests in the projects that rely on these APIs is all that's needed to monitor things. Provide standard interface for deep application server integration -- Key: CASSANDRA-6846 URL: https://issues.apache.org/jira/browse/CASSANDRA-6846 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Tupshin Harper Assignee: Tupshin Harper Priority: Minor Labels: (╯°□°)╯︵┻━┻, ponies Instead of creating a pluggable interface for Thrift, I'd like to create a pluggable interface for arbitrary app-server deep integration. Inspired by both the existence of intravert-ug, as well as there being a long history of various parties embedding tomcat or jetty servlet engines inside Cassandra, I'd like to propose the creation an internal somewhat stable (versioned?) interface that could allow any app server to achieve deep integration with Cassandra, and as a result, these servers could 1) host their own apis (REST, for example 2) extend core functionality by having limited (see triggers and wide row scanners) access to the internals of cassandra The hand wavey part comes because while I have been mulling this about for a while, I have not spent any significant time into looking at the actual surface area of intravert-ug's integration. But, using it as a model, and also keeping in minds the general needs of your more traditional servlet/j2ee containers, I believe we could come up with a reasonable interface to allow any jvm app server to be integrated and maintained in or out of the Cassandra tree. This would satisfy the needs that many of us (Both Ed and I, for example) to have a much greater degree of control over server side execution, and to be able to start building much more interestingly (and simply) tiered applications. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-4498) Remove openjdk-6-jre Cassandra APT dependencies
[ https://issues.apache.org/jira/browse/CASSANDRA-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13443431#comment-13443431 ] Gary Dusbabek commented on CASSANDRA-4498: -- What about this: https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/Memtable.java#L162 Remove openjdk-6-jre Cassandra APT dependencies --- Key: CASSANDRA-4498 URL: https://issues.apache.org/jira/browse/CASSANDRA-4498 Project: Cassandra Issue Type: Improvement Reporter: Terrance Shepherd Assignee: Brandon Williams Priority: Minor Labels: debian Fix For: 1.2.0 beta 1 Attachments: apache_cassandra_Packages.diff As it is well known the recommended jre for Cassandra is sun java 1.6 but at this point that package no longer in the debian or ubuntu apt repos. In order to run Cassandra with the sun java 1.6 jre it must be installed manually with out the repos. Because of this when you install cassandra via the apache or datastax apt repos it must also install openjdk-6-jre even though sun java 1.6 jre is already installed. I would suggest that the java apt dependencies be removed from the Depends field in package configuration and move to either the Recommends or Suggests field so that way openjdk is not being downloaded when not necessary and possibly interfering with a be pre-installed jre -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-1391) Allow Concurrent Schema Migrations
[ https://issues.apache.org/jira/browse/CASSANDRA-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096031#comment-13096031 ] Gary Dusbabek commented on CASSANDRA-1391: -- bq. Merge algorithm is based on isolated schema initialized from merging migration lastVersion point: merging migration applied first then all older migrations, after that Schema.instance gets safely updated. Could you clarify what you mean by merging migration applied first, then all older migrations...? It seems like a side effect of applying a migration is that it can apply other migrations. Does MigrationManager.applyMigrations() need to be updated because of this? What does isolated indicate? Try to put things like flushSystemTables() in a separate patch (ok on the same ticket) to make reviewing the actual changes easier. Would it be possible to create some unit tests for CFMD.diff()? Allow Concurrent Schema Migrations -- Key: CASSANDRA-1391 URL: https://issues.apache.org/jira/browse/CASSANDRA-1391 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Stu Hood Assignee: Pavel Yaskevich Fix For: 1.0 Attachments: CASSANDRA-1391.patch CASSANDRA-1292 fixed multiple migrations started from the same node to properly queue themselves, but it is still possible for migrations initiated on different nodes to conflict and leave the cluster in a bad state. Since the system_add/drop/rename methods are accessible directly from the client API, they should be completely safe for concurrent use. It should be possible to allow for most types of concurrent migrations by converting the UUID schema ID into a VersionVectorClock (as provided by CASSANDRA-580). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-1391) Allow Concurrent Schema Migrations
[ https://issues.apache.org/jira/browse/CASSANDRA-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13092834#comment-13092834 ] Gary Dusbabek commented on CASSANDRA-1391: -- Pavel, can you please rebase? Allow Concurrent Schema Migrations -- Key: CASSANDRA-1391 URL: https://issues.apache.org/jira/browse/CASSANDRA-1391 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Stu Hood Assignee: Pavel Yaskevich Fix For: 1.0 Attachments: CASSANDRA-1391.patch CASSANDRA-1292 fixed multiple migrations started from the same node to properly queue themselves, but it is still possible for migrations initiated on different nodes to conflict and leave the cluster in a bad state. Since the system_add/drop/rename methods are accessible directly from the client API, they should be completely safe for concurrent use. It should be possible to allow for most types of concurrent migrations by converting the UUID schema ID into a VersionVectorClock (as provided by CASSANDRA-580). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3051) On Disk Compression breaks SSL Encryption
[ https://issues.apache.org/jira/browse/CASSANDRA-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13092921#comment-13092921 ] Gary Dusbabek commented on CASSANDRA-3051: -- wait, you tested it locally first, right? It's not difficult to set up a streaming environment locally. On Disk Compression breaks SSL Encryption - Key: CASSANDRA-3051 URL: https://issues.apache.org/jira/browse/CASSANDRA-3051 Project: Cassandra Issue Type: Bug Affects Versions: 1.0 Environment: Trunk Reporter: Benjamin Coverston Assignee: Pavel Yaskevich Fix For: 1.0 Attachments: CASSANDRA-3051.patch Encryption depends on FileStreamTask.write [1] protected member to be called because the SSLFileStreamTask.write overrides this to write back to the server. When enabled, compression circumvents the call and the client does not communicate using an SSL socket back to the server. [1] protected long write(FileChannel fc, PairLong, Long section, long length, long bytesTransferred) throws IOException -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3051) On Disk Compression breaks SSL Encryption
[ https://issues.apache.org/jira/browse/CASSANDRA-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13092930#comment-13092930 ] Gary Dusbabek commented on CASSANDRA-3051: -- Not that I know of. If someone wants to write one it would flesh out these basic steps: # follow the steps for generating a keystore and a trust store here: http://download.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html#CreateKeystore # plug those files into encryption_options in cassandra.yaml # make sure encryption_options.internode_encryption = all in the yaml. I was mostly raising a voice of caution against committing code backed up by statements like I don't see anh reason why it won't... This is usually a prelude to something like we need to quickly release a new version because XYZ broke streaming. Just sayin'. On Disk Compression breaks SSL Encryption - Key: CASSANDRA-3051 URL: https://issues.apache.org/jira/browse/CASSANDRA-3051 Project: Cassandra Issue Type: Bug Affects Versions: 1.0 Environment: Trunk Reporter: Benjamin Coverston Assignee: Pavel Yaskevich Fix For: 1.0 Attachments: CASSANDRA-3051.patch Encryption depends on FileStreamTask.write [1] protected member to be called because the SSLFileStreamTask.write overrides this to write back to the server. When enabled, compression circumvents the call and the client does not communicate using an SSL socket back to the server. [1] protected long write(FileChannel fc, PairLong, Long section, long length, long bytesTransferred) throws IOException -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-3051) On Disk Compression breaks SSL Encryption
[ https://issues.apache.org/jira/browse/CASSANDRA-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13092957#comment-13092957 ] Gary Dusbabek edited comment on CASSANDRA-3051 at 8/29/11 4:25 PM: --- Pavel, I tested SSL prior to committing the feature. I was under the impression that this ticket exists because compression, when enabled, breaks SSL. The implication is that it was working prior, else the ticket would be something more like SSL is broken. was (Author: gdusbabek): Pavel, I tested SSL prior to committing the feature. I was under the impression that ticket exists because compression, when enabled, breaks SSL. The implication is that it was working prior, else the ticket would be something more like SSL is broken. On Disk Compression breaks SSL Encryption - Key: CASSANDRA-3051 URL: https://issues.apache.org/jira/browse/CASSANDRA-3051 Project: Cassandra Issue Type: Bug Affects Versions: 1.0 Environment: Trunk Reporter: Benjamin Coverston Assignee: Pavel Yaskevich Fix For: 1.0 Attachments: CASSANDRA-3051.patch Encryption depends on FileStreamTask.write [1] protected member to be called because the SSLFileStreamTask.write overrides this to write back to the server. When enabled, compression circumvents the call and the client does not communicate using an SSL socket back to the server. [1] protected long write(FileChannel fc, PairLong, Long section, long length, long bytesTransferred) throws IOException -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3051) On Disk Compression breaks SSL Encryption
[ https://issues.apache.org/jira/browse/CASSANDRA-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13092957#comment-13092957 ] Gary Dusbabek commented on CASSANDRA-3051: -- Pavel, I tested SSL prior to committing the feature. I was under the impression that ticket exists because compression, when enabled, breaks SSL. The implication is that it was working prior, else the ticket would be something more like SSL is broken. On Disk Compression breaks SSL Encryption - Key: CASSANDRA-3051 URL: https://issues.apache.org/jira/browse/CASSANDRA-3051 Project: Cassandra Issue Type: Bug Affects Versions: 1.0 Environment: Trunk Reporter: Benjamin Coverston Assignee: Pavel Yaskevich Fix For: 1.0 Attachments: CASSANDRA-3051.patch Encryption depends on FileStreamTask.write [1] protected member to be called because the SSLFileStreamTask.write overrides this to write back to the server. When enabled, compression circumvents the call and the client does not communicate using an SSL socket back to the server. [1] protected long write(FileChannel fc, PairLong, Long section, long length, long bytesTransferred) throws IOException -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3055) Add links to books covering supported Cassandra versions
[ https://issues.apache.org/jira/browse/CASSANDRA-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13087085#comment-13087085 ] Gary Dusbabek commented on CASSANDRA-3055: -- +1 Add links to books covering supported Cassandra versions Key: CASSANDRA-3055 URL: https://issues.apache.org/jira/browse/CASSANDRA-3055 Project: Cassandra Issue Type: Task Components: Documentation website Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Attachments: 3055.txt (The PMC considers stable and oldstable versions to be supported. Currently, that means 0.8.x and 0.7.x.) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3010) Java CQL command-line shell
[ https://issues.apache.org/jira/browse/CASSANDRA-3010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13082625#comment-13082625 ] Gary Dusbabek commented on CASSANDRA-3010: -- What is the argument against CQLSH? It should be easy enough to augment with introspection, etc. Java CQL command-line shell --- Key: CASSANDRA-3010 URL: https://issues.apache.org/jira/browse/CASSANDRA-3010 Project: Cassandra Issue Type: New Feature Components: Tools Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Fix For: 1.0 We need a real CQL shell that: - does not require installing additional environments - includes show keyspaces and other introspection tools - does not break existing cli scripts I.e., it needs to be java, but it should be a new tool instead of replacing the existing cli. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-1391) Allow Concurrent Schema Migrations
[ https://issues.apache.org/jira/browse/CASSANDRA-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13064581#comment-13064581 ] Gary Dusbabek commented on CASSANDRA-1391: -- Bottom line: we need to solve the problem of how to handle conflicts. I view this as a similar problem of handling merge conflicts in change sets: a good subset of the conflicts can be merged automatically because they are independent of each other. But every once a while there is a conflict that needs a manual edit-the solution is not computable because it isn't deterministic. This is currently addressed right now by strictly enforcing the relationship of a migration with its predecessor to ensure that all migrations are applied serially. There is probably a pragmatic approach that I'm able to see because the merge-conflict problem makes it a non-starter for me. Allow Concurrent Schema Migrations -- Key: CASSANDRA-1391 URL: https://issues.apache.org/jira/browse/CASSANDRA-1391 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Stu Hood Assignee: Gary Dusbabek CASSANDRA-1292 fixed multiple migrations started from the same node to properly queue themselves, but it is still possible for migrations initiated on different nodes to conflict and leave the cluster in a bad state. Since the system_add/drop/rename methods are accessible directly from the client API, they should be completely safe for concurrent use. It should be possible to allow for most types of concurrent migrations by converting the UUID schema ID into a VersionVectorClock (as provided by CASSANDRA-580). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-1391) Allow Concurrent Schema Migrations
[ https://issues.apache.org/jira/browse/CASSANDRA-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13064581#comment-13064581 ] Gary Dusbabek edited comment on CASSANDRA-1391 at 7/13/11 3:04 PM: --- Bottom line: we need to solve the problem of how to handle conflicts. I view this as a similar problem of handling merge conflicts in change sets: a good subset of the conflicts can be merged automatically because they are independent of each other. But every once a while there is a conflict that needs a manual edit-the solution is not computable because it isn't deterministic. This is currently addressed right now by strictly enforcing the relationship of a migration with its predecessor to ensure that all migrations are applied serially. There is probably a pragmatic approach that I'm not able to see because the merge-conflict problem makes it a non-starter for me. was (Author: gdusbabek): Bottom line: we need to solve the problem of how to handle conflicts. I view this as a similar problem of handling merge conflicts in change sets: a good subset of the conflicts can be merged automatically because they are independent of each other. But every once a while there is a conflict that needs a manual edit-the solution is not computable because it isn't deterministic. This is currently addressed right now by strictly enforcing the relationship of a migration with its predecessor to ensure that all migrations are applied serially. There is probably a pragmatic approach that I'm able to see because the merge-conflict problem makes it a non-starter for me. Allow Concurrent Schema Migrations -- Key: CASSANDRA-1391 URL: https://issues.apache.org/jira/browse/CASSANDRA-1391 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Stu Hood Assignee: Gary Dusbabek CASSANDRA-1292 fixed multiple migrations started from the same node to properly queue themselves, but it is still possible for migrations initiated on different nodes to conflict and leave the cluster in a bad state. Since the system_add/drop/rename methods are accessible directly from the client API, they should be completely safe for concurrent use. It should be possible to allow for most types of concurrent migrations by converting the UUID schema ID into a VersionVectorClock (as provided by CASSANDRA-580). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-1391) Allow Concurrent Schema Migrations
[ https://issues.apache.org/jira/browse/CASSANDRA-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13064626#comment-13064626 ] Gary Dusbabek commented on CASSANDRA-1391: -- bq. Seems like if we could come up with some way of ordering schema components A lamport-ish clock consisting of node name and counter/timestamp would probably be sufficient for ordering. This could be used with an approach that quarantines schema changes for a period of time. This would allow for changes to come in from throughout the cluster and would allow them to be reordered before being applied. I think this is sensible, but still gives some rope from which we can hang ourselves--the strict predecessor relationship is gone and we'd have to trust that nodes would be doing the right thing (by applying migrations) independently after the quarantine is over. Allow Concurrent Schema Migrations -- Key: CASSANDRA-1391 URL: https://issues.apache.org/jira/browse/CASSANDRA-1391 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Stu Hood Assignee: Gary Dusbabek CASSANDRA-1292 fixed multiple migrations started from the same node to properly queue themselves, but it is still possible for migrations initiated on different nodes to conflict and leave the cluster in a bad state. Since the system_add/drop/rename methods are accessible directly from the client API, they should be completely safe for concurrent use. It should be possible to allow for most types of concurrent migrations by converting the UUID schema ID into a VersionVectorClock (as provided by CASSANDRA-580). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-1391) Allow Concurrent Schema Migrations
[ https://issues.apache.org/jira/browse/CASSANDRA-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13064363#comment-13064363 ] Gary Dusbabek commented on CASSANDRA-1391: -- Not with the current state of things. Allow Concurrent Schema Migrations -- Key: CASSANDRA-1391 URL: https://issues.apache.org/jira/browse/CASSANDRA-1391 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Stu Hood Assignee: Gary Dusbabek CASSANDRA-1292 fixed multiple migrations started from the same node to properly queue themselves, but it is still possible for migrations initiated on different nodes to conflict and leave the cluster in a bad state. Since the system_add/drop/rename methods are accessible directly from the client API, they should be completely safe for concurrent use. It should be possible to allow for most types of concurrent migrations by converting the UUID schema ID into a VersionVectorClock (as provided by CASSANDRA-580). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2715) simplify schema reconciliation
[ https://issues.apache.org/jira/browse/CASSANDRA-2715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13048537#comment-13048537 ] Gary Dusbabek commented on CASSANDRA-2715: -- +1 simplify schema reconciliation -- Key: CASSANDRA-2715 URL: https://issues.apache.org/jira/browse/CASSANDRA-2715 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.0 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 0.8.1 Attachments: 2715.txt, 2715.txt Currently, schema migrations can be replayed from one node to another in any of three ways: - a node processes a migration from a client, and pushes it to all live nodes (Migration.announce on the source) - a node sees that another node's schema version is older than his (MigrationManager.onChange on the source) - a node sees that his own schema version is older than another's and makes an explicit request (MigrationManager.onChange on the target, DefinitionsAnnounceVerbHandler on the source) The last of these is an optimization that isn't worth the extra complexity -- under normal conditions, the initial announce from the coordinator updates everyone, and in recovery situations the latency gain of #3 over #2 is only a few seconds. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2714) Throttle migration replay
[
https://issues.apache.org/jira/browse/CASSANDRA-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13039911#comment-13039911
]
Gary Dusbabek commented on CASSANDRA-2714:
--
+1
Throttle migration replay
-
Key: CASSANDRA-2714
URL: https://issues.apache.org/jira/browse/CASSANDRA-2714
Project: Cassandra
Issue Type: Improvement
Affects Versions: 0.7.0
Reporter: Jonathan Ellis
Assignee: Jonathan Ellis
Priority: Minor
Fix For: 0.7.7, 0.8.1
Attachments: 2714-v2.txt, 2714.txt
As reported on the mailing list,
{noformat}
- I have a lot of schema updates (there are 2067 rows in the system.Schema
CF).
- The live node loads migrations 1-1000, and sends them to the recovering
node (Migration.getLocalMigrations())
- Soon afterwards, the live node checks the schema version on the recovering
node and finds it has moved by a little - say it has applied the first 3
migrations. It then loads migrations 3-1003, and sends them to the node.
- This process is repeated very quickly (sends migrations 6-1006, 9-1009,
etc).
{noformat}
The source of the problem is that MigrationManager.onChange will send out a
full (up to 1000 migrations) replay, every time the target's schema version
changes.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-1765) Compare serialization metrics between a few frameworks.
[ https://issues.apache.org/jira/browse/CASSANDRA-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13038246#comment-13038246 ] Gary Dusbabek commented on CASSANDRA-1765: -- @Tatu: the patches were never committed. There didn't seem much point after I realized that all libraries were roughly comparable. Plus, the test has dependencies that are outside the scope of cassandra. The v2 patches are the most recent, but I suspect they are rather outdated. Compare serialization metrics between a few frameworks. --- Key: CASSANDRA-1765 URL: https://issues.apache.org/jira/browse/CASSANDRA-1765 Project: Cassandra Issue Type: Task Reporter: Gary Dusbabek Assignee: Gary Dusbabek Priority: Minor Fix For: 0.8 beta 1 Attachments: 0001-CASSANDRA-1765-allocate-memory-for-binary-deserializ.patch, 0001-inserts-codes-for-properly-calling-full-GC-into-Mess.patch, MessageSerializationThriftTest.java, v1-0001-CASSANDRA-1765-create-reader-writer-once.txt, v1-0001-CASSANDRA-1765-don-t-ser-dser-schema-string.txt, v1-0001-IDL-and-RangeSliceCommand-alteration.txt, v1-0002-msgpack-dependencies.txt, v1-0003-serialization-tests.txt, v1-0004-jvm-warmup-and-other-improvements.-by-Muga-Nishizawa.txt, v2-0001-CASSANDRA-1765-create-reader-writer-once.txt, v2-0001-IDL-and-RangeSliceCommand-alteration.txt, v2-0002-msgpack-dependencies.txt, v2-0003-serialization-tests.txt, v2-0004-jvm-warmup-and-other-improvements.-by-Muga-Nishizawa.txt, v2-0005-don-t-bother-with-sending-schema-on-avro-tests.-patch-.txt, v2-0006-allocate-memory-more-efficently-for-msgpack.-patch-by-.txt Compare serialization performance of Cassandra (ICompactSerializer), Thrift, Avro and Messagepack. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-1451) Shutting down a node cleanly still kills client requests when the node goes down
[ https://issues.apache.org/jira/browse/CASSANDRA-1451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13033806#comment-13033806 ] Gary Dusbabek commented on CASSANDRA-1451: -- We do have such a control. Shutting down a node cleanly still kills client requests when the node goes down -- Key: CASSANDRA-1451 URL: https://issues.apache.org/jira/browse/CASSANDRA-1451 Project: Cassandra Issue Type: New Feature Components: Core Reporter: David King Priority: Minor Fix For: 1.0 Shutting down a node, even more cleanly through drain, still kills some requests with timeoutexceptions. Ideally, operations would not be sent at all to nodes that are known to be shutting down, perhaps by shutting down gossip before starting the draining process. Other nodes will still need to have the phi convict threshold exceeded, but presumably that's usually shorter than drain -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-2640) `ant clean build test` is broken
[ https://issues.apache.org/jira/browse/CASSANDRA-2640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek resolved CASSANDRA-2640. -- Resolution: Not A Problem Dear ppls, Please upgrade your ants. That is all. Thanks you. `ant clean build test` is broken Key: CASSANDRA-2640 URL: https://issues.apache.org/jira/browse/CASSANDRA-2640 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.5, 0.8.0 beta 2 Reporter: Gary Dusbabek Assignee: Stephen Connolly `ant clean build` works. `ant test` works. `ant clean build test` is broken. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2638) Migrations announce on startup attempts to set local gossip state before gossiper is started.
Migrations announce on startup attempts to set local gossip state before gossiper is started. - Key: CASSANDRA-2638 URL: https://issues.apache.org/jira/browse/CASSANDRA-2638 Project: Cassandra Issue Type: Bug Affects Versions: 0.8.0 beta 2, 0.7.5 Reporter: Gary Dusbabek AbstractCassandraDemon calls MigrationManager.applyMigrations() before the gossiper is initialized (via SS.initServer()). MM.applyMigrations tries to set the local gossip state before it is initialized via G.start(). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-2638) Migrations announce on startup attempts to set local gossip state before gossiper is started.
[ https://issues.apache.org/jira/browse/CASSANDRA-2638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek reassigned CASSANDRA-2638: Assignee: Gary Dusbabek Migrations announce on startup attempts to set local gossip state before gossiper is started. - Key: CASSANDRA-2638 URL: https://issues.apache.org/jira/browse/CASSANDRA-2638 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.5, 0.8.0 beta 2 Reporter: Gary Dusbabek Assignee: Gary Dusbabek AbstractCassandraDemon calls MigrationManager.applyMigrations() before the gossiper is initialized (via SS.initServer()). MM.applyMigrations tries to set the local gossip state before it is initialized via G.start(). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2638) Migrations announce on startup attempts to set local gossip state before gossiper is started.
[ https://issues.apache.org/jira/browse/CASSANDRA-2638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13031893#comment-13031893 ] Gary Dusbabek commented on CASSANDRA-2638: -- java.lang.NullPointerException at org.apache.cassandra.gms.Gossiper.addLocalApplicationState(Gossiper.java:883) at org.apache.cassandra.service.MigrationManager.passiveAnnounce(MigrationManager.java:125) at org.apache.cassandra.service.MigrationManager.applyMigrations(MigrationManager.java:183) at org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:182) at org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:313) at org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:80) Migrations announce on startup attempts to set local gossip state before gossiper is started. - Key: CASSANDRA-2638 URL: https://issues.apache.org/jira/browse/CASSANDRA-2638 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.5, 0.8.0 beta 2 Reporter: Gary Dusbabek Assignee: Gary Dusbabek AbstractCassandraDemon calls MigrationManager.applyMigrations() before the gossiper is initialized (via SS.initServer()). MM.applyMigrations tries to set the local gossip state before it is initialized via G.start(). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2638) Migrations announce on startup attempts to set local gossip state before gossiper is started.
[ https://issues.apache.org/jira/browse/CASSANDRA-2638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-2638: - Attachment: v1-0001-init-ep-state-when-prior-to-gossiper-start.txt Migrations announce on startup attempts to set local gossip state before gossiper is started. - Key: CASSANDRA-2638 URL: https://issues.apache.org/jira/browse/CASSANDRA-2638 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.5, 0.8.0 beta 2 Reporter: Gary Dusbabek Assignee: Gary Dusbabek Attachments: v1-0001-init-ep-state-when-prior-to-gossiper-start.txt AbstractCassandraDemon calls MigrationManager.applyMigrations() before the gossiper is initialized (via SS.initServer()). MM.applyMigrations tries to set the local gossip state before it is initialized via G.start(). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2640) `ant clean build test` is broken
`ant clean build test` is broken Key: CASSANDRA-2640 URL: https://issues.apache.org/jira/browse/CASSANDRA-2640 Project: Cassandra Issue Type: Bug Affects Versions: 0.8.0 beta 2, 0.7.5 Reporter: Gary Dusbabek Assignee: Stephen Connolly `ant clean build` works. `ant test` works. `ant clean build test` is broken. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2536) Schema disagreements when using connections to multiple hosts
[ https://issues.apache.org/jira/browse/CASSANDRA-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13026953#comment-13026953 ] Gary Dusbabek commented on CASSANDRA-2536: -- I think timestamp comparisons will be fine. Schema disagreements when using connections to multiple hosts - Key: CASSANDRA-2536 URL: https://issues.apache.org/jira/browse/CASSANDRA-2536 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8 beta 1 Environment: Two node 0.8-beta1 cluster with one seed and JNA. Reporter: Tyler Hobbs Assignee: Tyler Hobbs Attachments: 2536-compare-timestamp.txt, schema_disagree.py If you have two thrift connections open to different nodes and you create a KS using the first, then a CF in that KS using the second, you wind up with a schema disagreement even if you wait/sleep after creating the KS. The attached script reproduces the issue using pycassa (1.0.6 should work fine, although it has the 0.7 thrift-gen code). It's also reproducible by hand with two cassandra-cli sessions. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2536) Schema disagreements when using connections to multiple hosts
[ https://issues.apache.org/jira/browse/CASSANDRA-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13026292#comment-13026292 ] Gary Dusbabek commented on CASSANDRA-2536: -- bq. any thoughts... I was going to add some jmx to get the last N schema versions (seems like it would be handy anyway and will be necessary if we ever get the rollback pony). Send schema to node A, verify that schema is propagated to B, send schema to B and watch the problem happen. The code to start looking at are the Definitions*VerbHandlers. Schema version is tracked in two places: gossip and in DatabaseDescriptor.defsVersion. Make sure those are reasonably in sync (was the sourced of one bug in the past). Schema disagreements when using connections to multiple hosts - Key: CASSANDRA-2536 URL: https://issues.apache.org/jira/browse/CASSANDRA-2536 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8 beta 1 Environment: Two node 0.8-beta1 cluster with one seed and JNA. Reporter: Tyler Hobbs Assignee: Gary Dusbabek Attachments: schema_disagree.py If you have two thrift connections open to different nodes and you create a KS using the first, then a CF in that KS using the second, you wind up with a schema disagreement even if you wait/sleep after creating the KS. The attached script reproduces the issue using pycassa (1.0.6 should work fine, although it has the 0.7 thrift-gen code). It's also reproducible by hand with two cassandra-cli sessions. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2536) Schema disagreements when using connections to multiple hosts
[ https://issues.apache.org/jira/browse/CASSANDRA-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13026684#comment-13026684 ] Gary Dusbabek commented on CASSANDRA-2536: -- bq. Sometimes the v1 UUID generated by the second node has an earlier timestamp than the current schema UUID has. Wouldn't that update be DOA then? I thought we checked to make sure the new migration compared after the current migration (as well as making sure the new migration's previous version matches with the current version). bq. A node shouldn't accept a schema change if the timestamp for the new schema would be earlier than its current schema. If the clocks are *that* far off sync, I think the cluster has bigger problems (like writes not being applied). Plus, it would be easy for a node whose clock is way head to 'poison' schema updates from the rest of the cluster who are, in effect, behind the times. bq. Schema modification calls should accept an optional client-side timestamp that will be used for the v1 UUID. Seems like a better approach. Schema disagreements when using connections to multiple hosts - Key: CASSANDRA-2536 URL: https://issues.apache.org/jira/browse/CASSANDRA-2536 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8 beta 1 Environment: Two node 0.8-beta1 cluster with one seed and JNA. Reporter: Tyler Hobbs Assignee: Tyler Hobbs Attachments: schema_disagree.py If you have two thrift connections open to different nodes and you create a KS using the first, then a CF in that KS using the second, you wind up with a schema disagreement even if you wait/sleep after creating the KS. The attached script reproduces the issue using pycassa (1.0.6 should work fine, although it has the 0.7 thrift-gen code). It's also reproducible by hand with two cassandra-cli sessions. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2453) node.js cql driver
[ https://issues.apache.org/jira/browse/CASSANDRA-2453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13022871#comment-13022871 ] Gary Dusbabek commented on CASSANDRA-2453: -- https://github.com/racker/node-cassandra-client FWIW, we're going to let people poke at it on github for a while before we submit it to the cassandra src tree. node.js cql driver -- Key: CASSANDRA-2453 URL: https://issues.apache.org/jira/browse/CASSANDRA-2453 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Gary Dusbabek Assignee: Gary Dusbabek Priority: Minor Fix For: 0.8.1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2335) Windows: Test org.apache.cassandra.streaming.SerializationsTest FAILED
[ https://issues.apache.org/jira/browse/CASSANDRA-2335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13022325#comment-13022325 ] Gary Dusbabek commented on CASSANDRA-2335: -- I strongly suspect this error is due to the paths in the serialized PendingFiles. They hate Windows. Windows: Test org.apache.cassandra.streaming.SerializationsTest FAILED -- Key: CASSANDRA-2335 URL: https://issues.apache.org/jira/browse/CASSANDRA-2335 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 Environment: Windows Reporter: Benjamin Coverston Assignee: Joaquin Casares Priority: Minor Fix For: 0.7.5 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2488) cqlsh errors on comments that end with a semicolon
[ https://issues.apache.org/jira/browse/CASSANDRA-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13021680#comment-13021680 ] Gary Dusbabek commented on CASSANDRA-2488: -- +1 cqlsh errors on comments that end with a semicolon -- Key: CASSANDRA-2488 URL: https://issues.apache.org/jira/browse/CASSANDRA-2488 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.8 Environment: OS X 10.6.7 $ java -version java version 1.6.0_24 Java(TM) SE Runtime Environment (build 1.6.0_24-b07-334-10M3326) Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02-334, mixed mode) (This stuff isn't really important. It's a bug in a Python script) Reporter: Geoff Greer Assignee: Eric Evans Priority: Minor Labels: cql Fix For: 0.8 Attachments: v2-0001-CASSANDRA-2488-teach-cqlsh-to-ignore-comments.txt Commented-out lines that end in a semicolon cause an error. Examples: cqlsh -- CREATE KEYSPACE ELE WITH replication_factor = 3 AND strategy_class = SimpleStrategy AND strategy_options:replication_factor=3; Bad Request: line 0:-1 no viable alternative at input 'EOF' cqlsh -- CREATE KEYSPACE ELE WITH replication_factor = 3 AND strategy_class = SimpleStrategy AND strategy_options:replication_factor=3 ... ... ... ; Bad Request: line 2:0 no viable alternative at input ';' cqlsh -- ; Bad Request: line 0:-1 no viable alternative at input 'EOF' cqlsh --; Bad Request: line 0:-1 no viable alternative at input 'EOF' As long as there's a line with valid CQL before the semicolon, things work fine though. I'm pretty sure the problem is on line 75 of cqlsh: if not line.endswith(;): self.set_prompt(Shell.continue_prompt) return None A quick workaround would be to kill the pretty continue prompt. A more involved fix would detect whether or not the semicolon was in a comment. This is harder than it sounds, since /* and */ allow multi-line comments. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2410) JDBC ResultSet does not honor column value typing for the CF and uses default validator for all column value types.
[
https://issues.apache.org/jira/browse/CASSANDRA-2410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Dusbabek updated CASSANDRA-2410:
-
Attachment: v1-0001-honor-specific-column-validators-in-JDBC-driver.txt
JDBC ResultSet does not honor column value typing for the CF and uses default
validator for all column value types.
---
Key: CASSANDRA-2410
URL: https://issues.apache.org/jira/browse/CASSANDRA-2410
Project: Cassandra
Issue Type: Bug
Components: API
Reporter: Rick Shaw
Assignee: Gary Dusbabek
Priority: Minor
Labels: cql
Fix For: 0.8
Attachments:
v1-0001-honor-specific-column-validators-in-JDBC-driver.txt
Assume a CF declared in CQL as :
{code}
CREATE COLUMNFAMILY TestCF(KEY utf8 PRIMARY KEY,description utf8, anumber int)
WITH comparator = ascii AND default_validation = long;
{code}
If the {{ResultSet}} is fetched thusly:
{code}
Statement stmt = con.createStatement();
ResultSet rs = stmt.executeQuery(query);
String description;
Integer anumber;
while (rs.next())
{
description = rs.getString(1);
System.out.print(description : + description);
anumber = rs.getInt(2);
System.out.print(anumber : + anumber);
}
{code}
It will immediately fail with a message of:
{code}
org.apache.cassandra.db.marshal.MarshalException: A long is exactly 8 bytes:
16
at org.apache.cassandra.db.marshal.LongType.getString(LongType.java:66)
at org.apache.cassandra.cql.jdbc.TypedColumn.init(TypedColumn.java:45)
at
org.apache.cassandra.cql.jdbc.ColumnDecoder.makeCol(ColumnDecoder.java:158)
at
org.apache.cassandra.cql.jdbc.CassandraResultSet.next(CassandraResultSet.java:1073)
at da.access.testing.TestJDBC.selectAll(TestJDBC.java:83)
...
{code}
It appears that the {{makeCol}} method of {{ColumnDecoder.java}} chooses NOT
to use the {{CfDef}} to look up the possible occurrence of a column? That's
not right. Right?
{code}
/** constructs a typed column */
public TypedColumn makeCol(String keyspace, String columnFamily, byte[]
name, byte[] value)
{
CfDef cfDef = cfDefs.get(String.format(%s.%s, keyspace,
columnFamily));
AbstractType comparator = getComparator(keyspace, columnFamily,
Specifier.Comparator, cfDef);
AbstractType validator = getComparator(keyspace, columnFamily,
Specifier.Validator, null);
return new TypedColumn(comparator, name, validator, value);
}
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-2467) key validator not getting set when adding a keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-2467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek resolved CASSANDRA-2467. -- Resolution: Fixed committed. key validator not getting set when adding a keyspace Key: CASSANDRA-2467 URL: https://issues.apache.org/jira/browse/CASSANDRA-2467 Project: Cassandra Issue Type: Bug Components: Core Reporter: Gary Dusbabek Assignee: Gary Dusbabek Priority: Minor Fix For: 0.8 Attachments: v1-0001-set-requested-key-validator-when-creating-a-keyspace.txt needs to be applied CassandraServer.convertToCFMetaData() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2450) incompatibility w/ 0.7 schemas
[
https://issues.apache.org/jira/browse/CASSANDRA-2450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13020309#comment-13020309
]
Gary Dusbabek commented on CASSANDRA-2450:
--
+1
incompatibility w/ 0.7 schemas
--
Key: CASSANDRA-2450
URL: https://issues.apache.org/jira/browse/CASSANDRA-2450
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.8
Reporter: Jonathan Ellis
Assignee: Jonathan Ellis
Fix For: 0.8
Attachments: 2450.txt
If you create a SimpleStrategy keyspace under 0.7, then switch to 0.8, you
will get this error on startup:
{noformat}
ERROR 14:31:41,725 Exception encountered during startup.
java.lang.RuntimeException:
org.apache.cassandra.config.ConfigurationException: SimpleStrategy requires a
replication_factor strategy option.
at org.apache.cassandra.db.Table.init(Table.java:277)
at org.apache.cassandra.db.Table.open(Table.java:109)
at
org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:160)
at
org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:314)
at
org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:80)
Caused by: org.apache.cassandra.config.ConfigurationException: SimpleStrategy
requires a replication_factor strategy option.
at
org.apache.cassandra.locator.SimpleStrategy.validateOptions(SimpleStrategy.java:75)
at
org.apache.cassandra.locator.AbstractReplicationStrategy.createReplicationStrategy(AbstractReplicationStrategy.java:262)
at
org.apache.cassandra.db.Table.createReplicationStrategy(Table.java:327)
at org.apache.cassandra.db.Table.init(Table.java:273)
... 4 more
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2467) key validator not getting set when adding a keyspace
key validator not getting set when adding a keyspace Key: CASSANDRA-2467 URL: https://issues.apache.org/jira/browse/CASSANDRA-2467 Project: Cassandra Issue Type: Bug Components: Core Reporter: Gary Dusbabek Assignee: Gary Dusbabek Priority: Minor Fix For: 0.8 needs to be applied CassandraServer.convertToCFMetaData() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2467) key validator not getting set when adding a keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-2467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-2467: - Attachment: v1-0001-set-requested-key-validator-when-creating-a-keyspace.txt key validator not getting set when adding a keyspace Key: CASSANDRA-2467 URL: https://issues.apache.org/jira/browse/CASSANDRA-2467 Project: Cassandra Issue Type: Bug Components: Core Reporter: Gary Dusbabek Assignee: Gary Dusbabek Priority: Minor Fix For: 0.8 Attachments: v1-0001-set-requested-key-validator-when-creating-a-keyspace.txt needs to be applied CassandraServer.convertToCFMetaData() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2467) key validator not getting set when adding a keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-2467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13019504#comment-13019504 ] Gary Dusbabek commented on CASSANDRA-2467: -- todo: we could use a system test to verify that non-default CF and KS options are actually applied. key validator not getting set when adding a keyspace Key: CASSANDRA-2467 URL: https://issues.apache.org/jira/browse/CASSANDRA-2467 Project: Cassandra Issue Type: Bug Components: Core Reporter: Gary Dusbabek Assignee: Gary Dusbabek Priority: Minor Fix For: 0.8 Attachments: v1-0001-set-requested-key-validator-when-creating-a-keyspace.txt needs to be applied CassandraServer.convertToCFMetaData() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2056) Need a way of flattening schemas.
[ https://issues.apache.org/jira/browse/CASSANDRA-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-2056: - Attachment: v2-0003-a-way-to-upgrade-schema-when-protocol-version-changes.txt v2-0002-bail-on-migrations-originating-from-newer-protocol-ver.txt v2-0001-convert-MigrationManager-into-a-singleton.txt Need a way of flattening schemas. - Key: CASSANDRA-2056 URL: https://issues.apache.org/jira/browse/CASSANDRA-2056 Project: Cassandra Issue Type: Improvement Reporter: Gary Dusbabek Assignee: Gary Dusbabek Fix For: 0.8 Attachments: v2-0001-convert-MigrationManager-into-a-singleton.txt, v2-0002-bail-on-migrations-originating-from-newer-protocol-ver.txt, v2-0003-a-way-to-upgrade-schema-when-protocol-version-changes.txt For all of our trying not to, we still managed to screw this up. Schema updates currently contain a serialized RowMutation stored as a column value. When a node needs updated schema, it requests these values, deserializes them and applies them. As the serialization scheme for RowMutation changes over time (this is inevitable), those old migrations will become incompatible with newer implementations of the RowMutation deserializer. This means that when new nodes come online, they'll get migration messages that they have trouble deserializing. (Remember, we've only made the promise that we'll be backwards compatible for one version--see CASSANDRA-1015--even though we'd eventually have this problem without that guarantee.) What I propose is a cluster command to flatten the schema prior to upgrading. This would basically purge the old schema updates and replace them with a single serialized migration (serialized in the current protocol version). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2056) Need a way of flattening schemas.
[ https://issues.apache.org/jira/browse/CASSANDRA-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13018339#comment-13018339 ] Gary Dusbabek commented on CASSANDRA-2056: -- Attached rebased v2. CliTest fails though, so not committing yet. Need a way of flattening schemas. - Key: CASSANDRA-2056 URL: https://issues.apache.org/jira/browse/CASSANDRA-2056 Project: Cassandra Issue Type: Improvement Reporter: Gary Dusbabek Assignee: Gary Dusbabek Fix For: 0.8 Attachments: v2-0001-convert-MigrationManager-into-a-singleton.txt, v2-0002-bail-on-migrations-originating-from-newer-protocol-ver.txt, v2-0003-a-way-to-upgrade-schema-when-protocol-version-changes.txt For all of our trying not to, we still managed to screw this up. Schema updates currently contain a serialized RowMutation stored as a column value. When a node needs updated schema, it requests these values, deserializes them and applies them. As the serialization scheme for RowMutation changes over time (this is inevitable), those old migrations will become incompatible with newer implementations of the RowMutation deserializer. This means that when new nodes come online, they'll get migration messages that they have trouble deserializing. (Remember, we've only made the promise that we'll be backwards compatible for one version--see CASSANDRA-1015--even though we'd eventually have this problem without that guarantee.) What I propose is a cluster command to flatten the schema prior to upgrading. This would basically purge the old schema updates and replace them with a single serialized migration (serialized in the current protocol version). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2056) Need a way of flattening schemas.
[ https://issues.apache.org/jira/browse/CASSANDRA-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-2056: - Attachment: (was: v1-0001-convert-MigrationManager-into-a-singleton.txt) Need a way of flattening schemas. - Key: CASSANDRA-2056 URL: https://issues.apache.org/jira/browse/CASSANDRA-2056 Project: Cassandra Issue Type: Improvement Reporter: Gary Dusbabek Assignee: Gary Dusbabek Fix For: 0.8 Attachments: v2-0001-convert-MigrationManager-into-a-singleton.txt, v2-0002-bail-on-migrations-originating-from-newer-protocol-ver.txt, v2-0003-a-way-to-upgrade-schema-when-protocol-version-changes.txt For all of our trying not to, we still managed to screw this up. Schema updates currently contain a serialized RowMutation stored as a column value. When a node needs updated schema, it requests these values, deserializes them and applies them. As the serialization scheme for RowMutation changes over time (this is inevitable), those old migrations will become incompatible with newer implementations of the RowMutation deserializer. This means that when new nodes come online, they'll get migration messages that they have trouble deserializing. (Remember, we've only made the promise that we'll be backwards compatible for one version--see CASSANDRA-1015--even though we'd eventually have this problem without that guarantee.) What I propose is a cluster command to flatten the schema prior to upgrading. This would basically purge the old schema updates and replace them with a single serialized migration (serialized in the current protocol version). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2056) Need a way of flattening schemas.
[ https://issues.apache.org/jira/browse/CASSANDRA-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-2056: - Attachment: (was: v1-0002-bail-on-migrations-originating-from-newer-protocol-ver.txt) Need a way of flattening schemas. - Key: CASSANDRA-2056 URL: https://issues.apache.org/jira/browse/CASSANDRA-2056 Project: Cassandra Issue Type: Improvement Reporter: Gary Dusbabek Assignee: Gary Dusbabek Fix For: 0.8 Attachments: v2-0001-convert-MigrationManager-into-a-singleton.txt, v2-0002-bail-on-migrations-originating-from-newer-protocol-ver.txt, v2-0003-a-way-to-upgrade-schema-when-protocol-version-changes.txt For all of our trying not to, we still managed to screw this up. Schema updates currently contain a serialized RowMutation stored as a column value. When a node needs updated schema, it requests these values, deserializes them and applies them. As the serialization scheme for RowMutation changes over time (this is inevitable), those old migrations will become incompatible with newer implementations of the RowMutation deserializer. This means that when new nodes come online, they'll get migration messages that they have trouble deserializing. (Remember, we've only made the promise that we'll be backwards compatible for one version--see CASSANDRA-1015--even though we'd eventually have this problem without that guarantee.) What I propose is a cluster command to flatten the schema prior to upgrading. This would basically purge the old schema updates and replace them with a single serialized migration (serialized in the current protocol version). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2056) Need a way of flattening schemas.
[ https://issues.apache.org/jira/browse/CASSANDRA-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-2056: - Attachment: (was: v1-0003-a-way-to-upgrade-schema-when-protocol-version-changes.txt) Need a way of flattening schemas. - Key: CASSANDRA-2056 URL: https://issues.apache.org/jira/browse/CASSANDRA-2056 Project: Cassandra Issue Type: Improvement Reporter: Gary Dusbabek Assignee: Gary Dusbabek Fix For: 0.8 Attachments: v2-0001-convert-MigrationManager-into-a-singleton.txt, v2-0002-bail-on-migrations-originating-from-newer-protocol-ver.txt, v2-0003-a-way-to-upgrade-schema-when-protocol-version-changes.txt For all of our trying not to, we still managed to screw this up. Schema updates currently contain a serialized RowMutation stored as a column value. When a node needs updated schema, it requests these values, deserializes them and applies them. As the serialization scheme for RowMutation changes over time (this is inevitable), those old migrations will become incompatible with newer implementations of the RowMutation deserializer. This means that when new nodes come online, they'll get migration messages that they have trouble deserializing. (Remember, we've only made the promise that we'll be backwards compatible for one version--see CASSANDRA-1015--even though we'd eventually have this problem without that guarantee.) What I propose is a cluster command to flatten the schema prior to upgrading. This would basically purge the old schema updates and replace them with a single serialized migration (serialized in the current protocol version). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2453) node.js cql driver
node.js cql driver -- Key: CASSANDRA-2453 URL: https://issues.apache.org/jira/browse/CASSANDRA-2453 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Gary Dusbabek Assignee: Gary Dusbabek Priority: Minor Fix For: 0.8 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2439) CQL should allow no compression (UTF8 strings?).
CQL should allow no compression (UTF8 strings?). Key: CASSANDRA-2439 URL: https://issues.apache.org/jira/browse/CASSANDRA-2439 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Gary Dusbabek Assignee: Gary Dusbabek Fix For: 0.8 I can envision some truly pathetic environments that cannot even handle utf8, so we ought to have a BASE64 option too. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2439) CQL should allow no compression (UTF8 strings?).
[ https://issues.apache.org/jira/browse/CASSANDRA-2439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-2439: - Attachment: v1-0003-handle-Compression.NONE-in-CassandraServer.txt v1-0002-updated-thrif-gen-java.txt v1-0001-add-Compression.NONE.txt CQL should allow no compression (UTF8 strings?). Key: CASSANDRA-2439 URL: https://issues.apache.org/jira/browse/CASSANDRA-2439 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Gary Dusbabek Assignee: Gary Dusbabek Fix For: 0.8 Attachments: v1-0001-add-Compression.NONE.txt, v1-0002-updated-thrif-gen-java.txt, v1-0003-handle-Compression.NONE-in-CassandraServer.txt I can envision some truly pathetic environments that cannot even handle utf8, so we ought to have a BASE64 option too. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2412) Upgrade to thrift 0.6
[ https://issues.apache.org/jira/browse/CASSANDRA-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-2412: - Attachment: v1-0003-Adjust-CustomTThreadPoolServer-for-thrift-updates.txt v1-0002-update-thrift-generated-code.txt v1-0001-upgrade-thrift-jar.txt Upgrade to thrift 0.6 - Key: CASSANDRA-2412 URL: https://issues.apache.org/jira/browse/CASSANDRA-2412 Project: Cassandra Issue Type: Task Components: Core Reporter: Gary Dusbabek Assignee: Gary Dusbabek Priority: Trivial Labels: thrift Fix For: 0.8 Attachments: v1-0001-upgrade-thrift-jar.txt, v1-0001-upgrade-thrift-jar.txt, v1-0002-update-thrift-generated-code.txt, v1-0002-update-thrift-generated-code.txt, v1-0003-Adjust-CustomTThreadPoolServer-for-thrift-updates.txt, v1-0003-Adjust-CustomTThreadPoolServer-for-thrift-updates.txt -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2412) Upgrade to thrift 0.6
[ https://issues.apache.org/jira/browse/CASSANDRA-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-2412: - Attachment: v1-0003-Adjust-CustomTThreadPoolServer-for-thrift-updates.txt v1-0002-update-thrift-generated-code.txt v1-0001-upgrade-thrift-jar.txt Upgrade to thrift 0.6 - Key: CASSANDRA-2412 URL: https://issues.apache.org/jira/browse/CASSANDRA-2412 Project: Cassandra Issue Type: Task Components: Core Reporter: Gary Dusbabek Assignee: Gary Dusbabek Priority: Trivial Labels: thrift Fix For: 0.8 Attachments: v1-0001-upgrade-thrift-jar.txt, v1-0001-upgrade-thrift-jar.txt, v1-0002-update-thrift-generated-code.txt, v1-0002-update-thrift-generated-code.txt, v1-0003-Adjust-CustomTThreadPoolServer-for-thrift-updates.txt, v1-0003-Adjust-CustomTThreadPoolServer-for-thrift-updates.txt -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2412) Upgrade to thrift 0.6
[ https://issues.apache.org/jira/browse/CASSANDRA-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-2412: - Attachment: (was: v1-0001-upgrade-thrift-jar.txt) Upgrade to thrift 0.6 - Key: CASSANDRA-2412 URL: https://issues.apache.org/jira/browse/CASSANDRA-2412 Project: Cassandra Issue Type: Task Components: Core Reporter: Gary Dusbabek Assignee: Gary Dusbabek Priority: Trivial Labels: thrift Fix For: 0.8 Attachments: v1-0001-upgrade-thrift-jar.txt, v1-0002-update-thrift-generated-code.txt, v1-0003-Adjust-CustomTThreadPoolServer-for-thrift-updates.txt -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2412) Upgrade to thrift 0.6
[ https://issues.apache.org/jira/browse/CASSANDRA-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-2412: - Attachment: (was: v1-0002-update-thrift-generated-code.txt) Upgrade to thrift 0.6 - Key: CASSANDRA-2412 URL: https://issues.apache.org/jira/browse/CASSANDRA-2412 Project: Cassandra Issue Type: Task Components: Core Reporter: Gary Dusbabek Assignee: Gary Dusbabek Priority: Trivial Labels: thrift Fix For: 0.8 Attachments: v1-0001-upgrade-thrift-jar.txt, v1-0002-update-thrift-generated-code.txt, v1-0003-Adjust-CustomTThreadPoolServer-for-thrift-updates.txt -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2412) Upgrade to thrift 0.6
[ https://issues.apache.org/jira/browse/CASSANDRA-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-2412: - Attachment: (was: v1-0003-Adjust-CustomTThreadPoolServer-for-thrift-updates.txt) Upgrade to thrift 0.6 - Key: CASSANDRA-2412 URL: https://issues.apache.org/jira/browse/CASSANDRA-2412 Project: Cassandra Issue Type: Task Components: Core Reporter: Gary Dusbabek Assignee: Gary Dusbabek Priority: Trivial Labels: thrift Fix For: 0.8 Attachments: v1-0001-upgrade-thrift-jar.txt, v1-0002-update-thrift-generated-code.txt, v1-0003-Adjust-CustomTThreadPoolServer-for-thrift-updates.txt -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2412) Upgrade to thrift 0.6
[ https://issues.apache.org/jira/browse/CASSANDRA-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-2412: - Reviewer: tjake (was: jake) Upgrade to thrift 0.6 - Key: CASSANDRA-2412 URL: https://issues.apache.org/jira/browse/CASSANDRA-2412 Project: Cassandra Issue Type: Task Components: Core Reporter: Gary Dusbabek Assignee: Gary Dusbabek Priority: Trivial Labels: thrift Fix For: 0.8 Attachments: v1-0001-upgrade-thrift-jar.txt, v1-0002-update-thrift-generated-code.txt, v1-0003-Adjust-CustomTThreadPoolServer-for-thrift-updates.txt -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2412) Upgrade to thrift 0.6
[ https://issues.apache.org/jira/browse/CASSANDRA-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-2412: - Reviewer: jake Upgrade to thrift 0.6 - Key: CASSANDRA-2412 URL: https://issues.apache.org/jira/browse/CASSANDRA-2412 Project: Cassandra Issue Type: Task Components: Core Reporter: Gary Dusbabek Assignee: Gary Dusbabek Priority: Trivial Labels: thrift Fix For: 0.8 Attachments: v1-0001-upgrade-thrift-jar.txt, v1-0002-update-thrift-generated-code.txt, v1-0003-Adjust-CustomTThreadPoolServer-for-thrift-updates.txt -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2412) Upgrade to thrift 0.6
Upgrade to thrift 0.6 - Key: CASSANDRA-2412 URL: https://issues.apache.org/jira/browse/CASSANDRA-2412 Project: Cassandra Issue Type: Task Components: Core Reporter: Gary Dusbabek Assignee: Gary Dusbabek Priority: Trivial Fix For: 0.8 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2381) orphaned data files may be created during migration race
[ https://issues.apache.org/jira/browse/CASSANDRA-2381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13012045#comment-13012045 ] Gary Dusbabek commented on CASSANDRA-2381: -- Is it necessary to make the MT lock static? I do not think there would be a problem with concurrently flushing two memtables of different column families (the CL serialization is still preserved by the synchronization in CFS). orphaned data files may be created during migration race Key: CASSANDRA-2381 URL: https://issues.apache.org/jira/browse/CASSANDRA-2381 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.0 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 0.7.5 Attachments: 2381-0.8.txt We try to prevent creating orphans by locking Table.flusherLock in maybeSwitchMemtable and the Migration process, but since the actual writing is done asynchronously in Memtable.writeSortedContents there is a race window, where we acquire lock in maybeSwitch, we're not dropped so we queue the flush and release the lock, Migration does the drop, then Memtable writes itself out. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2394) Faulty hd kills cluster performance
[ https://issues.apache.org/jira/browse/CASSANDRA-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13012057#comment-13012057 ] Gary Dusbabek commented on CASSANDRA-2394: -- This probably belongs in 0.8. Faulty hd kills cluster performance --- Key: CASSANDRA-2394 URL: https://issues.apache.org/jira/browse/CASSANDRA-2394 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.4 Reporter: Thibaut Priority: Minor Fix For: 0.7.5 Hi, About every week, a node from our main cluster (100 nodes) has a faulty hd (Listing the cassandra data storage directoy triggers an input/output error). Whenever this occurs, I see many timeoutexceptions in our application on various nodes which cause everything to run very very slowly. Keyrange scans just timeout and will sometimes never succeed. If I stop cassandra on the faulty node, everything runs normal again. It would be great to have some kind of monitoring thread in cassandra which marks a node as down if there are multiple read/write errors to the data directories. A single faulty hd on 1 node shouldn't affect global cluster performance. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2381) orphaned data files may be created during migration race
[ https://issues.apache.org/jira/browse/CASSANDRA-2381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13012092#comment-13012092 ] Gary Dusbabek commented on CASSANDRA-2381: -- I'm seeing unit test failures in CliTest and DefsTest with v2 applied (never ran them on v1). orphaned data files may be created during migration race Key: CASSANDRA-2381 URL: https://issues.apache.org/jira/browse/CASSANDRA-2381 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.0 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 0.7.5 Attachments: 2381-0.8.txt, 2831-v2.txt We try to prevent creating orphans by locking Table.flusherLock in maybeSwitchMemtable and the Migration process, but since the actual writing is done asynchronously in Memtable.writeSortedContents there is a race window, where we acquire lock in maybeSwitch, we're not dropped so we queue the flush and release the lock, Migration does the drop, then Memtable writes itself out. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2381) orphaned data files may be created during migration race
[ https://issues.apache.org/jira/browse/CASSANDRA-2381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13012154#comment-13012154 ] Gary Dusbabek commented on CASSANDRA-2381: -- +1. orphaned data files may be created during migration race Key: CASSANDRA-2381 URL: https://issues.apache.org/jira/browse/CASSANDRA-2381 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.0 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 0.7.5 Attachments: 2381-0.8.txt, 2381-v3.txt, 2831-v2.txt We try to prevent creating orphans by locking Table.flusherLock in maybeSwitchMemtable and the Migration process, but since the actual writing is done asynchronously in Memtable.writeSortedContents there is a race window, where we acquire lock in maybeSwitch, we're not dropped so we queue the flush and release the lock, Migration does the drop, then Memtable writes itself out. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2361) AES depends on java serialization
[ https://issues.apache.org/jira/browse/CASSANDRA-2361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-2361: - Attachment: v2-0002-get-rid-of-annoying-AES-emissions.txt v2-0001-ICompactSerializers-for-MerkleTrees.txt AES depends on java serialization - Key: CASSANDRA-2361 URL: https://issues.apache.org/jira/browse/CASSANDRA-2361 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.4 Reporter: Gary Dusbabek Assignee: Gary Dusbabek Priority: Minor Fix For: 0.7.5, 0.8 Attachments: 2361-part1.patch, v2-0001-ICompactSerializers-for-MerkleTrees.txt, v2-0002-get-rid-of-annoying-AES-emissions.txt 0.8 should be able to run in the same cluster as 0.7. AES uses java serialization which means that Token serialization stands a good chance of being brittle. This needs to be fixed. 1. place a hard-coded serialVersionUID for Token in 0.7.5. 2. have AES use ICompactSerializer in place of ObjectInputStream in 0.8. This would be a good opportunity to audit the code for imprudent uses of Object[Input|Output]Stream and get those cleaned up. Also, it will exercise the versioning code a bit. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2361) AES depends on java serialization
[ https://issues.apache.org/jira/browse/CASSANDRA-2361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-2361: - Attachment: (was: v1-0001-ICompactSerializers-for-MerkleTrees.txt) AES depends on java serialization - Key: CASSANDRA-2361 URL: https://issues.apache.org/jira/browse/CASSANDRA-2361 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.4 Reporter: Gary Dusbabek Assignee: Gary Dusbabek Priority: Minor Fix For: 0.7.5, 0.8 Attachments: 2361-part1.patch, v2-0001-ICompactSerializers-for-MerkleTrees.txt, v2-0002-get-rid-of-annoying-AES-emissions.txt 0.8 should be able to run in the same cluster as 0.7. AES uses java serialization which means that Token serialization stands a good chance of being brittle. This needs to be fixed. 1. place a hard-coded serialVersionUID for Token in 0.7.5. 2. have AES use ICompactSerializer in place of ObjectInputStream in 0.8. This would be a good opportunity to audit the code for imprudent uses of Object[Input|Output]Stream and get those cleaned up. Also, it will exercise the versioning code a bit. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2361) AES depends on java serialization
[ https://issues.apache.org/jira/browse/CASSANDRA-2361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13012159#comment-13012159 ] Gary Dusbabek commented on CASSANDRA-2361: -- v2 implements Sylvain's suggestion for more compact serializations. AES depends on java serialization - Key: CASSANDRA-2361 URL: https://issues.apache.org/jira/browse/CASSANDRA-2361 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.4 Reporter: Gary Dusbabek Assignee: Gary Dusbabek Priority: Minor Fix For: 0.7.5, 0.8 Attachments: 2361-part1.patch, v2-0001-ICompactSerializers-for-MerkleTrees.txt, v2-0002-get-rid-of-annoying-AES-emissions.txt 0.8 should be able to run in the same cluster as 0.7. AES uses java serialization which means that Token serialization stands a good chance of being brittle. This needs to be fixed. 1. place a hard-coded serialVersionUID for Token in 0.7.5. 2. have AES use ICompactSerializer in place of ObjectInputStream in 0.8. This would be a good opportunity to audit the code for imprudent uses of Object[Input|Output]Stream and get those cleaned up. Also, it will exercise the versioning code a bit. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2361) AES depends on java serialization
[ https://issues.apache.org/jira/browse/CASSANDRA-2361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13010654#comment-13010654 ] Gary Dusbabek commented on CASSANDRA-2361: -- Go ahead and attach it to CASSANDRA-1034 then. I will modify the scope of this ticket to encompass only part 2. AES depends on java serialization - Key: CASSANDRA-2361 URL: https://issues.apache.org/jira/browse/CASSANDRA-2361 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.4 Reporter: Gary Dusbabek Assignee: Gary Dusbabek Priority: Minor Fix For: 0.7.5, 0.8 Attachments: 2361-part1.patch 0.8 should be able to run in the same cluster as 0.7. AES uses java serialization which means that Token serialization stands a good chance of being brittle. This needs to be fixed. 1. place a hard-coded serialVersionUID for Token in 0.7.5. 2. have AES use ICompactSerializer in place of ObjectInputStream in 0.8. This would be a good opportunity to audit the code for imprudent uses of Object[Input|Output]Stream and get those cleaned up. Also, it will exercise the versioning code a bit. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2361) AES depends on java serialization
[ https://issues.apache.org/jira/browse/CASSANDRA-2361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-2361: - Attachment: v1-0002-git-rid-of-annoying-AES-emissions.txt v1-0001-ICompactSerializers-for-MerkleTrees.txt AES depends on java serialization - Key: CASSANDRA-2361 URL: https://issues.apache.org/jira/browse/CASSANDRA-2361 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.4 Reporter: Gary Dusbabek Assignee: Gary Dusbabek Priority: Minor Fix For: 0.7.5, 0.8 Attachments: 2361-part1.patch, v1-0001-ICompactSerializers-for-MerkleTrees.txt, v1-0002-git-rid-of-annoying-AES-emissions.txt 0.8 should be able to run in the same cluster as 0.7. AES uses java serialization which means that Token serialization stands a good chance of being brittle. This needs to be fixed. 1. place a hard-coded serialVersionUID for Token in 0.7.5. 2. have AES use ICompactSerializer in place of ObjectInputStream in 0.8. This would be a good opportunity to audit the code for imprudent uses of Object[Input|Output]Stream and get those cleaned up. Also, it will exercise the versioning code a bit. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2379) ByteBufferUtil#bytes(String) can produce undesired results for some characters
[ https://issues.apache.org/jira/browse/CASSANDRA-2379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13010864#comment-13010864 ] Gary Dusbabek commented on CASSANDRA-2379: -- I think it makes more sense to always force UTF8 and not the platform default. Charsets.UTF_8 ftw. ByteBufferUtil#bytes(String) can produce undesired results for some characters -- Key: CASSANDRA-2379 URL: https://issues.apache.org/jira/browse/CASSANDRA-2379 Project: Cassandra Issue Type: Bug Reporter: Nate McCall Attachments: 2379.txt The difference between getBytes(java.nio.charset.Charset) vs. getBytes([charsetname]) on some platforms (mac it seems) can be substantial. From the java.lang.String javadoc for the former: This method always replaces malformed-input and unmappable-character sequences with this charset's default replacement byte array... vs. the latter: The behavior of this method when this string cannot be encoded in the default charset is unspecified. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2277) parameter substitution for Java CQL driver
[
https://issues.apache.org/jira/browse/CASSANDRA-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Dusbabek updated CASSANDRA-2277:
-
Attachment: v1-0004-fix-off-by-one-in-CassandraResultSet.txt
v1-0003-compress-utf8-bytes-and-not-platform-bytes.txt
v1-0002-JDBC-PreparedStatements-some-tests.txt
v1-0001-AbstractType-converts-types-to-Strings-not-just-ByteBu.txt
parameter substitution for Java CQL driver
--
Key: CASSANDRA-2277
URL: https://issues.apache.org/jira/browse/CASSANDRA-2277
Project: Cassandra
Issue Type: Sub-task
Components: API
Reporter: Eric Evans
Assignee: Gary Dusbabek
Labels: cql
Fix For: 0.8
Attachments:
v1-0001-AbstractType-converts-types-to-Strings-not-just-ByteBu.txt,
v1-0002-JDBC-PreparedStatements-some-tests.txt,
v1-0003-compress-utf8-bytes-and-not-platform-bytes.txt,
v1-0004-fix-off-by-one-in-CassandraResultSet.txt
The Java driver should support parameter substitution such that given a query
string and a sequence of arguments, question marks ('?') in the query string
will be substituted with the arguments.
{code:style=Java}
conn.execute(SELECT ?,? FROM Standard1 WHERE KEY = ?, 10, 20, foo)
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2372) JDBC driver will need adjustments post 2311
JDBC driver will need adjustments post 2311 --- Key: CASSANDRA-2372 URL: https://issues.apache.org/jira/browse/CASSANDRA-2372 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Gary Dusbabek Priority: Minor Right now jdbc just assumes keys are always bytes. After CASSANDRA-2311 we'll need to use a comparator that can be derived from client.describe_keyspaces(). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2361) AES depends on java serialization
AES depends on java serialization - Key: CASSANDRA-2361 URL: https://issues.apache.org/jira/browse/CASSANDRA-2361 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.4 Reporter: Gary Dusbabek Assignee: Gary Dusbabek Priority: Minor Fix For: 0.7.5, 0.8 0.8 should be able to run in the same cluster as 0.7. AES uses java serialization which means that Token serialization stands a good chance of being brittle. This needs to be fixed. 1. place a hard-coded serialVersionUID for Token in 0.7.5. 2. have AES use ICompactSerializer in place of ObjectInputStream in 0.8. This would be a good opportunity to audit the code for imprudent uses of Object[Input|Output]Stream and get those cleaned up. Also, it will exercise the versioning code a bit. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2350) Races between schema changes and StorageService operations
[
https://issues.apache.org/jira/browse/CASSANDRA-2350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13008419#comment-13008419
]
Gary Dusbabek commented on CASSANDRA-2350:
--
+1
Races between schema changes and StorageService operations
--
Key: CASSANDRA-2350
URL: https://issues.apache.org/jira/browse/CASSANDRA-2350
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.7.0
Reporter: Jeffrey Wang
Assignee: Jonathan Ellis
Priority: Minor
Fix For: 0.7.5
Attachments: 2350.txt
I only tested this on 0.7.0, but it judging by the 0.7.3 code (latest I've
looked at) the same thing should happen.
The case in particular that I ran into is this: I force a compaction for all
CFs in a keyspace, and while the compaction is happening I add another CF to
the keyspace. I get the following exception because the underlying set of CFs
has changed while being iterated over.
{noformat}
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(Unknown Source)
at java.util.HashMap$ValueIterator.next(Unknown Source)
at java.util.Collections$UnmodifiableCollection$1.next(Unknown Source)
at
org.apache.cassandra.service.StorageService.forceTableCompaction(StorageService.java:1140)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(Unknown
Source)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(Unknown
Source)
at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(Unknown Source)
at com.sun.jmx.mbeanserver.PerInterface.invoke(Unknown Source)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(Unknown Source)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(Unknown Source)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(Unknown Source)
at javax.management.remote.rmi.RMIConnectionImpl.doOperation(Unknown
Source)
at javax.management.remote.rmi.RMIConnectionImpl.access$200(Unknown
Source)
at
javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(Unknown
Source)
at
javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(Unknown
Source)
at javax.management.remote.rmi.RMIConnectionImpl.invoke(Unknown
Source)
at sun.reflect.GeneratedMethodAccessor84.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
at sun.rmi.transport.Transport$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown
Source)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
{noformat}
The problem is a little more fundamental than that, though, as I believe any
schema change of CFs in the keyspace during one of these operations (e.g.
flush, compaction, etc) has the potential to cause a race. I'm not sure what
would happen if the set of CFs to compact was acquired and one of them was
dropped before it had been compacted.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2124) JDBC driver for CQL
[ https://issues.apache.org/jira/browse/CASSANDRA-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13008014#comment-13008014 ] Gary Dusbabek commented on CASSANDRA-2124: -- IMO, that falls under implementing a proper PreparedStatement interface. This is currently what I envision for CASSANDRA-2277. JDBC driver for CQL --- Key: CASSANDRA-2124 URL: https://issues.apache.org/jira/browse/CASSANDRA-2124 Project: Cassandra Issue Type: New Feature Components: API Reporter: Eric Evans Assignee: Vivek Mishra Priority: Minor Labels: cql Fix For: 0.8 Attachments: Cassandra-2124_v1.0, Cassandra_2124_decoder.patch, cassandra-0.7.1-2124_v2.0, cassandra-0.7.1-2124_v2.1, cassandra_generic_decoder.patch, cassandra_generic_decoder_v1.1.patch, v3-0001-first-pass-at-column-decoding.txt, v3-0002-clean-up-JdbcDriverTest.txt, v3-0003-implements-getXXX-methods-to-return-values-of-the-corr.txt, v3-0004-more-comments-in-ColumnDecoder.txt, v3-0005-move-all-java-cql-into-jdbc-package-and-only-expose-.patch A simple connection class and corresponding pool was created for CQL as a part of CASSANDRA-1710, but a JDBC driver (either in addition to, or as a replacement for) would also be interesting. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2124) JDBC driver for CQL
[ https://issues.apache.org/jira/browse/CASSANDRA-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13008018#comment-13008018 ] Gary Dusbabek commented on CASSANDRA-2124: -- bq. I believe CassandraStatement is PreparedStatement. Yes, it currently is. I think the code will be more maintainable if it is broken out. JDBC driver for CQL --- Key: CASSANDRA-2124 URL: https://issues.apache.org/jira/browse/CASSANDRA-2124 Project: Cassandra Issue Type: New Feature Components: API Reporter: Eric Evans Assignee: Vivek Mishra Priority: Minor Labels: cql Fix For: 0.8 Attachments: Cassandra-2124_v1.0, Cassandra_2124_decoder.patch, cassandra-0.7.1-2124_v2.0, cassandra-0.7.1-2124_v2.1, cassandra_generic_decoder.patch, cassandra_generic_decoder_v1.1.patch, v3-0001-first-pass-at-column-decoding.txt, v3-0002-clean-up-JdbcDriverTest.txt, v3-0003-implements-getXXX-methods-to-return-values-of-the-corr.txt, v3-0004-more-comments-in-ColumnDecoder.txt, v3-0005-move-all-java-cql-into-jdbc-package-and-only-expose-.patch A simple connection class and corresponding pool was created for CQL as a part of CASSANDRA-1710, but a JDBC driver (either in addition to, or as a replacement for) would also be interesting. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CASSANDRA-2351) Null CF comments should be allowed
Null CF comments should be allowed -- Key: CASSANDRA-2351 URL: https://issues.apache.org/jira/browse/CASSANDRA-2351 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8 Reporter: Gary Dusbabek Assignee: Jon Hermes Priority: Minor Prior to 1906, cassandra tolerated null CF comments. They were converted to empty quotes when the CFM was created. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2351) Null CF comments should be allowed
[ https://issues.apache.org/jira/browse/CASSANDRA-2351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-2351: - Attachment: null_cf_comment_test_case.patch Attached a test case that demonstrates the regression. Null CF comments should be allowed -- Key: CASSANDRA-2351 URL: https://issues.apache.org/jira/browse/CASSANDRA-2351 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8 Reporter: Gary Dusbabek Assignee: Jon Hermes Priority: Minor Attachments: null_cf_comment_test_case.patch Prior to 1906, cassandra tolerated null CF comments. They were converted to empty quotes when the CFM was created. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2352) zero-length strings should result in zero-length ByteBuffers
[
https://issues.apache.org/jira/browse/CASSANDRA-2352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13008143#comment-13008143
]
Gary Dusbabek commented on CASSANDRA-2352:
--
+1
zero-length strings should result in zero-length ByteBuffers
Key: CASSANDRA-2352
URL: https://issues.apache.org/jira/browse/CASSANDRA-2352
Project: Cassandra
Issue Type: Bug
Components: API, Core
Reporter: Eric Evans
Assignee: Eric Evans
Labels: cql
Fix For: 0.8
Attachments:
v1-0001-CASSANDRA-2352-AT.fromString-should-return-empty-BB-fo.txt
The {{o.a.c.db.marshal.AbstractType.fromString()}} methods should return an
empty {{ByteBuffer}} when passed a zero-length string, (empty bytes do
{{validate()}} properly).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2124) JDBC driver for CQL
[ https://issues.apache.org/jira/browse/CASSANDRA-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13007461#comment-13007461 ] Gary Dusbabek commented on CASSANDRA-2124: -- Let's move any ResultSetMetaData discussion over to CASSANDRA-2302. JDBC driver for CQL --- Key: CASSANDRA-2124 URL: https://issues.apache.org/jira/browse/CASSANDRA-2124 Project: Cassandra Issue Type: New Feature Components: API Reporter: Eric Evans Assignee: Vivek Mishra Priority: Minor Labels: cql Fix For: 0.8 Attachments: Cassandra-2124_v1.0, Cassandra_2124_decoder.patch, cassandra-0.7.1-2124_v2.0, cassandra-0.7.1-2124_v2.1, cassandra_generic_decoder.patch, cassandra_generic_decoder_v1.1.patch, v3-0001-first-pass-at-column-decoding.txt, v3-0002-clean-up-JdbcDriverTest.txt, v3-0003-implements-getXXX-methods-to-return-values-of-the-corr.txt, v3-0004-more-comments-in-ColumnDecoder.txt, v3-0005-move-all-java-cql-into-jdbc-package-and-only-expose-.patch A simple connection class and corresponding pool was created for CQL as a part of CASSANDRA-1710, but a JDBC driver (either in addition to, or as a replacement for) would also be interesting. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2302) JDBC driver needs ResultSet.getMetaData()
[ https://issues.apache.org/jira/browse/CASSANDRA-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-2302: - Attachment: v2-0004-cache-comparator-and-validator-in-the-resultset.txt v2-0003-oh-yeah.-RSMD-column-index-all-need-to-be-off-by-one.txt v2-0002-expose-CassandraResultSetMetaData-to-inspect-type-info.txt v2-0001-implement-a-real-ResultSetMetaData.txt JDBC driver needs ResultSet.getMetaData() - Key: CASSANDRA-2302 URL: https://issues.apache.org/jira/browse/CASSANDRA-2302 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Gary Dusbabek Assignee: Gary Dusbabek Priority: Minor Labels: cql Fix For: 0.8 Attachments: v2-0001-RowData-exposes-sparse-column-attributes-through-Cassa.txt, v2-0001-implement-a-real-ResultSetMetaData.txt, v2-0002-expose-CassandraResultSetMetaData-to-inspect-type-info.txt, v2-0002-make-RowMetaData-typed.txt, v2-0003-oh-yeah.-RSMD-column-index-all-need-to-be-off-by-one.txt, v2-0004-cache-comparator-and-validator-in-the-resultset.txt -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2302) JDBC driver needs ResultSet.getMetaData()
[ https://issues.apache.org/jira/browse/CASSANDRA-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-2302: - Attachment: (was: v2-0001-RowData-exposes-sparse-column-attributes-through-Cassa.txt) JDBC driver needs ResultSet.getMetaData() - Key: CASSANDRA-2302 URL: https://issues.apache.org/jira/browse/CASSANDRA-2302 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Gary Dusbabek Assignee: Gary Dusbabek Priority: Minor Labels: cql Fix For: 0.8 Attachments: v2-0001-implement-a-real-ResultSetMetaData.txt, v2-0002-expose-CassandraResultSetMetaData-to-inspect-type-info.txt, v2-0002-make-RowMetaData-typed.txt, v2-0003-oh-yeah.-RSMD-column-index-all-need-to-be-off-by-one.txt, v2-0004-cache-comparator-and-validator-in-the-resultset.txt -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2302) JDBC driver needs ResultSet.getMetaData()
[ https://issues.apache.org/jira/browse/CASSANDRA-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-2302: - Attachment: (was: v2-0002-make-RowMetaData-typed.txt) JDBC driver needs ResultSet.getMetaData() - Key: CASSANDRA-2302 URL: https://issues.apache.org/jira/browse/CASSANDRA-2302 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Gary Dusbabek Assignee: Gary Dusbabek Priority: Minor Labels: cql Fix For: 0.8 Attachments: v2-0001-implement-a-real-ResultSetMetaData.txt, v2-0002-expose-CassandraResultSetMetaData-to-inspect-type-info.txt, v2-0003-oh-yeah.-RSMD-column-index-all-need-to-be-off-by-one.txt, v2-0004-cache-comparator-and-validator-in-the-resultset.txt -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2302) JDBC driver needs ResultSet.getMetaData()
[
https://issues.apache.org/jira/browse/CASSANDRA-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13007472#comment-13007472
]
Gary Dusbabek commented on CASSANDRA-2302:
--
Newest patch offers a ResultSetMetaData implementation that is more true to the
JDBC spec. The ResultSetMetaData interface is limited in that it only exposes
type information for column values. I've exposed CassandraResultSetMetaData to
remedy this. It can be accessed this way:
{code}
ResultSet rs = stmt.executeQuery(select ...);
ResultSetMetaData md = rs.getMetaData();
CassandraResultSetMetaData cmd = md.unwrap(CassandraResultSetMetaData.class);
{code}
CassandraResultSetMetaData is a long name to type out. I'm not opposed to
renaming it CassandraResultMetaData or something else shorter.
One aspect of CassandraResultSetMetaData that is different than the traditional
ResultSetMetaData is that it answers questions about the *current row* and not
the entire query (getColumnCount(), etc.), although type information (class
names, etc.) will be constant for every row in a result set.
When the time comes, I think CassandraResultSetMetaData will be the appropriate
place to expose decoded and typed row keys.
JDBC driver needs ResultSet.getMetaData()
-
Key: CASSANDRA-2302
URL: https://issues.apache.org/jira/browse/CASSANDRA-2302
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Gary Dusbabek
Assignee: Gary Dusbabek
Priority: Minor
Labels: cql
Fix For: 0.8
Attachments: v2-0001-implement-a-real-ResultSetMetaData.txt,
v2-0002-expose-CassandraResultSetMetaData-to-inspect-type-info.txt,
v2-0003-oh-yeah.-RSMD-column-index-all-need-to-be-off-by-one.txt,
v2-0004-cache-comparator-and-validator-in-the-resultset.txt
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-1906) Sanitize configuration code
[ https://issues.apache.org/jira/browse/CASSANDRA-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13007478#comment-13007478 ] Gary Dusbabek commented on CASSANDRA-1906: -- I can review this today. Jon-will you rebase and re-upload when you have a few minutes? Sanitize configuration code --- Key: CASSANDRA-1906 URL: https://issues.apache.org/jira/browse/CASSANDRA-1906 Project: Cassandra Issue Type: Improvement Reporter: Jon Hermes Assignee: Jon Hermes Priority: Minor Fix For: 0.8 Attachments: 1906-2.txt, 1906.txt Original Estimate: 24h Remaining Estimate: 24h Multipart: - Drop deprecated YAML config. Only config allowed is via thrift/JMX. Make this gratuitously easy to do with sane defaults and accepting changesets as opposed to full definitions. - Combine common code between KS/CF/ColumnDefs and between thrift/avro defs. - Provide an obvious and clean interface for changing settings locally versus globally (JMX vs. thrift). Dox here. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-1906) Sanitize configuration code
[ https://issues.apache.org/jira/browse/CASSANDRA-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13007678#comment-13007678 ] Gary Dusbabek commented on CASSANDRA-1906: -- Minor things (aside from the system test failures): * the CMFD constructors can be combined (public calls the private, passing nextId()). * a few of the files have spuriously inserted unnecessary imports. Those changes are the only changes for a few of them. Sanitize configuration code --- Key: CASSANDRA-1906 URL: https://issues.apache.org/jira/browse/CASSANDRA-1906 Project: Cassandra Issue Type: Improvement Reporter: Jon Hermes Assignee: Jon Hermes Priority: Minor Fix For: 0.8 Attachments: 1906-2.txt, 1906-3.txt, 1906.txt Original Estimate: 24h Remaining Estimate: 24h Multipart: - Drop deprecated YAML config. Only config allowed is via thrift/JMX. Make this gratuitously easy to do with sane defaults and accepting changesets as opposed to full definitions. - Combine common code between KS/CF/ColumnDefs and between thrift/avro defs. - Provide an obvious and clean interface for changing settings locally versus globally (JMX vs. thrift). Dox here. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2124) JDBC driver for CQL
[ https://issues.apache.org/jira/browse/CASSANDRA-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13006914#comment-13006914 ] Gary Dusbabek commented on CASSANDRA-2124: -- bq. Should we replace rowmetadata with ResultsetMetaData? The problem with using ResultSetMetaData is that it is a bad interface for Cassandra's sparse columns. A good example is that column 0 in one row might map to a column named foo, while column 0 in another row might map to a column named bar. The Wrappable interface exists so that JDBC driver implementations can provide features beyond the JDBC API without the ugliness of casting. I think it is better to make the programmer fully aware that he is dealing with sparse columns and forcing him to use the RowMetaData API. I'd like to hear your points on the benefits of using ResultSetMetaData though. I admit that RowMetaData may not be the ideal way of accessing row-specific meta information. JDBC driver for CQL --- Key: CASSANDRA-2124 URL: https://issues.apache.org/jira/browse/CASSANDRA-2124 Project: Cassandra Issue Type: New Feature Components: API Reporter: Eric Evans Assignee: Vivek Mishra Priority: Minor Labels: cql Fix For: 0.8 Attachments: Cassandra-2124_v1.0, Cassandra_2124_decoder.patch, cassandra-0.7.1-2124_v2.0, cassandra-0.7.1-2124_v2.1, cassandra_generic_decoder.patch, cassandra_generic_decoder_v1.1.patch, v3-0001-first-pass-at-column-decoding.txt, v3-0002-clean-up-JdbcDriverTest.txt, v3-0003-implements-getXXX-methods-to-return-values-of-the-corr.txt, v3-0004-more-comments-in-ColumnDecoder.txt, v3-0005-move-all-java-cql-into-jdbc-package-and-only-expose-.patch A simple connection class and corresponding pool was created for CQL as a part of CASSANDRA-1710, but a JDBC driver (either in addition to, or as a replacement for) would also be interesting. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (CASSANDRA-2302) JDBC driver needs ResultSet.getMetaData()
[ https://issues.apache.org/jira/browse/CASSANDRA-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek reopened CASSANDRA-2302: -- JDBC driver needs ResultSet.getMetaData() - Key: CASSANDRA-2302 URL: https://issues.apache.org/jira/browse/CASSANDRA-2302 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Gary Dusbabek Assignee: Gary Dusbabek Priority: Minor Labels: cql Fix For: 0.8 Attachments: v2-0001-RowData-exposes-sparse-column-attributes-through-Cassa.txt, v2-0002-make-RowMetaData-typed.txt -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2124) JDBC driver for CQL
[ https://issues.apache.org/jira/browse/CASSANDRA-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13006945#comment-13006945 ] Gary Dusbabek commented on CASSANDRA-2124: -- Ok. I reopened CASSANDRA-2302. JDBC driver for CQL --- Key: CASSANDRA-2124 URL: https://issues.apache.org/jira/browse/CASSANDRA-2124 Project: Cassandra Issue Type: New Feature Components: API Reporter: Eric Evans Assignee: Vivek Mishra Priority: Minor Labels: cql Fix For: 0.8 Attachments: Cassandra-2124_v1.0, Cassandra_2124_decoder.patch, cassandra-0.7.1-2124_v2.0, cassandra-0.7.1-2124_v2.1, cassandra_generic_decoder.patch, cassandra_generic_decoder_v1.1.patch, v3-0001-first-pass-at-column-decoding.txt, v3-0002-clean-up-JdbcDriverTest.txt, v3-0003-implements-getXXX-methods-to-return-values-of-the-corr.txt, v3-0004-more-comments-in-ColumnDecoder.txt, v3-0005-move-all-java-cql-into-jdbc-package-and-only-expose-.patch A simple connection class and corresponding pool was created for CQL as a part of CASSANDRA-1710, but a JDBC driver (either in addition to, or as a replacement for) would also be interesting. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2302) JDBC driver needs ResultSet.getMetaData()
[ https://issues.apache.org/jira/browse/CASSANDRA-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-2302: - Attachment: v2-0002-make-RowMetaData-typed.txt v2-0001-RowData-exposes-sparse-column-attributes-through-Cassa.txt JDBC driver needs ResultSet.getMetaData() - Key: CASSANDRA-2302 URL: https://issues.apache.org/jira/browse/CASSANDRA-2302 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Gary Dusbabek Assignee: Gary Dusbabek Priority: Minor Labels: cql Fix For: 0.8 Attachments: v2-0001-RowData-exposes-sparse-column-attributes-through-Cassa.txt, v2-0002-make-RowMetaData-typed.txt -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2302) JDBC driver needs ResultSet.getMetaData()
[ https://issues.apache.org/jira/browse/CASSANDRA-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-2302: - Attachment: (was: v1-0001-RowData-exposes-sparse-column-attributes-through-Cassa.txt) JDBC driver needs ResultSet.getMetaData() - Key: CASSANDRA-2302 URL: https://issues.apache.org/jira/browse/CASSANDRA-2302 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Gary Dusbabek Assignee: Gary Dusbabek Priority: Minor Labels: cql Fix For: 0.8 Attachments: v2-0001-RowData-exposes-sparse-column-attributes-through-Cassa.txt, v2-0002-make-RowMetaData-typed.txt -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (CASSANDRA-2277) parameter substitution for Java CQL driver
[
https://issues.apache.org/jira/browse/CASSANDRA-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Dusbabek reassigned CASSANDRA-2277:
Assignee: Gary Dusbabek
parameter substitution for Java CQL driver
--
Key: CASSANDRA-2277
URL: https://issues.apache.org/jira/browse/CASSANDRA-2277
Project: Cassandra
Issue Type: Sub-task
Components: API
Reporter: Eric Evans
Assignee: Gary Dusbabek
Labels: cql
Fix For: 0.8
The Java driver should support parameter substitution such that given a query
string and a sequence of arguments, question marks ('?') in the query string
will be substituted with the arguments.
{code:style=Java}
conn.execute(SELECT ?,? FROM Standard1 WHERE KEY = ?, 10, 20, foo)
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2258) service.SerializationsTest failes under cobertura
[
https://issues.apache.org/jira/browse/CASSANDRA-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Dusbabek updated CASSANDRA-2258:
-
Attachment:
v1-0001-fix-cobertura-brokenness-by-forcing-serialVersionUIDs.txt
service.SerializationsTest failes under cobertura
-
Key: CASSANDRA-2258
URL: https://issues.apache.org/jira/browse/CASSANDRA-2258
Project: Cassandra
Issue Type: Bug
Components: Tests
Reporter: Jonathan Ellis
Assignee: Gary Dusbabek
Priority: Minor
Fix For: 0.7.5
Attachments:
v1-0001-fix-cobertura-brokenness-by-forcing-serialVersionUIDs.txt
ant codecoverage -Dtest.name=SerializationsTest gives
{noformat}
[junit] Testcase:
testTreeResponseRead(org.apache.cassandra.service.SerializationsTest):
Caused an ERROR
[junit] java.io.InvalidClassException:
org.apache.cassandra.dht.BigIntegerToken; local class incompatible: stream
classdesc serialVersionUID = -5833589141319293006, local class
serialVersionUID = 2280189098581028124
[junit] java.lang.RuntimeException: java.io.InvalidClassException:
org.apache.cassandra.dht.BigIntegerToken; local class incompatible: stream
classdesc serialVersionUID = -5833589141319293006, local class
serialVersionUID = 2280189098581028124
[junit] at
org.apache.cassandra.service.AntiEntropyService$TreeResponseVerbHandler.deserialize(AntiEntropyService.java:634)
[junit] at
org.apache.cassandra.service.SerializationsTest.testTreeResponseRead(SerializationsTest.java:90)
[junit] Caused by: java.io.InvalidClassException:
org.apache.cassandra.dht.BigIntegerToken; local class incompatible: stream
classdesc serialVersionUID = -5833589141319293006, local class
serialVersionUID = 2280189098581028124
[junit] at
java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:562)
[junit] at
java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1582)
[junit] at
java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1495)
[junit] at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1731)
[junit] at
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
[junit] at
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1946)
[junit] at
java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870)
[junit] at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
[junit] at
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
[junit] at
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1946)
[junit] at
java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870)
[junit] at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
[junit] at
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
[junit] at
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1946)
[junit] at
java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870)
[junit] at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
[junit] at
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
[junit] at
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1946)
[junit] at
java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870)
[junit] at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
[junit] at
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
[junit] at
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1946)
[junit] at
java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870)
[junit] at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
[junit] at
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
[junit] at
java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)
[junit] at
org.apache.cassandra.service.AntiEntropyService$TreeResponseVerbHandler.deserialize(AntiEntropyService.java:630)
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2258) service.SerializationsTest failes under cobertura
[
https://issues.apache.org/jira/browse/CASSANDRA-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Dusbabek updated CASSANDRA-2258:
-
Attachment: v1-0001-do-not-instrument-the-Token-classes.txt
service.SerializationsTest failes under cobertura
-
Key: CASSANDRA-2258
URL: https://issues.apache.org/jira/browse/CASSANDRA-2258
Project: Cassandra
Issue Type: Bug
Components: Tests
Reporter: Jonathan Ellis
Assignee: Gary Dusbabek
Priority: Minor
Fix For: 0.7.5
Attachments: v1-0001-do-not-instrument-the-Token-classes.txt,
v1-0001-fix-cobertura-brokenness-by-forcing-serialVersionUIDs.txt
ant codecoverage -Dtest.name=SerializationsTest gives
{noformat}
[junit] Testcase:
testTreeResponseRead(org.apache.cassandra.service.SerializationsTest):
Caused an ERROR
[junit] java.io.InvalidClassException:
org.apache.cassandra.dht.BigIntegerToken; local class incompatible: stream
classdesc serialVersionUID = -5833589141319293006, local class
serialVersionUID = 2280189098581028124
[junit] java.lang.RuntimeException: java.io.InvalidClassException:
org.apache.cassandra.dht.BigIntegerToken; local class incompatible: stream
classdesc serialVersionUID = -5833589141319293006, local class
serialVersionUID = 2280189098581028124
[junit] at
org.apache.cassandra.service.AntiEntropyService$TreeResponseVerbHandler.deserialize(AntiEntropyService.java:634)
[junit] at
org.apache.cassandra.service.SerializationsTest.testTreeResponseRead(SerializationsTest.java:90)
[junit] Caused by: java.io.InvalidClassException:
org.apache.cassandra.dht.BigIntegerToken; local class incompatible: stream
classdesc serialVersionUID = -5833589141319293006, local class
serialVersionUID = 2280189098581028124
[junit] at
java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:562)
[junit] at
java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1582)
[junit] at
java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1495)
[junit] at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1731)
[junit] at
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
[junit] at
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1946)
[junit] at
java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870)
[junit] at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
[junit] at
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
[junit] at
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1946)
[junit] at
java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870)
[junit] at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
[junit] at
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
[junit] at
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1946)
[junit] at
java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870)
[junit] at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
[junit] at
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
[junit] at
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1946)
[junit] at
java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870)
[junit] at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
[junit] at
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
[junit] at
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1946)
[junit] at
java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870)
[junit] at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
[junit] at
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
[junit] at
java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)
[junit] at
org.apache.cassandra.service.AntiEntropyService$TreeResponseVerbHandler.deserialize(AntiEntropyService.java:630)
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2302) JDBC driver needs ResultSet.getMetaData()
[ https://issues.apache.org/jira/browse/CASSANDRA-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-2302: - Attachment: v1-0001-RowData-exposes-sparse-column-attributes-through-Cassa.txt JDBC driver needs ResultSet.getMetaData() - Key: CASSANDRA-2302 URL: https://issues.apache.org/jira/browse/CASSANDRA-2302 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Gary Dusbabek Assignee: Gary Dusbabek Priority: Minor Labels: cql Fix For: 0.8 Attachments: v1-0001-RowData-exposes-sparse-column-attributes-through-Cassa.txt -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2302) JDBC driver needs ResultSet.getMetaData()
[ https://issues.apache.org/jira/browse/CASSANDRA-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-2302: - Attachment: v1-0001-RowData-exposes-sparse-column-attributes-through-Cassa.txt JDBC driver needs ResultSet.getMetaData() - Key: CASSANDRA-2302 URL: https://issues.apache.org/jira/browse/CASSANDRA-2302 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Gary Dusbabek Assignee: Gary Dusbabek Priority: Minor Labels: cql Fix For: 0.8 Attachments: v1-0001-RowData-exposes-sparse-column-attributes-through-Cassa.txt -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2124) JDBC driver for CQL
[ https://issues.apache.org/jira/browse/CASSANDRA-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-2124: - Attachment: (was: v2-0003-implements-getXXX-methods-to-return-values-of-the-corr.txt) JDBC driver for CQL --- Key: CASSANDRA-2124 URL: https://issues.apache.org/jira/browse/CASSANDRA-2124 Project: Cassandra Issue Type: New Feature Components: API Reporter: Eric Evans Assignee: Vivek Mishra Priority: Minor Labels: cql Attachments: Cassandra-2124_v1.0, Cassandra_2124_decoder.patch, cassandra-0.7.1-2124_v2.0, cassandra-0.7.1-2124_v2.1, cassandra_generic_decoder.patch, cassandra_generic_decoder_v1.1.patch, v3-0001-first-pass-at-column-decoding.txt, v3-0002-clean-up-JdbcDriverTest.txt, v3-0003-implements-getXXX-methods-to-return-values-of-the-corr.txt, v3-0004-more-comments-in-ColumnDecoder.txt A simple connection class and corresponding pool was created for CQL as a part of CASSANDRA-1710, but a JDBC driver (either in addition to, or as a replacement for) would also be interesting. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2124) JDBC driver for CQL
[ https://issues.apache.org/jira/browse/CASSANDRA-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-2124: - Attachment: (was: v2-0004-more-comments-in-ColumnDecoder.txt) JDBC driver for CQL --- Key: CASSANDRA-2124 URL: https://issues.apache.org/jira/browse/CASSANDRA-2124 Project: Cassandra Issue Type: New Feature Components: API Reporter: Eric Evans Assignee: Vivek Mishra Priority: Minor Labels: cql Attachments: Cassandra-2124_v1.0, Cassandra_2124_decoder.patch, cassandra-0.7.1-2124_v2.0, cassandra-0.7.1-2124_v2.1, cassandra_generic_decoder.patch, cassandra_generic_decoder_v1.1.patch, v3-0001-first-pass-at-column-decoding.txt, v3-0002-clean-up-JdbcDriverTest.txt, v3-0003-implements-getXXX-methods-to-return-values-of-the-corr.txt, v3-0004-more-comments-in-ColumnDecoder.txt A simple connection class and corresponding pool was created for CQL as a part of CASSANDRA-1710, but a JDBC driver (either in addition to, or as a replacement for) would also be interesting. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2124) JDBC driver for CQL
[ https://issues.apache.org/jira/browse/CASSANDRA-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-2124: - Attachment: v3-0004-more-comments-in-ColumnDecoder.txt v3-0003-implements-getXXX-methods-to-return-values-of-the-corr.txt v3-0002-clean-up-JdbcDriverTest.txt v3-0001-first-pass-at-column-decoding.txt JDBC driver for CQL --- Key: CASSANDRA-2124 URL: https://issues.apache.org/jira/browse/CASSANDRA-2124 Project: Cassandra Issue Type: New Feature Components: API Reporter: Eric Evans Assignee: Vivek Mishra Priority: Minor Labels: cql Attachments: Cassandra-2124_v1.0, Cassandra_2124_decoder.patch, cassandra-0.7.1-2124_v2.0, cassandra-0.7.1-2124_v2.1, cassandra_generic_decoder.patch, cassandra_generic_decoder_v1.1.patch, v3-0001-first-pass-at-column-decoding.txt, v3-0002-clean-up-JdbcDriverTest.txt, v3-0003-implements-getXXX-methods-to-return-values-of-the-corr.txt, v3-0004-more-comments-in-ColumnDecoder.txt A simple connection class and corresponding pool was created for CQL as a part of CASSANDRA-1710, but a JDBC driver (either in addition to, or as a replacement for) would also be interesting. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2124) JDBC driver for CQL
[ https://issues.apache.org/jira/browse/CASSANDRA-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-2124: - Attachment: (was: v2-0001-first-pass-at-column-decoding.txt) JDBC driver for CQL --- Key: CASSANDRA-2124 URL: https://issues.apache.org/jira/browse/CASSANDRA-2124 Project: Cassandra Issue Type: New Feature Components: API Reporter: Eric Evans Assignee: Vivek Mishra Priority: Minor Labels: cql Attachments: Cassandra-2124_v1.0, Cassandra_2124_decoder.patch, cassandra-0.7.1-2124_v2.0, cassandra-0.7.1-2124_v2.1, cassandra_generic_decoder.patch, cassandra_generic_decoder_v1.1.patch, v3-0001-first-pass-at-column-decoding.txt, v3-0002-clean-up-JdbcDriverTest.txt, v3-0003-implements-getXXX-methods-to-return-values-of-the-corr.txt, v3-0004-more-comments-in-ColumnDecoder.txt A simple connection class and corresponding pool was created for CQL as a part of CASSANDRA-1710, but a JDBC driver (either in addition to, or as a replacement for) would also be interesting. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2124) JDBC driver for CQL
[ https://issues.apache.org/jira/browse/CASSANDRA-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-2124: - Attachment: (was: v2-0002-clean-up-JdbcDriverTest.txt) JDBC driver for CQL --- Key: CASSANDRA-2124 URL: https://issues.apache.org/jira/browse/CASSANDRA-2124 Project: Cassandra Issue Type: New Feature Components: API Reporter: Eric Evans Assignee: Vivek Mishra Priority: Minor Labels: cql Attachments: Cassandra-2124_v1.0, Cassandra_2124_decoder.patch, cassandra-0.7.1-2124_v2.0, cassandra-0.7.1-2124_v2.1, cassandra_generic_decoder.patch, cassandra_generic_decoder_v1.1.patch, v3-0001-first-pass-at-column-decoding.txt, v3-0002-clean-up-JdbcDriverTest.txt, v3-0003-implements-getXXX-methods-to-return-values-of-the-corr.txt, v3-0004-more-comments-in-ColumnDecoder.txt A simple connection class and corresponding pool was created for CQL as a part of CASSANDRA-1710, but a JDBC driver (either in addition to, or as a replacement for) would also be interesting. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2124) JDBC driver for CQL
[ https://issues.apache.org/jira/browse/CASSANDRA-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Dusbabek updated CASSANDRA-2124: - Attachment: v3-0005-move-all-java-cql-into-jdbc-package-and-only-expose-.patch JDBC driver for CQL --- Key: CASSANDRA-2124 URL: https://issues.apache.org/jira/browse/CASSANDRA-2124 Project: Cassandra Issue Type: New Feature Components: API Reporter: Eric Evans Assignee: Vivek Mishra Priority: Minor Labels: cql Attachments: Cassandra-2124_v1.0, Cassandra_2124_decoder.patch, cassandra-0.7.1-2124_v2.0, cassandra-0.7.1-2124_v2.1, cassandra_generic_decoder.patch, cassandra_generic_decoder_v1.1.patch, v3-0001-first-pass-at-column-decoding.txt, v3-0002-clean-up-JdbcDriverTest.txt, v3-0003-implements-getXXX-methods-to-return-values-of-the-corr.txt, v3-0004-more-comments-in-ColumnDecoder.txt, v3-0005-move-all-java-cql-into-jdbc-package-and-only-expose-.patch A simple connection class and corresponding pool was created for CQL as a part of CASSANDRA-1710, but a JDBC driver (either in addition to, or as a replacement for) would also be interesting. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CASSANDRA-2302) JDBC driver needs ResultSet.getMetaData()
JDBC driver needs ResultSet.getMetaData() - Key: CASSANDRA-2302 URL: https://issues.apache.org/jira/browse/CASSANDRA-2302 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Gary Dusbabek Assignee: Gary Dusbabek Priority: Minor Fix For: 0.8 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
