Re: 3.0 and the Cassandra release process
Broadly as a contributor and operator I like the idea of more frequent releases off of an always stable master. First customer ship quality all the time [1]! I'm a little concerned that the specific tick-tock proposal could devolve into a 'devodd' style where the 'feature release' becomes a thing no one wants to run in production. However, if master is always stable it doesn't really matter when releases are cut and if master is *not* stable that is a larger problem then the details of the release cadence. I say give it a shot. [1] http://wiki.illumos.org/display/illumos/On+the+Quality+Death+Spiral
Re: Proposed changes to C* Release Schedule
On 06/17/2014 01:16 PM, Michael Kjellman wrote: That being said I don’t think i’m alone by identifying the problem. FWIW I'm not doing anything wildly unusual and I've been on a fork for as long as I've been on 1.2 (and various times before). Almost everyone being on 1.2 with 3 other equally weighted active branches seems like an obvious not-great situation for running cassandra or developing. I like the idea of shortening the release cycle and LTS style releases and they feel like the most direct approach. I'm a little wary of more branches since that could backfire and make the problem worse.
Re: Proposal: freeze Thrift starting with 2.1.0
FWIW even for new development we have found thrift preferable to CQL. Others have have a different experience and that's cool. It's certinaly made it less intimidating to new users when explaining Cassandra. I'm very concerned at the sentiments in this thread about not testing or upgrading to 2.1 being a dumb idea. The thing we value most from Cassandra is that it works. Operability, stability, and robustness are by far the most important traits. I can deal with wrapping APIs and transport layers. Dealing with untested releases is much more complicated.
Re: [VOTE] Release Apache Cassandra 1.2.13
+1, we have rolled out most of the patches this week. On 12/11/2013 10:24 AM, Sylvain Lebresne wrote: Bugs fixed, good. I propose the following artifacts for release as 1.2.13. sha1: 6ab82a46984ccbf5eed4244ceef6fa30d781eebb Git: http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.2.13-tentative Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-044/org/apache/cassandra/apache-cassandra/1.2.13/ Staging repository: https://repository.apache.org/content/repositories/orgapachecassandra-044/ The artifacts as well as the debian package are also available here: http://people.apache.org/~slebresne/ The vote will be open for 72 hours (longer if needed). [1]: http://goo.gl/YssZQc (CHANGES.txt) [2]: http://goo.gl/6zdUA1 (NEWS.txt)
Re: [VOTE] Release Apache Cassandra 1.2.12
+1 I've been running several of the 1.2.12 patches in production for a while now. On 11/20/2013 04:37 AM, Sylvain Lebresne wrote: A fair number of fixes went in since 1.2.11, I propose the following artifacts for release as 1.2.12. sha1: 026865f2a36d9685057c407e3fa528c101ab46b7 Git: http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.2.12-tentative Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-173/org/apache/cassandra/apache-cassandra/1.2.12/ Staging repository: https://repository.apache.org/content/repositories/orgapachecassandra-173/ The artifacts as well as the debian package are also available here: http://people.apache.org/~slebresne/ The vote will be open for 72 hours (longer if needed). [1]: http://goo.gl/ew18iW (CHANGES.txt) [2]: http://goo.gl/RpPe3x (NEWS.txt)
Re: I don't understand shuffle progress
On 09/17/2013 09:41 PM, Paulo Motta wrote: So you're saying the only feasible way of enabling VNodes on an upgraded C* 1.2 is by doing fork writes to a brand new cluster + bulk load of sstables from the old cluster? Or is it possible to succeed on shuffling, even if that means waiting some weeks for the shuffle to complete? In a multi DC cluster situation you *should* be able to bring up a new DC with vnodes, bootstrap it, and then decommission the old cluster.
Re: [VOTE] Release Apache Cassandra 1.2.9
Following up on a discussion in IRC. A caveat on the (not new, but not
fixed) problems with replace_{node,token} would likely be appreciated by
users.
On 08/26/2013 02:53 PM, Sylvain Lebresne wrote:
The changelog is getting big, I propose the following artifacts for release
as 1.2.9.
sha1: ae62c947fc245295785324502bf6bc2c1c8477f9
Git:
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.2.9-tentative
Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-116/org/apache/cassandra/apache-cassandra/1.2.9/
Staging repository:
https://repository.apache.org/content/repositories/orgapachecassandra-116/
The artifacts as well as the debian package are also available here:
http://people.apache.org/~slebresne/
The vote will be open for 72 hours (longer if needed).
[1]: http://goo.gl/nfCb5Y (CHANGES.txt)
[2]: http://goo.gl/pxDqrc (NEWS.txt)
Re: JNA to activate cassandra row cache
On 08/19/2013 02:49 PM, CROCKETT, LEONARD P wrote: Must Cassandra 1.2.5 run as root for JNA jar to effectively disable swapping? It doesn't globally disable swap (which would require root), but don't swap this block of memory.
BRAF / FileChannel / sun.nio.ch.Util
CASSANDRA-2654 worked around a painful jdk bug [1]. In the course of trying to audit DirectByteBuffer use I've been trying to wrap my head around the interaction of BufferedRandomAccessFile and FileChannel. I admit that I'm as confused by nio as ever, but FileChannelImpl does appear to use Util.releaseTemporaryDirectBuffer. Do we have to work around [1] in BRAF just as we now do for IncomingTcpConnection? [1] http://bugs.sun.com/view_bug.do?bug_id=6210541
General usefulness of write only mode
I wanted to see if this was generally useful before I just made a ticket. The scenario is a read heavy workload. Running a major compaction or cleanup significantly reduces throughput to the point that the compaction drags on for a long time, performance dramatically degrades, etc. I can disablegossip which effectively disables all reads and writes while I run those tasks offline. But if my goal was to run cleanup across the cluster (say after another node was out for an extended period of time), this is a somewhat ironic proposition. What I wish I could do is disable reads but not write to the nodes. This would allow major compaction/repairs to proceed in a reasonable manner without hints building up on other nodes. Does this seem useful enough for inclusion, or is there a better way to solve the same problem?
re-using Cassandra's Bloom Filter
Hello all, Persuaded by Jonathan Ellis post [1] we started using Cassandra Bloom Filter implementation [2] when the need for one arose (which worked great by the way). That work grew into a stand alone library for tackling a related set of problems that we hope others find useful and are releasing: https://github.com/clearspring/stream-lib I've tried to make clear which code is primarily the work of Apache Cassandra committers both in the code and README (in many cases are changes are currently minimal). Please let me know if you have any questions or concerns. I think we have gotten all of the legal ts crossed but if you see anything amiss there we will fix it right away. Thank you, Chris Burroughs Developer | Clearspring Technologies [1] http://spyced.blogspot.com/2009/01/all-you-ever-wanted-to-know-about.html [2] Circa 2009 or so. Comparisons with the new implementation using OpenBitSet are on the proverbial todo list.
