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
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
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
+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:
+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:
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
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:
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.
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
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
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
11 matches
Mail list logo
