Re: 3.0 and the Cassandra release process
Hey Jonathan, I have been hoping for this approach for years now-one of the reasons I left Datastax was due to my feeling that quality was always on the backburner and never really taken seriously vs marketing driven releases. I sincerely hope this approach reverses that perceived trend. -- Colin +1 612 859 6129 Skype colin.p.clark On Apr 2, 2015, at 5:54 PM, Jonathan Ellis jbel...@gmail.com wrote: We are moving away from designating major releases like 3.0 as special, other than as a marker of compatibility. In fact we are moving away from major releases entirely, with each release being a much smaller, digestible unit of change, and the ultimate goal of every even release being production-quality. This means that bugs won't pile up and compound each other. And bugs that do slip through will affect less users. As 3.x stabilizes, more people will try out the releases, yielding better quality, yielding even more people trying them out in a virtuous cycle. This won't just happen by wishing for it. I am very serious about investing the energy we would have spent on backporting fixes to a stable branch, into improving our QA process and test coverage. After a very short list of in-progress features that may not make the 3.0 cutoff (#6477, #6696 come to mind) I'm willing to virtually pause new feature development entirely to make this happen. Some patience will be necessary with the first few releases. But at this point, people are used to about six months of waiting for a new major to stabilize. So, let's give this a try until 3.6. If that still hasn't materially stabilized, then we need to go back to the drawing board. But I'm optimistic that it will. On Thu, Apr 2, 2015 at 5:04 PM, Jonathan Haddad j...@jonhaddad.com wrote: In this tick tock cycle, is there still a long term release that's maintained, meant for production? Will bug fixes be back ported to 3.0 (stable) with new stuff going forward to 3.x? -- Jonathan Ellis Project Chair, Apache Cassandra co-founder, http://www.datastax.com @spyced
Re: New CQL binding - Perl/Net::Async::CassandraCQL
Hey Paul, The current version of perlcassa has some rudimentary support for CQL3. It appears the version on CPAN is being the current version on github. https://github.com/mkjellman/perlcassa On 08/29/2013 04:21 PM, Paul LeoNerd Evans wrote: Hi there, I've been working on a Cassandra binding for Perl that talks CQL, as I noticed none of the existing ones on CPAN do. It can be found at https://metacpan.org/module/Net::Async::CassandraCQL I was going to add it to the page here https://wiki.apache.org/cassandra/ClientOptions but I notice that even having signed up for an account, I can't edit the page. -- *Colin Blower* /Software Engineer/ Barracuda Networks Inc. +1 408-342-5576 (o)
Starting up Cassandra occurred errors after upgrading Cassandra to 1.2.5 from 1.0.12
Hi All, We followed the upgrade guide( http://www.datastax.com/docs/1.2/install/upgrading) from Datastax web site and upgraded Cassadra to 1.2.5, but it occurred errors in system.log when starting up. After digging into code level, it looks like Cassandra found the file length of IndexSummary sstable is zero. Thus Cassandra threw AssertionError. In fact, the file length of the IndexSummary is about 80 bytes, not zero. It's weird. Also we observed that only happens on the IndexSummary file of secondary index. The errors can be reproducible. Below are my upgrade steps. 1. Shutdown all of client applications. 2. Run nodetool drain before shutting down the existing Cassandra service. 3. Stop old Cassandra process, then start the new binary process using migrated cassandra.yaml. 4. Run nodetool upgradesstables -a in order to upgrade all of sstable files become new format. 5. Restart Cassandra process and monitor the logs file for any issues. At step 5, we found the error messages as below. Any ideas? Thank you! Colin === INFO [SSTableBatchOpen:2] 2013-05-29 04:38:40,085 SSTableReader.java (line 169) Opening /var/lib/cassandra/data/ks/user/ks-user.ks_user_personalID-ic-61 (58 bytes) ERROR [SSTableBatchOpen:1] 2013-05-29 04:38:40,085 CassandraDaemon.java (line 175) Exception in thread Thread[SSTableBatchOpen:1,5,main] java.lang.AssertionError at org.apache.cassandra.utils.ByteBufferUtil.readBytes(ByteBufferUtil.java:401) at org.apache.cassandra.io.sstable.IndexSummary$IndexSummarySerializer.deserialize(IndexSummary.java:124) at org.apache.cassandra.io.sstable.SSTableReader.loadSummary(SSTableReader.java:426) at org.apache.cassandra.io.sstable.SSTableReader.load(SSTableReader.java:360) at org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:201) at org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:154) at org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:241) at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) ERROR [SSTableBatchOpen:2] 2013-05-29 04:38:40,085 CassandraDaemon.java (line 175) Exception in thread Thread[SSTableBatchOpen:2,5,main] java.lang.AssertionError at org.apache.cassandra.utils.ByteBufferUtil.readBytes(ByteBufferUtil.java:401) at org.apache.cassandra.io.sstable.IndexSummary$IndexSummarySerializer.deserialize(IndexSummary.java:124) at org.apache.cassandra.io.sstable.SSTableReader.loadSummary(SSTableReader.java:426) at org.apache.cassandra.io.sstable.SSTableReader.load(SSTableReader.java:360) at org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:201) at org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:154) at org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:241) at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) ===
Re: [VOTE] Release Mojo's Cassandra Maven Plugin 1.0.0-1
+1 Thanks Stephen. On Wed, May 2, 2012 at 11:15 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Hi, I'd like to release version 1.1.0-1 of Mojo's Cassandra Maven Plugin to sync up with the 1.1.0 release of Apache Cassandra. We solved 2 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=12121version=17926 Staging Repository: https://nexus.codehaus.org/content/repositories/orgcodehausmojo-068/ Site: http://mojo.codehaus.org/cassandra-maven-plugin/index.html SCM Tag: https://svn.codehaus.org/mojo/tags/cassandra-maven-plugin-1.1.0-1@16519 [ ] +1 Yeah! fire ahead oh and the blind man on the galloping horse says it looks fine too. [ ] 0 Mehhh! like I care, I don't have any opinions either, I'd follow somebody else if only I could decide who [ ] -1 No! wait up there I have issues (in general like, ya know, and being a trouble-maker is only one of them) The vote is open for 72h and will succeed by lazy consensus. Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Cheers -Stephen P.S. In the interest of ensuring (more is) better testing, this vote is also open to subscribers of the dev and u...@cassandra.apache.org mailing lists.
Re: Server Side Logic/Script - Triggers / StoreProc
In my opinion, triggers/stored procedures are an absolute requirement for any distributed database. We've been using stored procedures in Cassandra now for a while, we've made modifications such that we don't really write directly anymore but pass everything through either a default stored procedures (which is just what was there before) or a dynamically loaded piece of java. These stored procedures can call other dynamically loaded pieces of java as well - we don't have any plans to implement any scripting capabilities. We can also 'select' from procedures. The idea of downloading data from a distributed data base for processing flies in the face of what nosql and bigdata is all about - you've got to do it in the db. On Apr 22, 2012, at 11:35 AM, Brian O'Neill wrote: Praveen, We are certainly interested. To get things moving we implemented an add-on for Cassandra to demonstrate the viability (using AOP): https://github.com/hmsonline/cassandra-triggers Right now the implementation executes triggers asynchronously, allowing you to implement a java interface and plugin your own java class that will get called for every insert. Per the discussion on 1311, we intend to extend our proof of concept to be able to invoke scripts as well. (minimally we'll enable javascript, but we'll probably allow for ruby and groovy as well) -brian On Apr 22, 2012, at 12:23 PM, Praveen Baratam wrote: I found that Triggers are coming in Cassandra 1.2 (https://issues.apache.org/jira/browse/CASSANDRA-1311) but no mention of any StoreProc like pattern. I know this has been discussed so many times but never met with any initiative. Even Groovy was staged out of the trunk. Cassandra is great for logging and as such will be infinitely more useful if some logic can be pushed into the Cassandra cluster nearer to the location of Data to generate a materialized view useful for applications. Server Side Scripts/Routines in Distributed Databases could soon prove to be the differentiating factor. Let me reiterate things with a use case. In our application we store time series data in wide rows with TTL set on each point to prevent data from growing beyond acceptable limits. Still the data size can be a limiting factor to move all of it from the cluster node to the querying node and then to the application via thrift for processing and presentation. Ideally we should process the data on the residing node and pass only the materialized view of the data upstream. This should be trivial if Cassandra implements some sort of server side scripting and CQL semantics to call it. Is anybody else interested in a similar feature? Is it being worked on? Are there any alternative strategies to this problem? Praveen -- Brian ONeill Lead Architect, Health Market Science (http://healthmarketscience.com) mobile:215.588.6024 blog: http://weblogs.java.net/blog/boneill42/ blog: http://brianoneill.blogspot.com/
Re: Time for 1.0
User documentation: done (http://www.riptano.com/docs) Apologies if this has been covered elsewhere but, is this a permanent home? Is there to be mirror on the official site? Surely if the project itself doesn't have user documentation then the milestone has not been reached by the project. I understand the motivation and it is Riptano's right of course, but the project still needs its own comprehensive user documentation. cheers Colin.
composite indexes?
Is this on the roadmap? I guess I cant see why it wouldnt be and we would be happy to supply patches if they were to be accepted, just puzzled by the seeming lack of interest. cheers Colin
Re: cassandra increment counters, Jira #1072
Would it help prioritizing if silent majority chimed in if keen on this functionality which is so key to large scale analytical apps? in which case : +1 Although perhaps I should encourage signing up on jira and vote there. https://issues.apache.org/jira/secure/Signup!default.jspa https://issues.apache.org/jira/browse/CASSANDRA-1072 [We intend counting various attributes of the 100 million documents coming through our system a day] On Fri, Aug 13, 2010 at 11:15 AM, Benjamin Black b...@b3k.us wrote: On Thu, Aug 12, 2010 at 10:23 AM, Kelvin Kakugawa kakug...@gmail.com wrote: I think the underlying unanswered question is whether #1072 is a niche feature or whether it should be brought into trunk. This should not be an unanswered question! #1072 should be considered essential, as it enables numerous use cases that currently require bolting something like memcache or redis onto the side to handle counters. +1 on getting this into trunk ASAP. b
