Re: C* 1.2.2 vs Raspberry Pi
It's an optimisation flag, and not applicable to the to the 1.x JVM's should be fine to remove it. --Jools On 4 March 2013 19:17, Andrew Cobley wrote: > Stupidly I've locked myself out of JIRA and it doesn't seem to want to > send me a password reset so I'll send this bug report here. > > As you guys may know I'v been running C* on a Raspberry Pi cluster for > experimental and educational reasons. It seems the startup script is > borked for 1.2.2 when using JDK1.8 (early release) on the PI. > > In Cassandra-env.sh lines 206-208 > > if [ "$JVM_VERSION" \> "1.7" ] ; then > JVM_OPTS="$JVM_OPTS -XX:+UseCondCardMark" > fi > > Are causing C* to not start on the Pi. It's reporting : > > Unrecognized VM option 'UseCondCardMark' > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > > It looks like this change came in for 1.2.2 > > Andy Cobley > School of Computing > University of Dundee > > > The University of Dundee is a registered Scottish Charity, No: SC015096 > >
Re: Avro RPC?
It's interesting to note that in Eben Hewitt's - The definitive guide to Cassandra he states the following; *Avro Summary* As of Cassandra version 0.7, Avro is the RPC and data serialization mechanism for Cassandra. It generates code that remote clients can use to interact with the database. It’s well-supported in the community and has the strength of growing out of the larger and very well-known Hadoop project. It should serve Cassandra well for the foreseeable future. Personally I'm pretty much married to thrift as it's used all the way through my application stack, and having played with Avro it really didn't merit the effort to move over (for me at least). How are you thinking of creating an 'application specific' transport ? --Jools On 22 December 2010 17:00, Eric Evans wrote: > > So, Avro RPC. Is anyone using this? Is there anyone interested in > seeing it maintained? > > I'm concentrating on CQL[1][2], which for me will culminate in the > creation of a new, application-specific transport, one that doesn't use > either of the frameworks. To me, the existing RPC framework is just > something to piggy-back on until things are otherwise working, and I'm > starting to think Thrift might be a better piggy here (read: it has more > momentum). > > TTBMK, the Avro RPC interface seems to be "mostly" working at present, > but it's already looking a bit like the proverbial red headed stepchild. > Or am I wrong and there are people who care deeply about this? > > > [1]: http://article.gmane.org/gmane.comp.db.cassandra.devel/2370 > [2]: https://issues.apache.org/jira/browse/CASSANDRA-1703 > > -- > Eric Evans > eev...@rackspace.com > >
Re: Avro RPC?
On 22 December 2010 17:40, Eric Evans wrote: > On Wed, 2010-12-22 at 17:27 +0000, Jools wrote: > > It's interesting to note that in Eben Hewitt's - The definitive guide > > to Cassandra he states the following; > > > > *Avro Summary* > > > > As of Cassandra version 0.7, Avro is the RPC and data serialization > > mechanism for Cassandra. > > > > It generates code that remote clients can use to interact with the > > database. > > > > It’s well-supported in the community and has the strength of growing > > out of the larger and very well-known Hadoop project. > > > > It should serve Cassandra well for the foreseeable future. > > Huh. That's just... wrong. Mmm, so it would seem. > > Personally I'm pretty much married to thrift as it's used all the way > > through my application stack, and having played with Avro it really > > didn't merit the effort to move over (for me at least). > > > > How are you thinking of creating an 'application specific' transport? > > Not sure what you mean, by "how" here. I haven't written a spec yet, if > that's what you mean. Ok, I thought you'd already discussed this and I'd missed the conversation. --Jools
Re: [VOTE] 7.0
+1 Although not a binding vote, seems to be playing nicely for me. --Jools On 6 January 2011 17:17, Eric Evans wrote: > > RC 4 seems to be holding up OK, shall we? I propose the following for > release as 0.7.0 (aka "For Reals Yo"). > > SVN: > > https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0@r1055934 > 0.7.0 artifacts: http://people.apache.org/~eevans > > The vote will be open for at least 72 hours. > > P.S. Don't forget that there is still a vote open for 0.6.9 > > [1]: http://goo.gl/uT89p (CHANGES.txt) > [2]: http://goo.gl/Bi8LD (NEWS.txt) > [3]: http://goo.gl/MHe1z (True Grit(s)) > > -- > Eric Evans > eev...@rackspace.com > >
Re: 6 months a more realistic release cycle?
We've been working on the 'ooh, shiny' approach to upgrading. Basically, once we see a new feature which will make life easier, better or just give us an excuse to play we start the process of adoption. Once we've managed to get our unit tests to pass, and updated our internal process documentation we then roll it out to our customers. We've never had a roll back, and each upgrade has pretty much been a dump -> install -> seed, and off we go. Hats of to the cassandra chaps, it just keeps getting better. -- Jools Enticknap Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Friday, 20 April 2012 at 19:33, Dave Brosius wrote: > +1 > > is there any stats on customer adoption of new versions? I'd wonder if > people generally move to new versions every 4 months, as that could be > potentially painful for them as well. Given the amount of questions > regarding older versions still percolating, i'd guess the answer is > they'd be ok with it too. > > > > On 04/20/2012 01:57 PM, Jonathan Ellis wrote: > > After the 0.7 release we decided to shoot for a fixed four-month > > release cycle. I think now is a good time to re-evaluate this, and > > possibly change to target a six month cycle: > > > > - Speaking for DataStax, about half our time is spent on maintenance. > > Given this, a 3 month window just isn't much time to work on some of > > the larger features we have planned. > > > > - Most of the schedule slip has been in our post-freeze QA period. A > > six month cycle would allow a more realistic 6 or even 8 weeks of QA, > > while still expanding the dev window. > > > > - Cassandra has matured enough that there is less low-hanging fruit to > > pick; two potential upgrades per year feels better matched to that, > > than three. > > > > - The reality has been that 0.8, 1.0, and 1.1 took about 5, 5.5, and 6 > > months, respectively. So in a sense, officially making it a 6-month > > cycle would only be acknowledging reality anyway. > > > > Thoughts?
