hmm. doesn't that leave the trunk in a bad position in terms of new development? you may go through times when a major feature lands and trunk is broken/buggy. or are you planning on building new features on a branch and then merging into trunk when it's stable?
On Dec 3, 2009, at 5:32 AM, Jonathan Ellis wrote: > We are using trunk. 0.5 beta / trunk is better than 0.4 at the 0.4 > functionality and IMO is production ready (although you should always > test first), but I would not yet rely on the new stuff (bootstrap, > loadbalance, and moving nodes around in general). > > -Jonathan > > On Wed, Dec 2, 2009 at 12:26 PM, Adam Fisk <a...@littleshoot.org> wrote: >> Helpful thread guys. In general, Jonathan, would you recommend >> building from trunk for new deployments at our current snapshot in >> time? Are you using trunk at Rackspace? >> >> Thanks. >> >> -Adam >> >> >> On Tue, Dec 1, 2009 at 6:18 PM, Jonathan Ellis <jbel...@gmail.com> wrote: >>> On Tue, Dec 1, 2009 at 7:31 PM, Freeman, Tim <tim.free...@hp.com> wrote: >>>> Looking at the Cassandra mbean's, the attributes of ROW-MUTATION-STAGE and >>>> ROW-READ-STAGE and RESPONSE-STAGE are all less than 10. >>>> MINOR-COMPACTION-POOL reports 1218 pending tasks. >>> >>> That's probably the culprit right there. Something is wrong if you >>> have 1200 pending compactions. >>> >>> This is something that upgrading to trunk will help with right away >>> since we parallelize compactions there. >>> >>> Another thing you can do is increase the memtable limits so you are >>> not flushing + compacting so often with your insert traffic. >>> >>> -Jonathan >>> >> >> >> >> -- >> Adam Fisk >> http://www.littleshoot.org | http://adamfisk.wordpress.com | >> http://twitter.com/adamfisk >> -- Ian Holsman i...@holsman.net
