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 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 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: [RELEASE] Apache Cassandra 3.0.0-beta2 released
It’s so nice to see a marketing message in an email from apache…. Come on guys, you almost sound like you’re begging, are sales *that* bad? — Colin Clark co...@clark.ws +1 612-859-6129 skype colin.p.clark > On Sep 8, 2015, at 8:00 PM, Jake Luciani wrote: > > The Cassandra team is pleased to announce the release of Apache Cassandra > version 3.0.0-beta2. > > Apache Cassandra is a fully distributed database. It is the right choice > when you need scalability and high availability without compromising > performance. > > http://cassandra.apache.org/ > > Downloads of source and binary distributions are listed in our download > section: > > http://cassandra.apache.org/download/ > > This version is a *beta* release[1] on the 3.0 series. As always, please pay > attention to the release notes[2] and Let us know[3] if you were to > encounter > any problem. > > Enjoy! > > [1]: http://goo.gl/UWe5yb (CHANGES.txt) > [2]: http://goo.gl/xWOSDa (NEWS.txt) > [3]: https://issues.apache.org/jira/browse/CASSANDRA
Re: Proposal: deprecate Thrift now and remove support in 4.0
+1 -- Colin +1 612 723 2501 skype colin.p.clark > On Dec 28, 2015, at 8:54 AM, Robert Stupp wrote: > > +1 > > -- > Robert Stupp > @snazy > > > > -- > Robert Stupp > @snazy >> Am 28.12.2015 um 15:26 schrieb Jonathan Ellis : >> >> Thrift has been officially frozen for almost two years and unofficially for >> longer. [1] Meanwhile, maintaining Thrift support through changes like >> 8099 has been a substantial investment. >> >> I propose deprecating Thrift now and removing support in 4.0, i.e. Nov 2016 >> if tick-tock goes as planned. >> >> I note that only 7% of our survey respondents [2] are using Thrift-only, >> and and those users are often on old releases (1.1 and 1.2), i.e. unlikely >> to upgrade to 4.x anyway. >> >> Another 20% of users are using a mix of Thrift and CQL. Some have been >> unable to completely migrate because CQL doesn’t quite provide every >> feature from Thrift. The last such outstanding issue is mixing static and >> dynamic Thrift “columns” in a single table. We have an issue open to >> address this [3]. >> >> I think it is reasonable to either deprecate Thrift immediately in 3.2 or >> to wait until 10857 is committed in 3.4. >> >> [1] >> http://mail-archives.apache.org/mod_mbox/cassandra-dev/201403.mbox/%3ccaldd-zim6knmr7f_zcpvpqk0b2g919tttathiuofnvlztaw...@mail.gmail.com%3E >> >> [2] >> https://docs.google.com/spreadsheets/d/1FegCArZgj2DNAjNkcXi1n2Y1Kfvf6cdZedkMPYQdvC0/edit#gid=0 >> >> [3] https://issues.apache.org/jira/browse/CASSANDRA-10857 >> >> -- >> Jonathan Ellis >> Project Chair, Apache Cassandra >> co-founder, http://www.datastax.com >> @spyced
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: 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)
Re: Cassandra Ubuntu "PPA"
+1 ! On 6/29/2010 5:56 PM, Clint Byrum wrote: I'd like to get all of your opinion on the PPA that we've built to help Cassandra users on Ubuntu. PPA stands for Personal Package Archive, and it is a system for building small apt repositories that users can easily add to their systems. As Eric Evans noted on IRC today, most users will be fine just pointing at the apache repository and installing cassandra from there. The only reason we've chosen to build a PPA is the continuously changing nature not only that Cassandra has, but Ubuntu as well. While we try to stay as close to Debian as possible, its entirely possible we'll break with Debian for a release, and we'd like to make sure our users are able to run and/or rebuild the latest packages on their systems. Likewise there may be other complementary packages like thrift that are not in apache's repository, that we can add to this one. We're basically just taking the debian source packages you're already putting out, and rebuilding it on top of Ubuntu releases. The focus of this is to help users reduce the amount of manual building/packaging/script writing they have need to do to get up and running and keep current. While we won't be able to offer the level of support that we do for packages in main, we're hoping that by staying as close as possible to your upstream releases we can help you support these users as well. So, I hope you will find it useful to point Ubuntu users here: https://launchpad.net/~cassandra-ubuntu/+archive/stable I welcome your comments! -Clint
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 wrote: > On Thu, Aug 12, 2010 at 10:23 AM, Kelvin Kakugawa 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 >
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: 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.
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: [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 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=12121&version=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.
