Re: CASSANDRA-13241 lower default chunk_length_in_kb

[Pavel Yaskevich]

On Thu, Oct 11, 2018 at 4:31 PM Ben Bromhead  wrote:

> This is something that's bugged me for ages, tbh the performance gain for
> most use cases far outweighs the increase in memory usage and I would even
> be in favor of changing the default now, optimizing the storage cost later
> (if it's found to be worth it).
>
> For some anecdotal evidence:
> 4kb is usually what we end setting it to, 16kb feels more reasonable given
> the memory impact, but what would be the point if practically, most folks
> set it to 4kb anyway?
>
> Note that chunk_length will largely be dependent on your read sizes, but 4k
> is the floor for most physical devices in terms of ones block size.
>

It might be worth while to investigate how splitting chunk size into data,
index and compaction sizes would affect performance.


>
> +1 for making this change in 4.0 given the small size and the large
> improvement to new users experience (as long as we are explicit in the
> documentation about memory consumption).
>
>
> On Thu, Oct 11, 2018 at 7:11 PM Ariel Weisberg  wrote:
>
> > Hi,
> >
> > This is regarding https://issues.apache.org/jira/browse/CASSANDRA-13241
> >
> > This ticket has languished for a while. IMO it's too late in 4.0 to
> > implement a more memory efficient representation for compressed chunk
> > offsets. However I don't think we should put out another release with the
> > current 64k default as it's pretty unreasonable.
> >
> > I propose that we lower the value to 16kb. 4k might never be the correct
> > default anyways as there is a cost to compression and 16k will still be a
> > large improvement.
> >
> > Benedict and Jon Haddad are both +1 on making this change for 4.0. In the
> > past there has been some consensus about reducing this value although
> maybe
> > with more memory efficiency.
> >
> > The napkin math for what this costs is:
> > "If you have 1TB of uncompressed data, with 64k chunks that's 16M chunks
> > at 8 bytes each (128MB).
> > With 16k chunks, that's 512MB.
> > With 4k chunks, it's 2G.
> > Per terabyte of data (pre-compression)."
> >
> >
> https://issues.apache.org/jira/browse/CASSANDRA-13241?focusedCommentId=15886621&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15886621
> >
> > By way of comparison memory mapping the files has a similar cost per 4k
> > page of 8 bytes. Multiple mappings makes this more expensive. With a
> > default of 16kb this would be 4x less expensive than memory mapping a
> file.
> > I only mention this to give a sense of the costs we are already paying. I
> > am not saying they are directly related.
> >
> > I'll wait a week for discussion and if there is consensus make the
> change.
> >
> > Regards,
> > Ariel
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> > --
> Ben Bromhead
> CTO | Instaclustr 
> +1 650 284 9692
> Reliability at Scale
> Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer
>

Re: Stabilising Internode Messaging in 4.0

[Pavel Yaskevich]

Great to see such a significant progress made in the area!

On Thu, Apr 4, 2019 at 1:13 PM Aleksey Yeschenko  wrote:

> I would like to propose CASSANDRA-15066 [1] - an important set of bug fixes
> and stability improvements to internode messaging code that Benedict, I,
> and others have been working on for the past couple of months.
>
> First, some context.   This work started off as a review of CASSANDRA-14503
> (Internode connection management is race-prone [2]), CASSANDRA-13630
> (Support large internode messages with netty) [3], and a pre-4.0
> confirmatory review of such a major new feature.
>
> However, as we dug in, we realized this was insufficient. With more than 50
> bugs uncovered [4] - dozens of them critical to correctness and/or
> stability of the system - a substantial rework was necessary to guarantee a
> solid internode messaging subsystem for the 4.0 release.
>
> In addition to addressing all of the uncovered bugs [4] that were unique to
> trunk + 13630 [3] + 14503 [2], we used this opportunity to correct some
> long-existing, pre-4.0 bugs and stability issues. For the complete list of
> notable bug fixes, read the comments to CASSANDRA-15066 [1]. But I’d like
> to highlight a few.
>
> # Lack of message integrity checks
>
> It’s known that TCP checksums are too weak [5] and Ethernet CRC cannot be
> relied upon [6] for integrity. With sufficient scale or time, you will hit
> bit flips. Sadly, most of the time these go undetected.  Cassandra’s
> replication model makes this issue much more serious, as the faulty data
> can infect the cluster.
>
> We recognised this problem, and recently introduced a fix for server-client
> messages, implementing CRCs in CASSANDRA-13304 (Add checksumming to the
> native protocol) [7].
>
> But until CASSANDRA-15066 [1] lands, this is also a critical flaw
> internode. We have addressed it by ensuring that no matter what, whether
> you use SSL or not, whether you use internode compression or not, a
> protocol level CRC is always present, for every message frame. It’s our
> deep and sincere belief that shipping a new implementation of the messaging
> protocol without application-level data integrity checks would be
> unacceptable for a modern database.
>

I'm all for introducing more correctness checks at all levels especially in
communication.
Having dealt with multiple data corruption bugs that could have been easily
prevented by
having a checksum, it's great to see that we are moving in this direction.


> # Lack of back-pressure and memory usage constraints
>
> As it stands today, it’s far too easy for a single slow node to become
> overwhelmed by messages from its peers.  Conversely, multiple coordinators
> can be made unstable by the backlog of messages to deliver to just one
> struggling node.
>
> To address this problem, we have introduced strict memory usage constraints
> that apply TCP-level back-pressure, on both outbound and inbound.  It is
> now impossible for a node to be swamped on inbound, and on outbound it is
> made significantly harder to overcommit resources.  It’s a simple, reliable
> mechanism that drastically improves cluster stability under load, and
> especially overload.
>
> Cassandra is a mature system, and introducing an entirely new messaging
> implementation without resolving this fundamental stability issue is
> difficult to justify in our view.
>

I'd say that this is required to be able to ship 4.0 as a release focused
on stability.
I personally have been waiting for this to happen for years. Significant
step forward in our QoS story.


>
> # State of the patch, feature freeze and 4.0 timeline concerns
>
> The patch is essentially complete, with much improved unit tests all
> passing, dtests green, and extensive fuzz testing underway - with initial
> results all positive.  We intend to further improve in-code documentation
> and test coverage in the next week or two, and do some minor additional
> code review, but we believe it will be basically good to commit in a couple
> weeks.
>
> The patch could also use some performance testing. We are hoping that our
> colleagues at Netflix and new Cassandra committers Joey and Vinay will help
> us with this aspect.  However, this work needs to be done regardless, so
> provides no significant delay.
>
> I would classify absolutely most of the work done in this patch as
> necessary bug fixes and stability improvements - in line with the stated
> goals of the feature freeze.
>
> The only clear “feature” introduced is the expanded metrics, and virtual
> tables to observe them.  If the freeze is to be strictly interpreted these
> can be removed, but we think this would be unwise.
>
> We hope that the community will appreciate and welcome these changes.
> We’ve worked hard to deliver this promptly, to minimise delays to 4.0 were
> these issues to be addressed piecemeal, and we sincerely believe this work
> will have a positive impact on stability and performance of Cassandra
> clusters for yea

Re: Stabilising Internode Messaging in 4.0

[Pavel Yaskevich]

On Thu, Apr 11, 2019 at 10:15 PM Joshua McKenzie 
wrote:

> As one of the two people that re-wrote all our unit tests to try and help
> Sylvain get 8099 out the door, I think it's inaccurate to compare the scope
> and potential stability impact of this work to the truly sweeping work that
> went into 8099 (not to downplay the scope and extent of this work here).
>
> TBH, one of the big reasons we tend to drop such large PRs is the fact that
> > Cassandra's code is highly intertwined and it makes it hard to precisely
> > change things. We need to iterate towards interfaces that allow us to
> > iterate quickly and reduce the amount of highly intertwined code. It
> helps
> > with testing as well. I want us to have a meaningful discussion around it
> > before we drop a big PR.
>
> This has been a huge issue with our codebase since at least back when I
> first encountered it five years ago. To date, while we have made progress
> on this front, it's been nowhere near sufficient to mitigate the issues in
> the codebase and allow for large, meaningful changes in smaller incremental
> patches or commits. Having yet another discussion around this (there have
> been many, many of them over the years) as a blocker for significant work
> to go into the codebase is an unnecessary and dangerous blocker. Not to say
> we shouldn't formalize a path to try and make incremental progress to
> improve the situation, far from it, but blocking other progress on a
> decade's worth of accumulated hygiene problems isn't going to make the
> community focus on fixing those problems imo, it'll just turn away
> contributions.
>

> So let me second jd (and many others') opinion here: "it makes sense to get
> it right the first time, rather than applying bandaids to 4.0 and rewriting
> things for 4.next". And fwiw, asking people who have already done a huge
> body of work to reformat that work into a series of commits or to break up
> that work in a fashion that's more to the liking of people not involved in
> either the writing of the patch or reviewing of it doesn't make much sense
> to me. As I am neither an assignee nor reviewer on this contribution, I
> leave it up to the parties involved to do things professionally and with a
> high standard of quality. Admittedly, a large code change merging in like
> this has implications for rebasing on anyone else's work that's in flight,
> but be it one commit merged or 50, or be it one JIRA ticket or ten, the
> end-result is the same; any large contribution in any format will ripple
> outwards and require re-work from others in the community.
>
The one thing I *would* strongly argue for is performance benchmarking of
> the new messaging code on a representative sample of different
> general-purpose queries, LWT's, etc, preferably in a 3 node RF=3 cluster,
> plus a healthy suite of jmh micro-benches (assuming they're not already in
> the diff. If they are, disregard / sorry). From speaking with Aleksey
> offline about this work, my understanding is that that's something they
> plan on doing before putting a bow on things.
>
> In the balance between "fear change because it destabilizes" and "go forth
> blindly into that dark night, rewriting All The Things", I think the
> Cassandra project's willingness to jettison the old and introduce the new
> has served it well in keeping relevant as the years have gone by. I'd hate
> to see that culture of progress get mired in a dogmatic adherence to
> requirements on commit counts, lines of code allowed / expected on a given
> patch set, or any other metrics that might stymie the professional needs of
> some of the heaviest contributors to the project.
>

+1. Based on all of the discussion here and in JIRA it seems to me that
we'd be doing a big disservice to the users by outright rejecting the
changes just
based on +/- LoC or complexity of review. From the points raised it seems
like
enabling encryption by default (or even making it the only available
option?),
upstreaming Netty related changes, possible steps to improve codebase, as
well as how the changes should be formatted to aid the reviewers could all
be discussed separately.

I think at the end of the day it _might be_ reasonable for PMC have a final
say on the matter,
maybe even on point-by-point basis.

>

>
> On Wed, Apr 10, 2019 at 5:03 PM Oleksandr Petrov <
> oleksandr.pet...@gmail.com>
> wrote:
>
> > Sorry to pick only a few points to address, but I think these are ones
> > where I can contribute productively to the discussion.
> >
> > > In principle, I agree with the technical improvements you
> > mention (backpressure / checksumming / etc). These things should be
> there.
> > Are they a hard requirement for 4.0?
> >
> > One thing that comes to mind is protocol versioning and consistency. If
> > changes adding checksumming and handshake do not make it to 4.0, we grow
> > the upgrade matrix and have to put changes to the separate protocol
> > version. I'm not sure how many other internode pr

Re: Stabilising Internode Messaging in 4.0

[Pavel Yaskevich]

On Fri, Apr 12, 2019 at 10:15 AM Jordan West  wrote:

> I understand these non-technical discussions are not what everyone wants to
> focus on but they are extremely pertinent to the stability of the project.
> What I would like to see before merging this in is below. They are all
> reasonable asks in my opinion that will still result in the patch being
> merged — only w/ even more confidence in its quality. More details on my
> thoughts behind it follow.
>
> 1. Additional third party/independent reviewers added and required before
> merge.
>
> 2. The patch should at a minimum be broken up (commit-wise, not ticket
> wise) so the newly added features (CRC/backpressure/virtual tables) can be
> reviewed independent of the large patch set and can be easily included or
> excluded based on community discussion or reviewer feedback — using the
> exception process for new features we have used in the past during this
> freeze (merging 13304 the day after freeze, the zstd changes, etc).
>
> 3. As Sankalp mentioned, and I believe is in progress, a test plan should
> be published and executed (or at least part of it should be execute before
> the merge, its possible some will happen post merge but this should be
> minimal).
>
> 4. A (design) doc should be published to make it easier for reviewers to
> approach the code.
>

I haven't actually looked at the code, but these seems like reasonable asks.

I'd expect mechanical changes split into separate commits, as well as (at
least)
categories (e.g. CRC and framing, backpreassure) that Benedict/Aleksey
outlined.
Design doc would be great at least for posterity sake.


> With the above said, I apologize if the 8099 comment was a parallel that
> was too close to home for some. I am sure they are not direct comparison
> but the parallel I was trying to draw (and continue to) is that the
> development process that led to a project like 8099 continues to be used
> here. My focus for Cassandra is improving Quality and Stability of 4.0 (and
> ideally the 3.x series along the way) — especially in light of the recent
> status email I sent that included over 25 bugs found in the last 6 months.
>
> There is no question that the majority of this patch should go in — the bug
> fixes are necessary and we have no alternatives written. The question to
> me, besides increasing confidence in the patch, is can the authors make
> this better for reviewers by putting some more effort into the
> non-technical aspects of the patch and should the new features be included
> given the already risky changes proposed in this patch and the demand to
> review them?  The goal of the freeze was to reduce the time spent on new
> work so we can improve what existed. We do have a process for exceptions to
> that and if the community feels strongly about these features then we
> should follow that process — which would involve isolating the changes from
> the larger patch and having them be considered separately.
>
> Further, as someone who has reviewed 13304 and found a bug others didn’t, I
> don’t think having the code authors dictate the complexity or timeframe of
> the review makes sense. Thats not to say I didn’t read the email as
> suggested.  I encourage you to consider that its possible my experience
> informed my contrary point of view and how that sort of denigrating and
> unneeded comment affects the community.
>
> Anyways, part of those improvements have to come from how we design and
> develop the database. Not just how we test and run it. Having worked on
> several large projects on multiple databases (Cassandra’s SASI*, Riak’s
> Cluster Metadata / Membership, Riak’s bucket types, and Riak’s ring
> resizing feature, among others) and for large companies (those projects I
> can’t talk about), I am sure it is possible to design and develop features
> with a better process than the one used here. It is certainly possible, and
> hugely beneficial, to break up code into smaller commits (Google also feels
> this way: https://arxiv.org/pdf/1702.01715.pdf) and its not unreasonable
> to
> ask by any means. It should be a pre-requisite. A patch like this requires
> more from the authors than simply writing the code. Holding ourselves to a
> higher standard will increase the quality of the database dramatically. The
> same way committing to real testing has done (I again refer to all of the
> bugs found during the freeze that were not found previously).
>
> Hopefully its clear from the above that I am very supportive of getting the
> majority of these changes in. I think it would benefit the future of the
> project if we did that in a more deliberate way than how risky changes like
> this, late in the cycle, were handled in the past. We have an opportunity
> to change that here and it would benefit the project significantly.
> Cassandra’s willingness to jettison code has kept it relevant. Its process
> for doing so however has had negative effects on the databases brand — the
> deployment of the 3.x ser

Re: Stabilising Internode Messaging in 4.0

[Pavel Yaskevich]

It seems to me that the corner stone here is the development process.
If the work and review is done openly (e.g. on JIRA or Github) we
wouldn't be having this post factum conversation, because all of the
progress would be visible, so it would make sense to just squash before
committing
if so preferred.

It's indeed not really bisect friendly to drop squashed changes into the
repository,
but I've been guilty of that myself with SASI for a number of reasons, so I
can't
blame authors for this without sounding hypocritical.

As I mentioned before I would be great if we could establish the process for
how the development is supposed to happen, like other projects do. But it,
as most of the other concerns, (if not all of them) could be discussed
separately.


On Fri, Apr 12, 2019 at 1:25 PM Benedict Elliott Smith 
wrote:

> Can you start a new thread to build consensus on your proposals for
> modifying the commit process?
>
> I do not share your views, as already laid out in my first email.  The
> community makes these decisions through building consensus, and potentially
> a vote of the PMC.  This scope of change requires its own thread of
> discussion.
>
>
>
> > On 12 Apr 2019, at 20:46, Jordan West  wrote:
> >
> > Since their seems to be an assumption that I haven’t read the code let me
> > clarify: I am working on making time to be a reviewer on this and I have
> > already spent a few hours with the patch before I sent any replies,
> likely
> > more than most who are replying here. Again, because I disagree on
> > non-technical matters does not mean I haven’t considered the technical. I
> > am sharing what I think is necessary for the authors
> > to make review higher quality. I will not compromise my review standards
> on
> > a patch like this as I have said already. Telling me to review it to talk
> > more about it directly ignores my feedback and requires me to acquiesce
> all
> > of my concerns, which as I said I won’t do as a reviewer.
> >
> > And yes I am arguing for changing how the Cassandra community approaches
> > large patches. In the same way the freeze changed how we approached major
> > releases and the decision to do so has been a net benefit as measured by
> > quality and stability. Existing community members have already chimed in
> in
> > support of things like better commit hygiene.
> >
> > The past approaches haven’t prioritized quality and stability and it
> really
> > shows. What I and others here are suggesting has worked all over our
> > industry and is adopted by companies big (like google as i linked
> > previously) and small (like many startups I and others have worked for).
> > Everything we want to do: better testing, better review, better code, is
> > made easier with better design review, better discussion, and more
> > digestible patches among many of the other things suggested in this
> thread.
> >
> > Jordan
> >
> > On Fri, Apr 12, 2019 at 12:01 PM Benedict Elliott Smith <
> bened...@apache.org>
> > wrote:
> >
> >> I would once again exhort everyone making these kinds of comment to
> >> actually read the code, and to comment on Jira.  Preferably with a
> >> justification by reference to the code for how or why it would improve
> the
> >> patch.
> >>
> >> As far as a design document is concerned, it’s very unclear what is
> being
> >> requested.  We already had plans, as Jordan knows, to produce a wiki
> page
> >> for posterity, and a blog post closer to release.  However, I have never
> >> heard of this as a requirement for review, or for commit.  We have so
> far
> >> taken two members of the community through the patch over video chat,
> and
> >> would be more than happy to do the same for others.  So far nobody has
> had
> >> any difficulty getting to grips with its structure.
> >>
> >> If the project wants to modify its normal process for putting a patch
> >> together, this is a whole different can of worms, and I am strongly -1.
> >> I’m not sure what precedent we’re trying to set imposing arbitrary
> >> constraints pre-commit for work that has already met the project’s
> >> inclusion criteria.
> >>
> >>
> >>> On 12 Apr 2019, at 18:58, Pavel Yaskevich  wrote:
> >>>
> >>> I haven't actually looked at the code
> >>
> >>
> >>
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [DISCUSS] governance on the Apache Cassandra project

[Pavel Yaskevich]

On Mon, Jun 8, 2020 at 3:12 AM Mick Semb Wever  wrote:

> > > With regards to CEPs, I personally don't see any value in voting to
> start
> > one.
> >
> > Agree with this, and I'd go even further - requiring a vote in order to
> > propose an idea runs so counter to the idea of a CEP that it would
> default
> > the purpose of even having them.  The CEP is the _proposal_ for a change
> > that gets fleshed out enough so people can understand the idea and _then_
> > vote on it, not the other way around.
>
>
> Totally agree that CEPs should be as light-weight as possible, and with the
> sentiments above. But would also like to keep the discussion open to
> encourage and include as many voices as possible.
>
> My _questioning_ is around the value in "initial exposure and discussion".
> It is implied already that there is lazy consensus in starting a CEP, and
> that starting a CEP is more than just an initial proposal of an idea. One
> example is we require a CEP to have a Shepherd that is a PMC member.
> Encouraging a vote, or better-yet keeping it light-weight: an initial
> DISCUSS thread as early as possible in the CEP lifecycle does come with
> value. From openly calling out for a Shepherd, to allowing the more
> experienced community members to add their insight (without having to get
> formally involved in it), there's potential value in encouraging such
> open-mode opening discussion early on (versus the cost of additional
> process).
>
> Really interested in hearing from folk from other communities and projects
> that do CEP/CIP and how their lifecycle through the process works and what
> they have learnt.
>

Here is a description of the process Swift Programming Language uses -
https://github.com/apple/swift-evolution/blob/master/process.md.

Re: [VOTE] Release Apache Cassandra 2.0.17

[Pavel Yaskevich]

+1

On Wed, Sep 16, 2015 at 11:45 AM, Brandon Williams  wrote:

> +1
>
> On Wed, Sep 16, 2015 at 1:29 PM, Jake Luciani  wrote:
>
> > I propose the following artifacts for release as 2.0.17.
> >
> > sha1: 3aff44915edbd2bf07955d5b30fd47bf9c4698da
> > Git:
> >
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.0.17-tentative
> > Artifacts:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1078/org/apache/cassandra/apache-cassandra/2.0.17/
> > Staging repository:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1078/
> >
> > The artifacts as well as the debian package are also available here:
> > http://people.apache.org/~jake
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: http://goo.gl/1g0t58 (CHANGES.txt)
> > [2]: http://goo.gl/SHN2y3 (NEWS.txt)
> >
>

Re: [VOTE] Release Apache Cassandra 2.0.17 (Attempt #2)

[Pavel Yaskevich]

+1

On Fri, Sep 18, 2015 at 8:20 AM, Brandon Williams  wrote:

> +1
>
> On Fri, Sep 18, 2015 at 9:47 AM, Jake Luciani  wrote:
>
> > I propose the following artifacts for release as 2.0.17.
> >
> > sha1: c4de752758c3cf7f5de5a92e4ede30e430a36255
> > Git:
> >
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.0.17-tentative
> > Artifacts:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1079/org/apache/cassandra/apache-cassandra/2.0.17/
> > Staging repository:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1079/
> >
> > The artifacts as well as the debian package are also available here:
> > http://people.apache.org/~jake
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: http://goo.gl/1g0t58 (CHANGES.txt)
> > [2]: http://goo.gl/SHN2y3 (NEWS.txt)
> >
>

Re: [VOTE] Release Apache Cassandra 3.0.0

[Pavel Yaskevich]

+1

On Fri, Nov 6, 2015 at 3:00 PM, Aleksey Yeschenko 
wrote:

> +1
>
> --
> AY
>
> On 6 November 2015 at 21:35:06, Jake Luciani (j...@apache.org) wrote:
>
> I propose the following artifacts for release as 3.0.0.
>
> sha1: 96f407bce56b98cd824d18e32ee012dbb99a0286
> Git:
>
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.0-tentative
> Artifacts:
>
> https://repository.apache.org/content/repositories/orgapachecassandra-1089/org/apache/cassandra/apache-cassandra/3.0.0/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1089/
>
> The artifacts as well as the debian package are also available here:
> http://people.apache.org/~jake
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: http://goo.gl/0vghCL (CHANGES.txt)
> [2]: http://goo.gl/xAElQy (NEWS.txt)
>

Re: [VOTE] Release Apache Cassandra 3.4

[Pavel Yaskevich]

+1

> On Mar 4, 2016, at 5:43 PM, Jake Luciani  wrote:
> 
> I propose the following artifacts for release as 3.4.
> 
> sha1: 70649a8d65825144fcdbde136d9b6354ef1fb911
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.4-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1103/org/apache/cassandra/apache-cassandra/3.4/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1103/
> 
> The artifacts as well as the debian package are also available here:
> http://people.apache.org/~jake
> 
> The vote will be open for 72 hours (longer if needed).
> 
> [1]: http://goo.gl/j9D9Se (CHANGES.txt)
> [2]: http://goo.gl/6R89cS (NEWS.txt)
> [3]: https://goo.gl/K5LkEL (DataStax Test Report)

Re: Plans to support OR?

[Pavel Yaskevich]

Hi Henry,

   Yes, I'm currently working toward that (
https://issues.apache.org/jira/browse/CASSANDRA-0),
   such would require some major changes to the way select statements are
executed but we are going to get there soon.

Best Regards, Pavel.

On Mon, Mar 28, 2016 at 12:35 PM, Henry M  wrote:

> Is there a plan for supporting OR in Cassandra queries?
>
> The following page points out there will be future changes to add OR
> support but I could not find a Jira ticket.
>
>- https://github.com/apache/cassandra/blob/trunk/doc/SASI.md
>*"Not Equals and OR support have been removed in this release while
>changes are made to Cassandra itself to support them."*
>
> Thank you,
> Henry
>

Re: [VOTE] Release Apache Cassandra 3.5

[Pavel Yaskevich]

There is a bug in SASI indexes we have introduced in 3.5 - CASSANDRA-11525,
I'm not sure if we want to postpone release until we work it out.

On Thu, Apr 7, 2016 at 3:19 PM, Brandon Williams  wrote:

> +1
>
> On Thu, Apr 7, 2016 at 5:19 PM, Jake Luciani  wrote:
>
> > I propose the following artifacts for release as 3.5.
> >
> > sha1: 89bd93502ac141f8cd13f8738bb4314488db2a5a
> > Git:
> >
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.5-tentative
> > Artifacts:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1105/org/apache/cassandra/apache-cassandra/3.5/
> > Staging repository:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1105/
> >
> > The artifacts as well as the debian package are also available here:
> > http://people.apache.org/~jake
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: http://goo.gl/v1sH4v (CHANGES.txt)
> > [2]: http://goo.gl/ZlHf5z (NEWS.txt)
> > [3]: https://goo.gl/hvPmFE (DataStax Test Report)
> >
>

Re: [VOTE] Release Apache Cassandra 3.5

[Pavel Yaskevich]

Yes, it's a new regression because, so far, it looks like it's a result of
us fixing OOM problem discovered in 3.4.

On Thu, Apr 7, 2016 at 3:35 PM, Jonathan Ellis  wrote:

> So it's a new regression, not present in 3.4?
>
> On Thu, Apr 7, 2016 at 5:24 PM, Pavel Yaskevich  wrote:
>
> > There is a bug in SASI indexes we have introduced in 3.5 -
> CASSANDRA-11525,
> > I'm not sure if we want to postpone release until we work it out.
> >
> > On Thu, Apr 7, 2016 at 3:19 PM, Brandon Williams 
> wrote:
> >
> > > +1
> > >
> > > On Thu, Apr 7, 2016 at 5:19 PM, Jake Luciani  wrote:
> > >
> > > > I propose the following artifacts for release as 3.5.
> > > >
> > > > sha1: 89bd93502ac141f8cd13f8738bb4314488db2a5a
> > > > Git:
> > > >
> > > >
> > >
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.5-tentative
> > > > Artifacts:
> > > >
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1105/org/apache/cassandra/apache-cassandra/3.5/
> > > > Staging repository:
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1105/
> > > >
> > > > The artifacts as well as the debian package are also available here:
> > > > http://people.apache.org/~jake
> > > >
> > > > The vote will be open for 72 hours (longer if needed).
> > > >
> > > > [1]: http://goo.gl/v1sH4v (CHANGES.txt)
> > > > [2]: http://goo.gl/ZlHf5z (NEWS.txt)
> > > > [3]: https://goo.gl/hvPmFE (DataStax Test Report)
> > > >
> > >
> >
>
>
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>

Re: [VOTE] Release Apache Cassandra 3.5

[Pavel Yaskevich]

Ok, I will let you know if that's actually is a problem and if so we'll
revert it from 3.5.

On Thu, Apr 7, 2016 at 3:46 PM, Jonathan Ellis  wrote:

> I'd recommend then that we revert the OOM fix, release 3.5 on-schedule-ish,
> and release an updated fix in 3.6.
>
> On Thu, Apr 7, 2016 at 5:42 PM, Pavel Yaskevich  wrote:
>
> > Yes, it's a new regression because, so far, it looks like it's a result
> of
> > us fixing OOM problem discovered in 3.4.
> >
> > On Thu, Apr 7, 2016 at 3:35 PM, Jonathan Ellis 
> wrote:
> >
> > > So it's a new regression, not present in 3.4?
> > >
> > > On Thu, Apr 7, 2016 at 5:24 PM, Pavel Yaskevich 
> > wrote:
> > >
> > > > There is a bug in SASI indexes we have introduced in 3.5 -
> > > CASSANDRA-11525,
> > > > I'm not sure if we want to postpone release until we work it out.
> > > >
> > > > On Thu, Apr 7, 2016 at 3:19 PM, Brandon Williams 
> > > wrote:
> > > >
> > > > > +1
> > > > >
> > > > > On Thu, Apr 7, 2016 at 5:19 PM, Jake Luciani 
> > wrote:
> > > > >
> > > > > > I propose the following artifacts for release as 3.5.
> > > > > >
> > > > > > sha1: 89bd93502ac141f8cd13f8738bb4314488db2a5a
> > > > > > Git:
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.5-tentative
> > > > > > Artifacts:
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1105/org/apache/cassandra/apache-cassandra/3.5/
> > > > > > Staging repository:
> > > > > >
> > > > >
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1105/
> > > > > >
> > > > > > The artifacts as well as the debian package are also available
> > here:
> > > > > > http://people.apache.org/~jake
> > > > > >
> > > > > > The vote will be open for 72 hours (longer if needed).
> > > > > >
> > > > > > [1]: http://goo.gl/v1sH4v (CHANGES.txt)
> > > > > > [2]: http://goo.gl/ZlHf5z (NEWS.txt)
> > > > > > [3]: https://goo.gl/hvPmFE (DataStax Test Report)
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Jonathan Ellis
> > > Project Chair, Apache Cassandra
> > > co-founder, http://www.datastax.com
> > > @spyced
> > >
> >
>
>
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>

Re: [VOTE] Release Apache Cassandra 3.5

[Pavel Yaskevich]

So it looks like that changes in CASSANDRA-11383 caused the problem, but we
have a non-intrusive solution for it and we should be able to make
it work by tomorrow, if you still think it is too late for 3.5 we can
revert but it would be better to have 3.5 CASSANDRA-11383 + CASSANDRA-11525.

On Thu, Apr 7, 2016 at 3:48 PM, Pavel Yaskevich  wrote:

> Ok, I will let you know if that's actually is a problem and if so we'll
> revert it from 3.5.
>
> On Thu, Apr 7, 2016 at 3:46 PM, Jonathan Ellis  wrote:
>
>> I'd recommend then that we revert the OOM fix, release 3.5
>> on-schedule-ish,
>> and release an updated fix in 3.6.
>>
>> On Thu, Apr 7, 2016 at 5:42 PM, Pavel Yaskevich 
>> wrote:
>>
>> > Yes, it's a new regression because, so far, it looks like it's a result
>> of
>> > us fixing OOM problem discovered in 3.4.
>> >
>> > On Thu, Apr 7, 2016 at 3:35 PM, Jonathan Ellis 
>> wrote:
>> >
>> > > So it's a new regression, not present in 3.4?
>> > >
>> > > On Thu, Apr 7, 2016 at 5:24 PM, Pavel Yaskevich 
>> > wrote:
>> > >
>> > > > There is a bug in SASI indexes we have introduced in 3.5 -
>> > > CASSANDRA-11525,
>> > > > I'm not sure if we want to postpone release until we work it out.
>> > > >
>> > > > On Thu, Apr 7, 2016 at 3:19 PM, Brandon Williams 
>> > > wrote:
>> > > >
>> > > > > +1
>> > > > >
>> > > > > On Thu, Apr 7, 2016 at 5:19 PM, Jake Luciani 
>> > wrote:
>> > > > >
>> > > > > > I propose the following artifacts for release as 3.5.
>> > > > > >
>> > > > > > sha1: 89bd93502ac141f8cd13f8738bb4314488db2a5a
>> > > > > > Git:
>> > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.5-tentative
>> > > > > > Artifacts:
>> > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://repository.apache.org/content/repositories/orgapachecassandra-1105/org/apache/cassandra/apache-cassandra/3.5/
>> > > > > > Staging repository:
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://repository.apache.org/content/repositories/orgapachecassandra-1105/
>> > > > > >
>> > > > > > The artifacts as well as the debian package are also available
>> > here:
>> > > > > > http://people.apache.org/~jake
>> > > > > >
>> > > > > > The vote will be open for 72 hours (longer if needed).
>> > > > > >
>> > > > > > [1]: http://goo.gl/v1sH4v (CHANGES.txt)
>> > > > > > [2]: http://goo.gl/ZlHf5z (NEWS.txt)
>> > > > > > [3]: https://goo.gl/hvPmFE (DataStax Test Report)
>> > > > > >
>> > > > >
>> > > >
>> > >
>> > >
>> > >
>> > > --
>> > > Jonathan Ellis
>> > > Project Chair, Apache Cassandra
>> > > co-founder, http://www.datastax.com
>> > > @spyced
>> > >
>> >
>>
>>
>>
>> --
>> Jonathan Ellis
>> Project Chair, Apache Cassandra
>> co-founder, http://www.datastax.com
>> @spyced
>>
>
>

Re: [VOTE] Release Apache Cassandra 3.5

[Pavel Yaskevich]

Alright, we've figured what the problem is in CASSANDRA-11525, I'm running
last tests on my machine, going to push changes into my branch soon, wait
for dtest/testall to run and merge later tonight.
So we should be on track for 3.5 vote tomorrow.

On Fri, Apr 8, 2016 at 5:15 AM, Sylvain Lebresne 
wrote:

> We also realized that some commits had been badly merge to trunk some times
> ago (3.0 isn't affected) on
> https://issues.apache.org/jira/browse/CASSANDRA-11353, so it also makes
> sense to re-roll for those since they were supposed to be fixed a long time
> ago and at least #11353 is worth not delaying further.
> I'll note that we've already backported those missing tickets to the
> cassandra-3.5 branch so we're good to re-roll from that branch as soon as
> the SASI problem is fixed.
>
> On Fri, Apr 8, 2016 at 2:54 AM, Jonathan Ellis  wrote:
>
> > Tomorrow should be fine.  Thanks!
> >
> > On Thu, Apr 7, 2016 at 7:45 PM, Pavel Yaskevich 
> wrote:
> >
> > > So it looks like that changes in CASSANDRA-11383 caused the problem,
> but
> > we
> > > have a non-intrusive solution for it and we should be able to make
> > > it work by tomorrow, if you still think it is too late for 3.5 we can
> > > revert but it would be better to have 3.5 CASSANDRA-11383 +
> > > CASSANDRA-11525.
> > >
> > > On Thu, Apr 7, 2016 at 3:48 PM, Pavel Yaskevich 
> > wrote:
> > >
> > > > Ok, I will let you know if that's actually is a problem and if so
> we'll
> > > > revert it from 3.5.
> > > >
> > > > On Thu, Apr 7, 2016 at 3:46 PM, Jonathan Ellis 
> > > wrote:
> > > >
> > > >> I'd recommend then that we revert the OOM fix, release 3.5
> > > >> on-schedule-ish,
> > > >> and release an updated fix in 3.6.
> > > >>
> > > >> On Thu, Apr 7, 2016 at 5:42 PM, Pavel Yaskevich 
> > > >> wrote:
> > > >>
> > > >> > Yes, it's a new regression because, so far, it looks like it's a
> > > result
> > > >> of
> > > >> > us fixing OOM problem discovered in 3.4.
> > > >> >
> > > >> > On Thu, Apr 7, 2016 at 3:35 PM, Jonathan Ellis  >
> > > >> wrote:
> > > >> >
> > > >> > > So it's a new regression, not present in 3.4?
> > > >> > >
> > > >> > > On Thu, Apr 7, 2016 at 5:24 PM, Pavel Yaskevich <
> > pove...@gmail.com>
> > > >> > wrote:
> > > >> > >
> > > >> > > > There is a bug in SASI indexes we have introduced in 3.5 -
> > > >> > > CASSANDRA-11525,
> > > >> > > > I'm not sure if we want to postpone release until we work it
> > out.
> > > >> > > >
> > > >> > > > On Thu, Apr 7, 2016 at 3:19 PM, Brandon Williams <
> > > dri...@gmail.com>
> > > >> > > wrote:
> > > >> > > >
> > > >> > > > > +1
> > > >> > > > >
> > > >> > > > > On Thu, Apr 7, 2016 at 5:19 PM, Jake Luciani <
> j...@apache.org
> > >
> > > >> > wrote:
> > > >> > > > >
> > > >> > > > > > I propose the following artifacts for release as 3.5.
> > > >> > > > > >
> > > >> > > > > > sha1: 89bd93502ac141f8cd13f8738bb4314488db2a5a
> > > >> > > > > > Git:
> > > >> > > > > >
> > > >> > > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.5-tentative
> > > >> > > > > > Artifacts:
> > > >> > > > > >
> > > >> > > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1105/org/apache/cassandra/apache-cassandra/3.5/
> > > >> > > > > > Staging repository:
> > > >> > > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1105/
> > > >> > > > > >
> > > >> > > > > > The artifacts as well as the debian package are also
> > available
> > > >> > here:
> > > >> > > > > > http://people.apache.org/~jake
> > > >> > > > > >
> > > >> > > > > > The vote will be open for 72 hours (longer if needed).
> > > >> > > > > >
> > > >> > > > > > [1]: http://goo.gl/v1sH4v (CHANGES.txt)
> > > >> > > > > > [2]: http://goo.gl/ZlHf5z (NEWS.txt)
> > > >> > > > > > [3]: https://goo.gl/hvPmFE (DataStax Test Report)
> > > >> > > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > --
> > > >> > > Jonathan Ellis
> > > >> > > Project Chair, Apache Cassandra
> > > >> > > co-founder, http://www.datastax.com
> > > >> > > @spyced
> > > >> > >
> > > >> >
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Jonathan Ellis
> > > >> Project Chair, Apache Cassandra
> > > >> co-founder, http://www.datastax.com
> > > >> @spyced
> > > >>
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Jonathan Ellis
> > Project Chair, Apache Cassandra
> > co-founder, http://www.datastax.com
> > @spyced
> >
>

Re: [VOTE] Release Apache Cassandra 3.5

[Pavel Yaskevich]

CASSANDRA-11525 is resolved now, I think we can restart the vote if that
was the only blocker.

On Fri, Apr 8, 2016 at 5:57 PM, Pavel Yaskevich  wrote:

> Alright, we've figured what the problem is in CASSANDRA-11525, I'm running
> last tests on my machine, going to push changes into my branch soon, wait
> for dtest/testall to run and merge later tonight.
> So we should be on track for 3.5 vote tomorrow.
>
> On Fri, Apr 8, 2016 at 5:15 AM, Sylvain Lebresne 
> wrote:
>
>> We also realized that some commits had been badly merge to trunk some
>> times
>> ago (3.0 isn't affected) on
>> https://issues.apache.org/jira/browse/CASSANDRA-11353, so it also makes
>> sense to re-roll for those since they were supposed to be fixed a long
>> time
>> ago and at least #11353 is worth not delaying further.
>> I'll note that we've already backported those missing tickets to the
>> cassandra-3.5 branch so we're good to re-roll from that branch as soon as
>> the SASI problem is fixed.
>>
>> On Fri, Apr 8, 2016 at 2:54 AM, Jonathan Ellis  wrote:
>>
>> > Tomorrow should be fine.  Thanks!
>> >
>> > On Thu, Apr 7, 2016 at 7:45 PM, Pavel Yaskevich 
>> wrote:
>> >
>> > > So it looks like that changes in CASSANDRA-11383 caused the problem,
>> but
>> > we
>> > > have a non-intrusive solution for it and we should be able to make
>> > > it work by tomorrow, if you still think it is too late for 3.5 we can
>> > > revert but it would be better to have 3.5 CASSANDRA-11383 +
>> > > CASSANDRA-11525.
>> > >
>> > > On Thu, Apr 7, 2016 at 3:48 PM, Pavel Yaskevich 
>> > wrote:
>> > >
>> > > > Ok, I will let you know if that's actually is a problem and if so
>> we'll
>> > > > revert it from 3.5.
>> > > >
>> > > > On Thu, Apr 7, 2016 at 3:46 PM, Jonathan Ellis 
>> > > wrote:
>> > > >
>> > > >> I'd recommend then that we revert the OOM fix, release 3.5
>> > > >> on-schedule-ish,
>> > > >> and release an updated fix in 3.6.
>> > > >>
>> > > >> On Thu, Apr 7, 2016 at 5:42 PM, Pavel Yaskevich > >
>> > > >> wrote:
>> > > >>
>> > > >> > Yes, it's a new regression because, so far, it looks like it's a
>> > > result
>> > > >> of
>> > > >> > us fixing OOM problem discovered in 3.4.
>> > > >> >
>> > > >> > On Thu, Apr 7, 2016 at 3:35 PM, Jonathan Ellis <
>> jbel...@gmail.com>
>> > > >> wrote:
>> > > >> >
>> > > >> > > So it's a new regression, not present in 3.4?
>> > > >> > >
>> > > >> > > On Thu, Apr 7, 2016 at 5:24 PM, Pavel Yaskevich <
>> > pove...@gmail.com>
>> > > >> > wrote:
>> > > >> > >
>> > > >> > > > There is a bug in SASI indexes we have introduced in 3.5 -
>> > > >> > > CASSANDRA-11525,
>> > > >> > > > I'm not sure if we want to postpone release until we work it
>> > out.
>> > > >> > > >
>> > > >> > > > On Thu, Apr 7, 2016 at 3:19 PM, Brandon Williams <
>> > > dri...@gmail.com>
>> > > >> > > wrote:
>> > > >> > > >
>> > > >> > > > > +1
>> > > >> > > > >
>> > > >> > > > > On Thu, Apr 7, 2016 at 5:19 PM, Jake Luciani <
>> j...@apache.org
>> > >
>> > > >> > wrote:
>> > > >> > > > >
>> > > >> > > > > > I propose the following artifacts for release as 3.5.
>> > > >> > > > > >
>> > > >> > > > > > sha1: 89bd93502ac141f8cd13f8738bb4314488db2a5a
>> > > >> > > > > > Git:
>> > > >> > > > > >
>> > > >> > > > > >
>> > > >> > > > >
>> > > >> > > >
>> > > >> > >
>> > > >> >
>> > > >>
>> > >
>> >
>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.5-tentative
>> > > &g

Re: [VOTE] Release Apache Cassandra 3.5 (Attempt #2)

[Pavel Yaskevich]

+1

> On Apr 10, 2016, at 9:52 AM, Codarren Velvindron  wrote:
> 
> +1
>> On 10 Apr 2016 19:54, "Brandon Williams"  wrote:
>> 
>> +1
>> 
>>> On Sun, Apr 10, 2016 at 10:43 AM, Jake Luciani  wrote:
>>> 
>>> I propose the following artifacts for release as 3.5.
>>> 
>>> sha1: 020dd2d1034abc5c729edf1975953614b33c5a8b
>>> Git:
>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.5-tentative
>>> Artifacts:
>> https://repository.apache.org/content/repositories/orgapachecassandra-1106/org/apache/cassandra/apache-cassandra/3.5/
>>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapachecassandra-1106/
>>> 
>>> The artifacts as well as the debian package are also available here:
>>> http://people.apache.org/~jake
>>> 
>>> The vote will be open for 72 hours (longer if needed).
>>> 
>>> [1]: http://goo.gl/v1sH4v (CHANGES.txt)
>>> [2]: http://goo.gl/ZlHf5z (NEWS.txt)
>> 

Re: Cassandra Java Driver and DataStax

[Pavel Yaskevich]

Hi Chris,

   On a similar note to what Andres mentioned, me and couple of other
people have recently contributed index implementation (SASI), which
significantly extends
   indexing capabilities of Apache Cassandra, and might be one of the
biggest changes to the database in years.
   I'm a member of PMC for the project and I am not affiliated with
DataStax and although SASI introduces conflict of interests with DSE,
   similar (if not greater) to the work Andres is doing at Stratio, I have
only received positive feedback and help from development community -
people helped to review changes, added new features, contributed tests,
   wrote blog posts about it, organized meetups etc.

Best Regards, Pavel.


On Mon, Jun 6, 2016 at 4:43 PM, Chris Mattmann  wrote:

> Thanks Jonathan.
>
> I have seen several people replying back and citing general
> technical benefits again to having different drivers hosted
> elsewhere. I have also seen people say, “well it’s ALv2
> and open source, so people can fork it and blah and blah”.
>
> “Opensource” and “ALv2” don’t necessarily a community make and
> I think that point is a little lost amongst people who are
> part of this Apache PMC.
>
> Thanks for being willing to update the report as I asked and
> I look forward to your thoughts and the community thinking
> on this and reviewing it with my board hat on.
>
> Cheers,
> Chris
>
>
>
>
> On 6/6/16, 3:19 PM, "Jonathan Ellis"  wrote:
>
> >I’m happy to consult with my peers in other projects for the board report
> >and summarize their ideas and Cassandra PMC's to improve contributor
> >diversity.  I’ll plan to attend the meeting in person to discuss this
> >further.
> >
> >On Sun, Jun 5, 2016 at 5:33 PM, Mattmann, Chris A (3980) <
> >chris.a.mattm...@jpl.nasa.gov> wrote:
> >
> >> Thanks for the info Jonathan. I think have assessed based on
> >> the replies thus far, my studying of the archives and
> >> commit and project history the following situation.
> >>
> >> Unfortunately it seems like there is a bit of control going on
> >> I’m going to call a spade a spade here. A key portion of your
> >> software’s stack, a client driver to use it, exists outside of
> >> Apache in separate communities. This is an inherent risk to the
> >> project. Some of you cite flexibility and adaptability as reasons
> >> for this - I’ve seen it in so many communities over the last 12+
> >> years in the foundation - it’s not really due to those issues.
> >> There is definitely some control going on. I would ask you all
> >> this - has there been a PR or patch in the past year or two that
> >> wasn’t singularly reviewed by DataStax committers and PMC? Also,
> >> as to the composition of the PMC when was the last time a non
> >> DataStax person was elected to the PMC and/or as a committer?
> >>
> >> By itself the diversity issues alone are not damning to the
> >> project, but taken together with the citation to other project
> >> communities even those outside of Apache (e.g., the comments
> >> well “Postgres does it this way, so it’s a good example to
> >> compare us to” or “these other 4 projects at the ASF do it
> >> like this, so X”.. [sic]) and with the perception being created
> >> to those that don’t work at DataStax, and there is an issue here.
> >>
> >> I would like to see a discussion in your next board report about
> >> the diversity and health issues of the project, and also some
> >> ideas about potential strategies for mitigation.
> >>
> >> I appreciate the open and honest conversation thus far. Let’s
> >> keep it up.
> >>
> >> Cheers,
> >> Chris
> >>
> >> ++
> >> Chris Mattmann, Ph.D.
> >> Chief Architect
> >> Instrument Software and Science Data Systems Section (398)
> >> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> >> Office: 168-519, Mailstop: 168-527
> >> Email: chris.a.mattm...@nasa.gov
> >> WWW:  http://sunset.usc.edu/~mattmann/
> >> ++
> >> Director, Information Retrieval and Data Science Group (IRDS)
> >> Adjunct Associate Professor, Computer Science Department
> >> University of Southern California, Los Angeles, CA 90089 USA
> >> WWW: http://irds.usc.edu/
> >> ++
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On 6/5/16, 1:51 PM, "Jonathan Ellis"  wrote:
> >>
> >> >On Sun, Jun 5, 2016 at 8:32 AM, Mattmann, Chris A (3980) <
> >> >chris.a.mattm...@jpl.nasa.gov> wrote:
> >> >
> >> >> 1. Is Apache Cassandra useful *without* a driver? That is, can
> >> >> you use the database without a driver to connect to it or in the
> >> >> real world would your users all have to download at least one
> >> >> driver in order to use the DB?
> >> >>
> >> >
> >> >The users do need to download a driver--but this is pretty normal for
> >> >community-driven OSS databases.  Besides the Apache projects I listed,
> >> >PostgreSQL also runs on a communi

Re: [VOTE] Release Apache Cassandra 3.8

[Pavel Yaskevich]

+1

On Wed, Jul 20, 2016 at 5:09 PM, Aleksey Yeschenko 
wrote:

> +1
>
> --
> AY
>
> On 20 July 2016 at 22:48:09, Michael Shuler (mshu...@apache.org) wrote:
>
> I propose the following artifacts for release as 3.8.
>
> sha1: c3ded0551f538f7845602b27d53240cd8129265c
> Git:
>
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.8-tentative
> Artifacts:
>
> https://repository.apache.org/content/repositories/orgapachecassandra-1123/org/apache/cassandra/apache-cassandra/3.8/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1123/
>
> The debian packages are available here: http://people.apache.org/~mshuler/
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: http://goo.gl/oGNH0i (CHANGES.txt)
> [2]: http://goo.gl/KjMtUn (NEWS.txt)
> [3]: https://goo.gl/TxVLKo (3.8 Test Summary)
>

Re: [VOTE RESULT] Release Apache Cassandra 3.8

[Pavel Yaskevich]

I concur with Sylvain.

On Wed, Jul 27, 2016 at 1:59 AM, Sylvain Lebresne 
wrote:

> On Wed, Jul 27, 2016 at 12:42 AM, Aleksey Yeschenko 
> wrote:
>
> > Sorry, but I’m counting 3 binding +1s and 1 binding -1 (2, if you
> > interpret Jonathan’s emails as such).
> >
> > Thus, if you were to do close the vote now, the vote is passing with the
> > binding majority, and the required minimum # of +1s gained.
> >
> > I also don’t see the PMC consensus on ‘August 3.8 release target’.
> >
> > As such, the vote is now reopened for further discussion, and to allow
> PMC
> > to change their votes if they feel like it (I, for one, have just
> returned,
> > and need to reevaluate 12236 in light of new comments).
> >
>
> It has been my understanding that we took a more human approach to release
> decisions than strictly and blindly adhering to the Apache written voting
> rules. There has been many votes that has been re-rolled even though they
> had had more than 3 binding vote already when a problem was detected, and
> it never took an official PMC vote to do so, nor did we ever officially
> waited on the cast votes to be officially reverted.
>
> I'm also sad that knowing that there is a bug that breaks in-flight queries
> during upgrade *and* the fact the vast majority of our upgrade tests are
> failing is not _obviously_ enough to hold a release, without the need for
> further considerations. This speaks imo poorly of the PMC attachment to
> release quality.
>
> But you are correct on the technicality of vote counting and their official
> consequences according to the written rules ...
>
>
> >
> > --
> > AY
> >
> > On 25 July 2016 at 15:46:40, Michael Shuler (mshu...@apache.org) wrote:
> >
> > Thanks for the clarity, Jonathan. I agree that an August 3.8 release
> > target sounds like the most reasonable option, at this point in time.
> >
> > With Sylvain's binding -1, this vote has failed.
> >
> > --
> > Kind regards,
> > Michael Shuler
> >
> > On 07/21/2016 05:33 PM, Jonathan Ellis wrote:
> > > I feel like the calendar is relevant though because if we delay 3.8
> more
> > > we're looking at a week, maybe 10 days before 3.9 is scheduled. Which
> > > doesn't give us much time for the stabilizing we're supposed to do in
> > 3.9.
> > >
> > > All in all I think I agree that releasing 3.8 in August is less
> confusing
> > > than skipping it entirely. And I don't like the idea of ignoring a
> whole
> > > bunch of test failures and hoping they don't mean anything, because we
> > just
> > > had that thread about getting more rigorous about tests, not less.
> > >
> > > So I would recommend we go ahead and fix this before releasing, and to
> > > avoid a super compressed 3.9 window either retarget 3.8 for August, or
> > 3.9
> > > for September.
> > >
> > > On Thu, Jul 21, 2016 at 9:58 AM, Aleksey Yeschenko  >
> > > wrote:
> > >
> > >> What we’d usually do is revert the offending ticket and push it to the
> > >> next release, if this indeed were significant enough.
> > >>
> > >> So option 4 would be to revert CDC fast (painful) and ship.
> > >> Option 5 would be to quickly fix the issue, retag, and revote, with
> 3.9
> > >> still following up on schedule.
> > >> Option 6 would be to ignore the calendar entirely. Fix or revert the
> > issue
> > >> eventually, and release 3.8 then. Have 3.9 and 3.0.9 out at whatever
> > time
> > >> we decide to, and go back to monthly cycles from there on.
> > >>
> > >> TBH I don’t think anybody is even going to notice, or care. So I’m
> fine
> > >> with 1, 4, 5, 6, but not reverting my +1 so far.
> > >>
> > >> --
> > >> AY
> > >>
> > >> On 21 July 2016 at 14:46:17, Sylvain Lebresne (sylv...@datastax.com)
> > >> wrote:
> > >>
> > >> On Thu, Jul 21, 2016 at 3:21 PM, Jonathan Ellis 
> > wrote:
> > >>
> > >>> I see the alternatives as:
> > >>>
> > >>> 1. Release this as 3.8
> > >>> 2. Skip 3.8 and release 3.9 next month on schedule
> > >>> 3. Skip this month and release 3.8 next month instead
> > >>>
> > >>
> > >> I've hopefully made it clear I don't really like 1. I'm totally fine
> > with
> > >> either 2 or 3 though (with a very very small preference for 3.
> because I
> > >> suspect skipping a release might confuse a few users, but also knowing
> > that
> > >> 2. has the small advantage of keeping the 3.0.x and 3.x versions
> > released
> > >> more or less in lockstep).
> > >>
> > >>
> > >>
> > >>>
> > >>> On Thu, Jul 21, 2016 at 8:19 AM, Aleksey Yeschenko <
> alek...@apache.org
> > >
> > >>> wrote:
> > >>>
> >  I still think the issue is minor enough, and with 3.8 being
> extremely
> >  delayed, and being a non-odd release, at that, we’d be better off
> just
> >  pushing it.
> > 
> >  Also, I know we’ve been easy on -1s when voting on releases, but I
> > want
> > >>> to
> >  remind people in general that release votes can not be vetoed and
> only
> >  require a majority of binding votes,
> >  http://www.apache.org/foundation/voting.html#ReleaseVotes
> > 
> > >>>

Re: [VOTE RESULT] Release Apache Cassandra 3.8

[Pavel Yaskevich]

I am more -0 at this point, because I think we need to get our priorities 
straight before even talking about dates and releases, that's why I wrote that 
I agree with Sylvain.

Sent from my iPhone

> On Jul 28, 2016, at 1:40 PM, Brandon Williams  wrote:
> 
> Also I believe Pavel may have switched tacitly to -1 with his "I agree with
> Sylvain" email?
> 
>> On Thu, Jul 28, 2016 at 3:08 PM, Brandon Williams  wrote:
>> 
>> I change my vote to -1.
>> 
>>> On Thu, Jul 28, 2016 at 3:04 PM, Jonathan Ellis  wrote:
>>> 
>>> On Thu, Jul 28, 2016 at 1:19 PM, Aleksey Yeschenko 
>>> wrote:
>>> 
 1. Release 3.8 as is now. It’s an even preview release that can live
>>> fine
 with one minor annoyance on upgrade. Have 3.9 released on schedule.
 Since the vote technically passed, we can just do it, now.
 
 2. Wait until #12236 is in, and release 3.8 then, doesn’t matter when.
 Have 3.9+ released on schedule. Even though the delta between 3.8 and
>>> 3.9
 would
 be tiny, it’s still IMO less confusing than skipping a whole version,
>>> and
 a lot more preferable than failing the schedule for 4 upcoming 3.x and
 3.0.x releases.
>>> 
>>> I can live with either but as a -1 voter I would prefer #2.
>>> 
>>> --
>>> Jonathan Ellis
>>> Project Chair, Apache Cassandra
>>> co-founder, http://www.datastax.com
>>> @spyced
>> 
>> 

Re: [VOTE] Accept dtests Donation Into Project

[Pavel Yaskevich]

+1

On Mon, Oct 3, 2016 at 7:54 AM, Aleksey Yeschenko 
wrote:

> +1
>
> --
> AY
>
> On 30 September 2016 at 19:51:32, Nate McCall (zzn...@apache.org) wrote:
>
> I propose we begin the process of accepting the contribution of the
> dtest codebase (https://github.com/riptano/cassandra-dtest) into the
> project.
>
> Background discussion thread here:
> https://lists.apache.org/thread.html/840fd900fb7f6568bfa008d122d437
> 5b708c1f7f1b5929018118d5d5@%3Cdev.cassandra.apache.org%3E
>
> Note: It won't be immediate as there are some steps to follow [0] for
> accepting outside code contributions.
>
> The vote will be open for 72 hours.
>
> -Nate
>
> [0] http://incubator.apache.org/ip-clearance/ip-clearance-template.html
>

Re: Proposal to retroactively mark materialized views experimental

[Pavel Yaskevich]

On Wed, Oct 4, 2017 at 12:09 PM, Jon Haddad  wrote:

> MVs work fine for *some use cases*, not the general use case.  That’s why
> there should be a flag.  To opt into the feature when the behavior is only
> known to be correct under a certain set of circumstances.  Nobody is saying
> the flag should be “enable_terrible_feature_nobody_tested_and_we_all_hate”,
> or something ridiculous like that.  It’s not an attack against the work
> done by anyone, the level of effort put in, or minimizing the complexity of
> the problem.  “enable_materialized_views” would be just fine.
>
> We should be honest to people about what they’re getting into.  You may
> not be aware of this, but a lot of people still believe Cassandra isn’t a
> DB that you should put in prod.  It’s because features like SASI, MVs,  or
> incremental repair get merged in prematurely (or even made the default),
> without having been thoroughly tested, understood and vetted by trusted
> community members.  New users hit the snags because they deploy the
> bleeding edge code and hit the bugs.
>

I beg to differ in case of SASI, it has been tested and vetted and ported
to different versions. I'm pretty sure it still has better test coverage
then most of the project does, it's not a "default" and you actually have
to opt-in to it by creating a custom index, how is that premature or
misleading to users?


>
> That’s not how the process should work.
>
> Ideally, we’d follow a process that looks a lot more like this:
>
> 1. New feature is built with an opt in flag.  Unknowns are documented, the
> risk of using the feature is known to the end user.
> 2. People test and use the feature that know what they’re doing.  They are
> able to read the code, submit patches, and help flush out the issues.  They
> do so in low risk environments.  In the case of MVs, they can afford to
> drop and rebuild the view over a week, or rebuild the cluster altogether.
> We may not even need to worry as much about backwards compatibility.
> 3. The feature matures.  More tests are written.  More people become aware
> of how to contribute to the feature’s stability.
> 4. After a while, we vote on removing the feature flag and declare it
> stable for general usage.
>
> If nobody actually cares about a feature (why it was it written in the
> first place?), then it would never get to 2, 3, 4.  It would take a while
> for big features like MVs to be marked stable, and that’s fine, because it
> takes a long time to actually stabilize them.  I think we can all agree
> they are really, really hard problems to solve, and maybe it takes a while.
>
> Jon
>
>
>
> > On Oct 4, 2017, at 11:44 AM, Josh McKenzie  wrote:
> >
> >>
> >> So you’d rather continue to lie to users about the stability of the
> >> feature rather than admitting it was merged in prematurely?
> >
> >
> > Much like w/SASI, this is something that's in the code-base that for
> >> certain use-cases apparently works just fine.
> >
> > I don't know of any outstanding issues with the feature,
> >
> > There appear to be varying levels of understanding of the implementation
> >> details of MV's (that seem to directly correlate with faith in the
> >> feature's correctness for the use-cases recommended)
> >
> > We have users in the wild relying on MV's with apparent success (same
> holds
> >> true of all the other punching bags that have come up in this thread)
> >
> > You're right, Jon. That's clearly exactly what I'm saying.
> >
> >
> > On Wed, Oct 4, 2017 at 2:39 PM, Jon Haddad  wrote:
> >
> >> So you’d rather continue to lie to users about the stability of the
> >> feature rather than admitting it was merged in prematurely?  I’d rather
> >> come clean and avoid future problems, and give people the opportunity to
> >> stop using MVs rather than let them keep taking risks they’re unaware
> of.
> >> This is incredibly irresponsible in my opinion.
> >>
> >>> On Oct 4, 2017, at 11:26 AM, Josh McKenzie 
> wrote:
> >>>
> 
>  Oh, come on. You're being disingenuous.
> >>>
> >>> Not my intent. MV's (and SASI, for example) are fairly well isolated;
> we
> >>> have a history of other changes that are much more broadly and higher
> >>> impact risk-wise across the code-base.
> >>>
> >>> If I were an operator and built a critical part of my business on a
> >>> released feature that developers then decided to default-disable as
> >>> 'experimental' post-hoc, I'd think long and hard about using any new
> >>> features in that project in the future (and revisit my confidence in
> all
> >>> other features I relied on, and the software as a whole). We have users
> >> in
> >>> the wild relying on MV's with apparent success (same holds true of all
> >> the
> >>> other punching bags that have come up in this thread) and I'd hate to
> see
> >>> us alienate them by being over-aggressive in the way we handle this.
> >>>
> >>> I'd much rather we continue to aggressively improve and continue to
> >> analyze
> >>> MV's stability before a 4.0 release an

Re: Proposal to retroactively mark materialized views experimental

[Pavel Yaskevich]

On Wed, Oct 4, 2017 at 12:23 PM, Jon Haddad  wrote:

> The default part I was referring to incremental repair.
>
> SASI still has a pretty fatal issue where nodes OOM:
> https://issues.apache.org/jira/browse/CASSANDRA-12662 <
> https://issues.apache.org/jira/browse/CASSANDRA-12662>
>

If you read the comments in the issue originator of the problem states
that "Cassandra fairly quickly crashes with OOM, a glance over hprof shows
4Gb of PartitionUpdates." which to me doesn't seem like it's a SASI issue
but more of the issue of underlaying storage which SASI uses.



>
>
> > On Oct 4, 2017, at 12:21 PM, Pavel Yaskevich  wrote:
> >
> > On Wed, Oct 4, 2017 at 12:09 PM, Jon Haddad  j...@jonhaddad.com>> wrote:
> >
> >> MVs work fine for *some use cases*, not the general use case.  That’s
> why
> >> there should be a flag.  To opt into the feature when the behavior is
> only
> >> known to be correct under a certain set of circumstances.  Nobody is
> saying
> >> the flag should be “enable_terrible_feature_
> nobody_tested_and_we_all_hate”,
> >> or something ridiculous like that.  It’s not an attack against the work
> >> done by anyone, the level of effort put in, or minimizing the
> complexity of
> >> the problem.  “enable_materialized_views” would be just fine.
> >>
> >> We should be honest to people about what they’re getting into.  You may
> >> not be aware of this, but a lot of people still believe Cassandra isn’t
> a
> >> DB that you should put in prod.  It’s because features like SASI, MVs,
> or
> >> incremental repair get merged in prematurely (or even made the default),
> >> without having been thoroughly tested, understood and vetted by trusted
> >> community members.  New users hit the snags because they deploy the
> >> bleeding edge code and hit the bugs.
> >>
> >
> > I beg to differ in case of SASI, it has been tested and vetted and ported
> > to different versions. I'm pretty sure it still has better test coverage
> > then most of the project does, it's not a "default" and you actually have
> > to opt-in to it by creating a custom index, how is that premature or
> > misleading to users?
> >
> >
> >>
> >> That’s not how the process should work.
> >>
> >> Ideally, we’d follow a process that looks a lot more like this:
> >>
> >> 1. New feature is built with an opt in flag.  Unknowns are documented,
> the
> >> risk of using the feature is known to the end user.
> >> 2. People test and use the feature that know what they’re doing.  They
> are
> >> able to read the code, submit patches, and help flush out the issues.
> They
> >> do so in low risk environments.  In the case of MVs, they can afford to
> >> drop and rebuild the view over a week, or rebuild the cluster
> altogether.
> >> We may not even need to worry as much about backwards compatibility.
> >> 3. The feature matures.  More tests are written.  More people become
> aware
> >> of how to contribute to the feature’s stability.
> >> 4. After a while, we vote on removing the feature flag and declare it
> >> stable for general usage.
> >>
> >> If nobody actually cares about a feature (why it was it written in the
> >> first place?), then it would never get to 2, 3, 4.  It would take a
> while
> >> for big features like MVs to be marked stable, and that’s fine, because
> it
> >> takes a long time to actually stabilize them.  I think we can all agree
> >> they are really, really hard problems to solve, and maybe it takes a
> while.
> >>
> >> Jon
> >>
> >>
> >>
> >>> On Oct 4, 2017, at 11:44 AM, Josh McKenzie 
> wrote:
> >>>
> >>>>
> >>>> So you’d rather continue to lie to users about the stability of the
> >>>> feature rather than admitting it was merged in prematurely?
> >>>
> >>>
> >>> Much like w/SASI, this is something that's in the code-base that for
> >>>> certain use-cases apparently works just fine.
> >>>
> >>> I don't know of any outstanding issues with the feature,
> >>>
> >>> There appear to be varying levels of understanding of the
> implementation
> >>>> details of MV's (that seem to directly correlate with faith in the
> >>>> feature's correctness for the use-cases recommended)
> >>>
> >>> We have users in the wild relying on 

Re: [VOTE] Release Apache Cassandra 1.1.2

[Pavel Yaskevich]

+1

29 jun 2012 kl. 19:28 skrev Jonathan Ellis :

> +1
>
> On Fri, Jun 29, 2012 at 11:20 AM, Sylvain Lebresne  
> wrote:
>> We've fixed a fair amount of issues so I believe it is time for a new release
>> and thus propose the following artifacts for release as 1.1.2.
>>
>> sha1: b94d8d40fb6f84b4041857bf69ddf7cd22df2e86
>> Git: 
>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.1.2-tentative
>> Artifacts: 
>> https://repository.apache.org/content/repositories/orgapachecassandra-289/org/apache/cassandra/apache-cassandra/1.1.2/
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapachecassandra-289/
>>
>> 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/3AlMf (CHANGES.txt)
>> [2]: http://goo.gl/aXvOy (NEWS.txt)
>
>
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder of DataStax, the source for professional Cassandra support
> http://www.datastax.com

Re: Cassandra not applying keyspace updates

[Pavel Yaskevich]

Hi Michael, 

   Thanks for you investigation, I have created 
https://issues.apache.org/jira/browse/CASSANDRA-4432 to cover related changes 
and going to start with that ASAP. 

Best Regards
-- 
Pavel Yaskevich


On Tuesday 10 July 2012 at 19:36, Michael Theroux wrote:

> Hello,
> 
> We are in the process of upgrading out cassandra installation from a single 
> instance to a 6 node cluster with a replication factor of 3. We are using 
> Cassandra 1.1.2. This is something I've done before in other environments, 
> but now I've hit an interesting issue. The cluster has been setup and all the 
> nodes have joined. I was about to update the replication factor to 3 via 
> cassandra-cli:
> 
> [open@unknown] use open; 
> Authenticated to keyspace: open
> 
> [default@open] update keyspace open with 
> placement_strategy='org.apache.cassandra.locator.NetworkTopologyStrategy' and 
> strategy_options={us-east:3};
> 4698e471-5a1d-30f2-aa11-761d204581ff
> Waiting for schema agreement...
> ... schemas agree across the cluster
> 
> The above looks normal, but when I look at the schema, the replication factor 
> is unchanged:
> 
> [default@open] describe open; 
> Keyspace: open: 
> Replication Strategy: org.apache.cassandra.locator.NetworkTopologyStrategy
> Durable Writes: true
> Options: [us-east:1]
> Column Families:
> ...
> 
> I couldn't figure out why this was, but then I saw this thread:
> 
> http://www.datastax.com/support-forums/topic/cassandra-111-update-keyspace-not-working
> 
> So I tried creating a new keyspace "ks" and looked at the results:
> 
> [default@open] use system;
> Authenticated to keyspace: system
> [default@system] list schema_keyspace;
> schema_keyspace not found in current keyspace.
> [default@system] list schema_keyspaces;
> Using default limit of 100
> Using default column limit of 100
> ---
> RowKey: open
> => (column=durable_writes, value=true, timestamp=530617107329814)
> => (column=name, value=open, timestamp=530617107329814)
> => (column=strategy_class, 
> value=org.apache.cassandra.locator.NetworkTopologyStrategy, 
> timestamp=530617107329814)
> => (column=strategy_options, value={"us-east":"1"}, timestamp=530617107329814)
> ---
> RowKey: ks
> => (column=durable_writes, value=true, timestamp=42396175198913)
> => (column=name, value=ky, timestamp=42396175198913)
> => (column=strategy_class, 
> value=org.apache.cassandra.locator.NetworkTopologyStrategy, 
> timestamp=42396175198913)
> => (column=strategy_options, value={"datacenter1":"1"}, 
> timestamp=42396175198913)
> 
> 
> Notice the "timestamp" on the new keyspace is MUCH younger than "open" (by 
> more than a factor of 10). 
> 
> I didn't understand how this could be, as time has always been in sync. 
> 
> I decided to look at the code to see if I could spot anything. When 
> cassandra-cli attempts to create a new keyspace, it uses thrift, and ends up 
> here (in CassandraServer.java):
> 
> public String system_update_keyspace(KsDef ks_def)
> throws InvalidRequestException, SchemaDisagreementException, TException
> {
> logger.debug("update_keyspace");
> ThriftValidation.validateKeyspaceNotSystem(ks_def.name (http://ks_def.name));
> ...
> MigrationManager.announceKeyspaceUpdate(KSMetaData.fromThrift(ks_def));
> return Schema.instance.getVersion().toString();
> ...
> }
> 
> 
> Which then calls:
> 
> public static void announceKeyspaceUpdate(KSMetaData ksm) throws 
> ConfigurationException
> {
> ksm.validate();
> 
> KSMetaData oldKsm = Schema.instance.getKSMetaData(ksm.name (http://ksm.name));
> if (oldKsm == null)
> throw new ConfigurationException(String.format("Cannot update non existing 
> keyspace '%s'.", ksm.name (http://ksm.name)));
> 
> announce(oldKsm.toSchemaUpdate(ksm, System.nanoTime()));
> }
> 
> It then uses the results of System.nanoTime in the timestamp.
> 
> I wrote a simple java program to output System.nanoTime on the system in 
> which I attempted to add the new keyspace, and the output was:
> 
> 46627528340034
> 
> Which is in the realm of the keyspace I added above. System.nanoTime() is 
> java instance dependent (nanoTime). You will get different values depending 
> on what machine you run on and is not necessarily associated with you system 
> clock. I ran this on several different machines, all verified to be in sync 
> with NTP, and got massively different results. In fact, when I stopped and 
> started my instance, my nanoTime became:
> 
> 97234377869
> 
> I then create

Re: Cassandra not applying keyspace updates

[Pavel Yaskevich]

Update: I have posted a patch that would change nanoTime() to 
currentTimeInMillis() that actually uses the system timer to CASSANDRA-4432, 
you can try to apply and test if you would like, Michael.

On Tuesday 10 July 2012 at 19:53, Pavel Yaskevich wrote:

> Hi Michael, 
> 
>Thanks for you investigation, I have created 
> https://issues.apache.org/jira/browse/CASSANDRA-4432 to cover related changes 
> and going to start with that ASAP. 
> 
> Best Regards
> -- 
> Pavel Yaskevich
> 
> 
> On Tuesday 10 July 2012 at 19:36, Michael Theroux wrote:
> 
> > Hello,
> > 
> > We are in the process of upgrading out cassandra installation from a single 
> > instance to a 6 node cluster with a replication factor of 3. We are using 
> > Cassandra 1.1.2. This is something I've done before in other environments, 
> > but now I've hit an interesting issue. The cluster has been setup and all 
> > the nodes have joined. I was about to update the replication factor to 3 
> > via cassandra-cli:
> > 
> > [open@unknown] use open; 
> > Authenticated to keyspace: open
> > 
> > [default@open] update keyspace open with 
> > placement_strategy='org.apache.cassandra.locator.NetworkTopologyStrategy' 
> > and strategy_options={us-east:3};
> > 4698e471-5a1d-30f2-aa11-761d204581ff
> > Waiting for schema agreement...
> > ... schemas agree across the cluster
> > 
> > The above looks normal, but when I look at the schema, the replication 
> > factor is unchanged:
> > 
> > [default@open] describe open; 
> > Keyspace: open: 
> > Replication Strategy: org.apache.cassandra.locator.NetworkTopologyStrategy
> > Durable Writes: true
> > Options: [us-east:1]
> > Column Families:
> > ...
> > 
> > I couldn't figure out why this was, but then I saw this thread:
> > 
> > http://www.datastax.com/support-forums/topic/cassandra-111-update-keyspace-not-working
> > 
> > So I tried creating a new keyspace "ks" and looked at the results:
> > 
> > [default@open] use system;
> > Authenticated to keyspace: system
> > [default@system] list schema_keyspace;
> > schema_keyspace not found in current keyspace.
> > [default@system] list schema_keyspaces;
> > Using default limit of 100
> > Using default column limit of 100
> > ---
> > RowKey: open
> > => (column=durable_writes, value=true, timestamp=530617107329814)
> > => (column=name, value=open, timestamp=530617107329814)
> > => (column=strategy_class, 
> > value=org.apache.cassandra.locator.NetworkTopologyStrategy, 
> > timestamp=530617107329814)
> > => (column=strategy_options, value={"us-east":"1"}, 
> > timestamp=530617107329814)
> > ---
> > RowKey: ks
> > => (column=durable_writes, value=true, timestamp=42396175198913)
> > => (column=name, value=ky, timestamp=42396175198913)
> > => (column=strategy_class, 
> > value=org.apache.cassandra.locator.NetworkTopologyStrategy, 
> > timestamp=42396175198913)
> > => (column=strategy_options, value={"datacenter1":"1"}, 
> > timestamp=42396175198913)
> > 
> > 
> > Notice the "timestamp" on the new keyspace is MUCH younger than "open" (by 
> > more than a factor of 10). 
> > 
> > I didn't understand how this could be, as time has always been in sync. 
> > 
> > I decided to look at the code to see if I could spot anything. When 
> > cassandra-cli attempts to create a new keyspace, it uses thrift, and ends 
> > up here (in CassandraServer.java):
> > 
> > public String system_update_keyspace(KsDef ks_def)
> > throws InvalidRequestException, SchemaDisagreementException, TException
> > {
> > logger.debug("update_keyspace");
> > ThriftValidation.validateKeyspaceNotSystem(ks_def.name 
> > (http://ks_def.name));
> > ...
> > MigrationManager.announceKeyspaceUpdate(KSMetaData.fromThrift(ks_def));
> > return Schema.instance.getVersion().toString();
> > ...
> > }
> > 
> > 
> > Which then calls:
> > 
> > public static void announceKeyspaceUpdate(KSMetaData ksm) throws 
> > ConfigurationException
> > {
> > ksm.validate();
> > 
> > KSMetaData oldKsm = Schema.instance.getKSMetaData(ksm.name 
> > (http://ksm.name));
> > if (oldKsm == null)
> > throw new ConfigurationException(String.format("Cannot update non existing 
> > keyspace '%s'.", ksm.name (http://ksm.name)));
> > 
> > annou

Re: [VOTE] Release Apache Cassandra 1.0.11

[Pavel Yaskevich]

+1

On Friday 27 July 2012 at 19:38, Sylvain Lebresne wrote:

> The 1.0 branch is fairly stable now but we still have fixed a few bugs since
> 1.0.10 so I propose the following artifacts for release as 1.0.11.
> 
> sha1: 4f0237acd5ee8097f90732ac416622588e4d7552
> Git: 
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.0.11-tentative
> Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-036/org/apache/cassandra/apache-cassandra/1.0.11/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-093/
> 
> 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/E5dpS (CHANGES.txt)
> [2]: http://goo.gl/OTL6t (NEWS.txt)
> 
> 

Re: [VOTE] Release Apache Cassandra 1.1.3

[Pavel Yaskevich]

+1

On Tuesday 31 July 2012 at 13:23, Sylvain Lebresne wrote:

> Some fair amount of bug have been fixed since 1.1.2, including a few important
> ones, so I propose the following artifacts for release as 1.1.3.
> 
> sha1: 2714056562a4435da48f5a12db18c60ea6551f41
> Git: 
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.1.3-tentative
> Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-101/org/apache/cassandra/apache-cassandra/1.1.3/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-101/
> 
> 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/wq0VC (CHANGES.txt)
> [2]: http://goo.gl/AnCo8 (NEWS.txt)
> 
> 

Re: [VOTE] Release Apache Cassandra 1.1.3 (Strike 3)

[Pavel Yaskevich]

+1

On Friday 3 August 2012 at 20:20, Brandon Williams wrote:

> +1
> 
> On Thu, Aug 2, 2012 at 1:43 AM, Sylvain Lebresne  (mailto:sylv...@datastax.com)> wrote:
> > Hopefully for the last time I propose the following artifacts for
> > release as 1.1.3.
> > 
> > sha1: 94bcc6a6f6171796e3147dec73d71df05c370f94
> > Git: 
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.1.3-tentative
> > Artifacts: 
> > https://repository.apache.org/content/repositories/orgapachecassandra-111/org/apache/cassandra/apache-cassandra/1.1.3/
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachecassandra-111/
> > 
> > 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/wq0VC (CHANGES.txt)
> > [2]: http://goo.gl/AnCo8 (NEWS.txt)
> > 
> 
> 
> 

Re: [VOTE] Release Apache Cassandra 1.1.4 (take #2)

[Pavel Yaskevich]

+1

On Wednesday 15 August 2012 at 00:34, Eric Evans wrote:

> I knew I'd mess up something; So here we go again, this time built
> with the right version of JDK.
> 
> SHA1: 8b1336f
> Git: 
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.1.4-tentative
> Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-003/org/apache/cassandra/apache-cassandra/1.1.4
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-003
> 
> The artifacts as well as the debian package are also available here:
> http://people.apache.org/~eevans
> 
> The vote will be open for 72 hours (longer if needed).
> 
> [1]: http://goo.gl/Iu7W3 (CHANGES.txt)
> [2]: http://goo.gl/yi8Iu (NEWS.txt)
> 
> -- 
> Eric Evans
> Acunu | http://www.acunu.com | @acunu
> 
> 

Re: [VOTE] Release Apache Cassandra 1.1.5 (strike 2)

[Pavel Yaskevich]

+1 

On Friday 7 September 2012 at 20:37, Sylvain Lebresne wrote:

> The fix to #4561 have now been pushed and we even have a few more fixes
> committed since the first try and so let's try again: I propose the following
> artifacts for release as 1.1.5.
> 
> sha1: e395307893d93a01e976656f6e0f5cee1acf3c3b
> Git: 
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.1.5-tentative
> Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-041/org/apache/cassandra/apache-cassandra/1.1.5/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-041/
> 
> 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/FHCUz (CHANGES.txt)
> [2]: http://goo.gl/Mw0HH (NEWS.txt)
> 
> 

Re: [VOTE] Release Apache Cassandra 1.2.0-beta1

[Pavel Yaskevich]

+1

On Friday 21 September 2012 at 22:49, Eric Evans wrote:

> On Tue, Sep 18, 2012 at 11:55 AM, Sylvain Lebresne  (mailto:sylv...@datastax.com)> wrote:
> > sha1: 60bf68caa98566ce09e76d501b14d45b46c26209
> > Git: 
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.2.0-beta1-tentative
> > Artifacts: 
> > https://repository.apache.org/content/repositories/orgapachecassandra-016/org/apache/cassandra/apache-cassandra/1.2.0-beta1/
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachecassandra-016/
> > 
> > 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
> 
> -- 
> Eric Evans
> Acunu | http://www.acunu.com | @acunu
> 
> 

Re: [VOTE] Release Apache Cassandra 1.0.12

[Pavel Yaskevich]

+1

On Tuesday 25 September 2012 at 01:10, Jonathan Ellis wrote:

> +1
> 
> On Mon, Sep 24, 2012 at 4:52 PM, Sylvain Lebresne  (mailto:sylv...@datastax.com)> wrote:
> > We've just fixed CASSANDRA-4708 and have a few other minor fixes on the 1.0
> > branch since 1.0.11 so I propose the following artifacts for release as 
> > 1.0.12.
> > 
> > sha1: 373e5b0d5104f17fca77edafbc033da99bced64c
> > Git: 
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.0.12-tentative
> > Artifacts: 
> > https://repository.apache.org/content/repositories/orgapachecassandra-035/org/apache/cassandra/apache-cassandra/1.0.12/
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachecassandra-035/
> > 
> > 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/RRacv (CHANGES.txt)
> > [2]: http://goo.gl/mJf2H (NEWS.txt)
> > 
> 
> 
> 
> 
> -- 
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder of DataStax, the source for professional Cassandra support
> http://www.datastax.com
> 
> 

Re: Pushing Cassandra 1.2 back a month to November?

[Pavel Yaskevich]

+1

26 sep 2012 kl. 15:56 skrev Sylvain Lebresne :

> +1
>
> On Tue, Sep 25, 2012 at 7:16 PM, Jonathan Ellis  wrote:
>> We are more or less on track for the promised late October 1.2 release
>> [1] but I'm starting to think we should expand the scope of 1.2 a bit
>> to get cql3 and the corresponding binary protocol truly "right."
>>
>> Specifically,
>> 1) We'd like to move the consistency level setting from the CQL
>> language to the protocol level.
>> 2) The binary protocol only really has a Java implementation so far.
>> Having the time to flesh out the Python implementation would be a good
>> sanity check before we commit to protocol stability.
>>
>> Additionally,
>> 3) vnodes is a big change that could use more time to test.  I'd like
>> to avoid a repeat of the schema change mess from 1.1, where we did a
>> substantial rewrite that took six minor releases to get all the bugs
>> out of.
>>
>> Gory details on the CQL situation:
>>
>> Currently, in CQL3, you set the consistency level of an operation in
>> the language, eg 'SELECT * FROM foo USING CONSISTENCY QUORUM'.  It now
>> looks like this was a mistake, and that consistency should be set at
>> the protocol level, i.e. as a separate parameter along with the query.
>>
>> The reasoning is that the CL applies to the guarantee provided by the
>> operation being successful, not to the query itself.  Specifically,
>> having the CL being part of the language means that CL is opaque to
>> low level client libraries without themselves parsing the CQL, which
>> we want to avoid.  Thus,
>>
>>- Those libraries can't implement automatic retries policy, where a query
>>  would be retried with a smaller CL.  (I'm aware that this is often a
>>  Bad Idea, but it does have legitimate uses and not having that available
>>  is seen as a regression from the Thrift api.)
>>- We had to introduce CASSANDRA-4448 to allow the client to configure some
>>  form of default CL since the library can't handle that anymore, which is
>>  hackish.
>>- Executing prepared statements with different CL requires preparing
>>  multiple statements.
>>- CL only makes sense for BATCH operations as a whole, not the
>>  sub-statements within the batch. Currently CQL3 "fixes" that by
>>  validating the given CLs match, but it would be much more clear
>>  if the CL was on the protocol side.
>>
>> Moving the CL to the protocol level solves all of that but the problem
>> is, if we move the CL from the language to the protocol after 1.2,
>> that's a breaking change of CQL3, so we're talking CQL4.  Bad idea.
>>
>> [1] although later-than-planned freeze is a warning sign
>>
>> --
>> Jonathan Ellis
>> Project Chair, Apache Cassandra
>> co-founder of DataStax, the source for professional Cassandra support
>> http://www.datastax.com

Re: [VOTE] Release Apache Cassandra 1.1.6 (strike 2)

[Pavel Yaskevich]

+1

On Friday, October 12, 2012 at 7:33 AM, Jonathan Ellis wrote:

> +1
> 
> On Fri, Oct 12, 2012 at 9:17 AM, Sylvain Lebresne  (mailto:sylv...@datastax.com)> wrote:
> > Ladies and gentlemen, with now added fix for leveled compaction and for
> > CASSANDRA-4782, I propose the following artifacts for release as
> > 1.1.6
> > 
> > sha1: a0900f3d3b9fadc3608bc6c4960ed1858d581e13
> > Git: 
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.1.6-tentative
> > Artifacts: 
> > https://repository.apache.org/content/repositories/orgapachecassandra-124/org/apache/cassandra/apache-cassandra/1.1.6/
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachecassandra-124/
> > 
> > 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/MYRFT (CHANGES.txt)
> > [2]: http://goo.gl/I9xPL (NEWS.txt)
> > 
> 
> 
> 
> 
> -- 
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder of DataStax, the source for professional Cassandra support
> http://www.datastax.com
> 
> 

Re: [VOTE] Release Apache Cassandra 1.2.0-beta2

[Pavel Yaskevich]

+1

On Wednesday, November 7, 2012 at 9:15 AM, Brandon Williams wrote:

> +1
> 
> On Mon, Nov 5, 2012 at 1:08 PM, Sylvain Lebresne  (mailto:sylv...@datastax.com)> wrote:
> > Lots have happened since beta1 and it's time to think seriously about the
> > 1.2.0
> > release, so I propose the following artifacts for release as
> > 1.2.0-beta2.
> > 
> > sha1: f04bebfa7e5fb0efd003685b10c0e31250de441d
> > Git:
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.2.0-beta2-tentative
> > Artifacts:
> > https://repository.apache.org/content/repositories/orgapachecassandra-014/org/apache/cassandra/apache-cassandra/1.2.0-beta2/
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachecassandra-014/
> > 
> > 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/UBWTe (CHANGES.txt)
> > [2]: http://goo.gl/DqyxT (NEWS.txt)
> > 
> 
> 
> 

Re: [VOTE] Release Apache Cassandra 1.1.7

[Pavel Yaskevich]

+1

On Tuesday, November 27, 2012 at 5:20 AM, Gary Dusbabek wrote:

> +1
> 
> 
> On Tue, Nov 27, 2012 at 3:29 AM, Sylvain Lebresne  (mailto:sylv...@datastax.com)>wrote:
> 
> > A fair amount of fixes went in since 1.1.6, so I propose the following
> > artifacts for release as 1.1.7.
> > 
> > sha1: 2f4b6d8c61d81ac4c878a4399a3634221deeb075
> > Git:
> > 
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.1.7-tentative
> > Artifacts:
> > 
> > https://repository.apache.org/content/repositories/orgapachecassandra-082/org/apache/cassandra/apache-cassandra/1.1.7/
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachecassandra-082/
> > 
> > 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/tYcFp (CHANGES.txt)
> > [2]: http://goo.gl/dllaz (NEWS.txt)
> > 
> 
> 
> 

Re: [VOTE] Release Apache Cassandra 1.2.0-rc1

[Pavel Yaskevich]

+1

On Tuesday, December 11, 2012 at 8:28 AM, Yuki Morishita wrote:

> +1 
> 
> yuki
> 
> 
> On Tuesday, December 11, 2012 at 7:27 AM, Jonathan Ellis wrote:
> 
> > +1
> > On Dec 11, 2012 5:19 AM, "Sylvain Lebresne"  > (mailto:sylv...@datastax.com)> wrote:
> > 
> > > We've now fixed all remaining blocking problems on the 1.2.0 branch since
> > > beta3, and if we want to release the final before the end of the year it's
> > > time
> > > to get serious, so I propose the following artifacts for release as
> > > 1.2.0-rc1.
> > > 
> > > sha1: d791e0b3fa5a615f2df200ecd40f82dc9a5874d6
> > > Git:
> > > 
> > > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.2.0-rc1-tentative
> > > Artifacts:
> > > 
> > > https://repository.apache.org/content/repositories/orgapachecassandra-136/org/apache/cassandra/apache-cassandra/1.2.0-rc1/
> > > Staging repository:
> > > https://repository.apache.org/content/repositories/orgapachecassandra-136/
> > > 
> > > 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/8RW6q (CHANGES.txt)
> > > [2]: http://goo.gl/ltVIw (NEWS.txt)
> > > 
> > 
> > 
> 
> 
> 

Re: A quick newbie disaster question: Where do I find cfIDs?

[Pavel Yaskevich]

Hi Michal,  

   Those ids are stored in system.schema_columnfamilies as part of each column 
family metadata. Have you tried deleting SSTable files from 
 I have this problem (like here
> http://www.datastax.com/support-forums/topic/cassandra-does-not-startup)
> with duplicated cfIDs in the infromation schema, my whole cluster is
> currently down.
> I am trying to figure out where those cfIDs stored.
> I've manage to hack sstable2json not to throw same exception about
> duplicates but cannot find specific CFID which is duplicated.
> I am looking at schema_columnfamilies and schema_keyspaces and its not
> there...
>  
> Any ideas would be appreciated...  

Re: [VOTE] Release Apache Cassandra 1.2.0

[Pavel Yaskevich]

+1

On Saturday, December 29, 2012 at 2:14 PM, Yuki Morishita wrote:

> +1
> 
> On Saturday, December 29, 2012, Jason Brown wrote:
> 
> > +1
> > On Dec 29, 2012 9:31 AM, "Vijay"  > (mailto:vijay2...@gmail.com) >
> > wrote:
> > 
> > > +1
> > > 
> > > Regards,
> > > 
> > > 
> > > 
> > > On Sat, Dec 29, 2012 at 4:40 AM, Sylvain Lebresne  > > (mailto:sylv...@datastax.com)
> > > > wrote:
> > > 
> > > 
> > > > After a quiet 2nd release candidate, it is time to release the final
> > > 1.2.0.
> > > > I thus propose the following artifacts for release as 1.2.0.
> > > > 
> > > > sha1: 69337a43670f71ae1fc55e23d6a9031230423900
> > > > Git:
> > > > 
> > > 
> > > 
> > 
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.2.0-tentative
> > > > Artifacts:
> > > 
> > 
> > https://repository.apache.org/content/repositories/orgapachecassandra-081/org/apache/cassandra/apache-cassandra/1.2.0/
> > > > Staging repository:
> > > 
> > 
> > https://repository.apache.org/content/repositories/orgapachecassandra-081/
> > > > 
> > > > 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/zLqf9 (CHANGES.txt)
> > > > [2]: http://goo.gl/aKgkY (NEWS.txt)
> > > > 
> > > 
> > 
> > 
> 
> 
> 
> -- 
> Yuki Morishita
> t:yukim (http://twitter.com/yukim)
> 
> 

Re: [VOTE] Release Apache Cassandra 1.2.1

[Pavel Yaskevich]

+1 

-- 
Pavel Yaskevich


On Friday, January 25, 2013 at 9:19 AM, Brandon Williams wrote:

> +1
> 
> On Fri, Jan 25, 2013 at 1:53 AM, Sylvain Lebresne  (mailto:sylv...@datastax.com)> wrote:
> > That list of changes since 1.2.0 is getting pretty long, time to ship that
> > to
> > users. I propose the following artifacts for release as 1.2.1.
> > 
> > sha1: 8540974dbd26989b1cd72608b06e57ebe053bf38
> > Git:
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.2.1-tentative
> > Artifacts:
> > https://repository.apache.org/content/repositories/orgapachecassandra-173/org/apache/cassandra/apache-cassandra/1.2.1/
> > 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/T0cLq (CHANGES.txt)
> > [2]: http://goo.gl/3Gud1 (NEWS.txt)
> > 
> 
> 
> 

Re: Proposal: require Java7 for Cassandra 2.0

[Pavel Yaskevich]

+1 

-- 
Pavel Yaskevich


On Wednesday, February 6, 2013 at 2:21 PM, Jonathan Ellis wrote:

> Java 6 EOL is this month. Java 7 will be two years old when C* 2.0
> comes out (July). Anecdotally, a bunch of people are running C* on
> Java7 with no issues, except for the Snappy-on-OS-X problem (which
> will be moot if LZ4 becomes our default, as looks likely).
> 
> Upgrading to Java7 lets us take advantage of new (two year old)
> features as well as simplifying interoperability with other
> dependencies, e.g., Jetty's BlockingArrayQueue requires java7.
> 
> Thoughts?
> 
> -- 
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
> 
> 

Re: [VOTE] Release Apache Cassandra 1.1.10

[Pavel Yaskevich]

+1 

-- 
Pavel Yaskevich


On Tuesday, February 12, 2013 at 12:59 PM, Jason Brown wrote:

> +1
> 
> 
> On Tue, Feb 12, 2013 at 11:09 AM, Eric Evans  (mailto:eev...@acunu.com)> wrote:
> 
> > +1
> > 
> > On Tue, Feb 12, 2013 at 9:59 AM, Sylvain Lebresne  > (mailto:sylv...@datastax.com)>
> > wrote:
> > > We've fixed our share of bugs since 1.1.9 so I propose the following
> > > artifacts
> > > for release as 1.1.10.
> > > 
> > > sha1: 684994215120b2bac4e04f520420e105e21d07c9
> > > Git:
> > > 
> > 
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.1.10-tentative
> > > Artifacts:
> > 
> > https://repository.apache.org/content/repositories/orgapachecassandra-226/org/apache/cassandra/apache-cassandra/1.1.10/
> > > Staging repository:
> > 
> > https://repository.apache.org/content/repositories/orgapachecassandra-226/
> > > 
> > > 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/dwPLz (CHANGES.txt)
> > > [2]: http://goo.gl/reKh5 (NEWS.txt)
> > > 
> > 
> > 
> > 
> > 
> > --
> > Eric Evans
> > Acunu | http://www.acunu.com | @acunu
> > 
> 
> 
> 

Re: [VOTE] Release Apache Cassandra 1.2.3

[Pavel Yaskevich]

+1 

-- 
Pavel Yaskevich


On Thursday, March 14, 2013 at 1:28 PM, Brandon Williams wrote:

> +1
> 
> On Thu, Mar 14, 2013 at 5:04 AM, Sylvain Lebresne  (mailto:sylv...@datastax.com)> wrote:
> > Some important bug fixed since 1.2.2, I propose the following artifacts for
> > release as 1.2.3.
> > 
> > sha1: f07804e0d0cf57bc6e1e2924a7b926d55408f640
> > Git:
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.2.3-tentative
> > Artifacts:
> > https://repository.apache.org/content/repositories/orgapachecassandra-002/org/apache/cassandra/apache-cassandra/1.2.3/
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachecassandra-002/
> > 
> > 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/6udxR (CHANGES.txt)
> > [2]: http://goo.gl/EAaJr (NEWS.txt)
> > 
> 
> 
> 

Re: [VOTE] Release Apache Cassandra 1.2.4

[Pavel Yaskevich]

+1

On Monday, April 8, 2013 at 1:31 PM, Gary Dusbabek wrote:

> +1
> 
> 
> On Mon, Apr 8, 2013 at 12:54 PM, Sylvain Lebresne  (mailto:sylv...@datastax.com)>wrote:
> 
> > A fair enough number of bugs fixed since 1.2.3, I propose the following
> > artifacts for release as 1.2.4.
> > 
> > sha1: 2e96d07114dc88f85e56d88f7322a6b91da36c0d
> > Git:
> > 
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.2.4-tentative
> > Artifacts:
> > 
> > https://repository.apache.org/content/repositories/orgapachecassandra-079/org/apache/cassandra/apache-cassandra/1.2.4/
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachecassandra-079/
> > 
> > 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/TL6WO (CHANGES.txt)
> > [2]: http://goo.gl/ODV43 (NEWS.txt)
> > 
> 
> 
> 

Re: [VOTE] Release Apache Cassandra 1.1.11

[Pavel Yaskevich]

+1

On Wednesday, April 17, 2013 at 5:35 AM, Gary Dusbabek wrote:

> +1
> 
> 
> On Tue, Apr 16, 2013 at 8:59 PM, Eric Evans  (mailto:eev...@sym-link.com)> wrote:
> 
> > 
> > Greets,
> > 
> > I propose the following for release as 1.1.11
> > 
> > SHA1: d939a0c958d36a3debfc63364a3fa569aa632c6e
> > Git:
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.1.11-tentative
> > Artifacts:
> > https://repository.apache.org/content/repositories/orgapachecassandra-108/org/apache/cassandra/apache-cassandra/1.1.11/
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachecassandra-108/
> > 
> > A Debian package is available here: http://people.apache.org/~eevans
> > 
> > The vote will be open for 72 hours (longer if needed).
> > 
> > Cheers,
> > 
> > 
> > [1]: http://goo.gl/QfZlg (CHANGES.txt)
> > [2]: http://goo.gl/O55QF (NEWS.txt)
> > [3]: http://goo.gl/KbiRm (Can't Hug Every Cat)
> > 
> > --
> > Eric Evans
> > eev...@sym-link.com (mailto:eev...@sym-link.com)
> > 
> 
> 
> 

Re: Time to roll 1.1.12?

[Pavel Yaskevich]

+1


On Tue, May 21, 2013 at 2:10 PM, Carl Yeksigian  wrote:

> +1 on the release, and +1 on the fork sticking :)
>
>
> On Tue, May 21, 2013 at 2:59 PM, Jonathan Ellis  wrote:
>
> > CHANGES:
> >  * Remove buggy thrift max message length option (CASSANDRA-5529)
> >  * Add retry mechanism to OTC for non-droppable_verbs (CASSANDRA-5393)
> >  * Use allocator information to improve memtable memory usage estimate
> >(CASSANDRA-5497)
> >  * fsync leveled manifest to avoid corruption (CASSANDRA-5535)
> >  * Fix Bound intersection computation (CASSANDRA-5551)
> >  * Fix NPE in Pig's widerow mode (CASSANDRA-5488)
> >
> > I'm feeling lucky that we're ready to stick a fork in 1.1.
> >
> > --
> > Jonathan Ellis
> > Project Chair, Apache Cassandra
> > co-founder, http://www.datastax.com
> > @spyced
> >
>

Re: [VOTE] Release Apache Cassandra 1.1.12 (Strike 2)

[Pavel Yaskevich]

+1


On Thu, May 23, 2013 at 10:12 AM, Jason Brown  wrote:

> +1
>
>
> On Thu, May 23, 2013 at 6:25 AM, Jonathan Ellis  wrote:
>
> > +1
> >
> > On Thu, May 23, 2013 at 3:03 AM, Sylvain Lebresne 
> > wrote:
> > > I propose the following artifacts for release as 1.1.12 (now with more
> > > #5488 fixes inside).
> > >
> > > sha1: 2dd73d171068d743befcd445a14751032d232e4e
> > > Git:
> > >
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.1.12-tentative
> > > Artifacts:
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-035/org/apache/cassandra/apache-cassandra/1.1.12/
> > > Staging repository:
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-035/
> > >
> > > 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/jm5Hz (CHANGES.txt)
> > > [2]: http://goo.gl/AQ3OP (NEWS.txt)
> >
> >
> >
> > --
> > Jonathan Ellis
> > Project Chair, Apache Cassandra
> > co-founder, http://www.datastax.com
> > @spyced
> >
>

Re: [VOTE] Release Apache Cassandra 1.2.6 (Strike 3)

[Pavel Yaskevich]

+1


On Tue, Jun 25, 2013 at 9:14 AM, Jonathan Ellis  wrote:

> Thanks for the confirmation, Michael.
>
> On Tue, Jun 25, 2013 at 6:28 AM, Michael Kjellman
>  wrote:
> > I know non members aren¹t supposed to comment on these votes, but I was
> > actually throwing 1.2.6 Strike 2ish into production when 3/4 of the way
> > thru I got Jason¹s email as I was debugging Gossip issues across the
> > cluster. It didn¹t appear to just break repair, but it also broke Gossip
> > (makes since given the scope of the patch). gossipinfo showed all nodes
> as
> > normal for what it¹s worth, but it required a complete cluster shutdown
> to
> > get rid of the bad state where some nodes believed other nodes were down
> > as it continued to propagate around the ring. that¹s life on the bleeding
> > edge. :(
> >
> > I built the equivalent of what Sylvan proposed here and things are
> running
> > smoothly for what it¹s worth, so +1.
> >
> > -michael
> >
> > On 6/25/13, 2:58 AM, "Carl Yeksigian"  wrote:
> >
> >>+1
> >>On Jun 25, 2013 10:42 AM, "Sylvain Lebresne" 
> wrote:
> >>
> >>> After having reverted CASSANDRA-5665, I propose the following artifacts
> >>>for
> >>> release as 1.2.6.
> >>>
> >>> sha1: a6ca5d496facf79c187310e81b3eeba3e6bc4b43
> >>> Git:
> >>>
> >>>
> >>>
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/
> >>>tags/1.2.6-tentative
> >>> Artifacts:
> >>>
> >>>
> >>>
> https://repository.apache.org/content/repositories/orgapachecassandra-068
> >>>/org/apache/cassandra/apache-cassandra/1.2.6/
> >>> Staging repository:
> >>>
> >>>
> https://repository.apache.org/content/repositories/orgapachecassandra-068
> >>>/
> >>>
> >>> The artifacts as well as the debian package are also available here:
> >>> http://people.apache.org/~slebresne/
> >>>
> >>> Since that release has already received quite a bit of testing, I
> >>>propose
> >>> to do
> >>> a short vote period and so the vote will be open for 24 hours (but
> >>>longer
> >>> if
> >>> needed).
> >>>
> >>> [1]: http://goo.gl/8Ih7f (CHANGES.txt)
> >>> [2]: http://goo.gl/nFiZc (NEWS.txt)
> >>>
> >
>
>
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>

Re: [VOTE] Release Apache Cassandra 2.0.0

[Pavel Yaskevich]

+1


On Fri, Aug 30, 2013 at 6:30 AM, Jake Luciani  wrote:

> +1
>
>
> On Wed, Aug 28, 2013 at 10:13 AM, Sylvain Lebresne  >wrote:
>
> > The RC2 period has been relatively calm so far and in term of timing,
> we're
> > way
> > late on our "regular 6 month schedule". It's time to release that final
> and
> > thus I propose the following artifacts for release as 2.0.0.
> >
> > sha1: 03045ca22b11b0e5fc85c4fabd83ce6121b5709b
> > Git:
> >
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.0.0-tentative
> > Artifacts:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-120/org/apache/cassandra/apache-cassandra/2.0.0/
> > Staging repository:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-120/
> >
> > 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/R8BxIz (CHANGES.txt)
> > [2]: http://goo.gl/gGCFnI (NEWS.txt)
> >
>
>
>
> --
> http://twitter.com/tjake
>

Re: Performance tickets

[Pavel Yaskevich]

Hi Jonathan,

  I can take on first two (4817, 5863).

Best Regards, Pavel.

> On Sep 19, 2013, at 8:46 AM, Jonathan Ellis  wrote:
> 
> https://issues.apache.org/jira/browse/CASSANDRA-5357 (query cache)
> 
>> On Thu, Sep 19, 2013 at 10:43 AM, Jonathan Ellis  wrote:
>> I'd like to spend some effort in 2.1 improving our performance story
>> for non-io-bound workloads.  Here are some of the ideas we have
>> floating around:
>> 
>> https://issues.apache.org/jira/browse/CASSANDRA-4718 (context switch 
>> overhead)
>> 
>> https://issues.apache.org/jira/browse/CASSANDRA-5863 (decompressed chunk 
>> cache)
>> 
>> https://issues.apache.org/jira/browse/CASSANDRA-5417 (composites 
>> optimization)
>> 
>> https://issues.apache.org/jira/browse/CASSANDRA-5019 (flyweight cell 
>> container)
>> 
>> https://issues.apache.org/jira/browse/CASSANDRA-5020 (switch off of
>> ByteBuffers in cell names and values.  Jake was also looking at using
>> primitives instead; I don't think there's a ticket for that?)
>> 
>> https://issues.apache.org/jira/browse/CASSANDRA-4175 (cell name compression)
>> 
>> https://issues.apache.org/jira/browse/CASSANDRA-6060 (avoid using
>> Strings internally for ks/cf identifiers)
>> 
>> Anything else I'm missing?
>> 
>> --
>> Jonathan Ellis
>> Project Chair, Apache Cassandra
>> co-founder, http://www.datastax.com
>> @spyced
> 
> 
> 
> -- 
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced

Re: [VOTE] Release Apache Cassandra 2.0.1

[Pavel Yaskevich]

I want to bump disruptor_thrift_server version to 3.0.1 today before C* 2.0.1, 
otherwise +1.

Sent from my iPhone

> On Sep 19, 2013, at 8:52 AM, Gary Dusbabek  wrote:
> 
> +1
> 
> 
> On Thu, Sep 19, 2013 at 7:23 AM, Sylvain Lebresne wrote:
> 
>> We have quite a bunch of bug fixed and new stuffs on the 2.0 branch that we
>> should get to the users. So I propose the following artifacts for release
>> as
>> 2.0.1.
>> 
>> sha1: 72c50bd7505c4d27838134882ef2c2d7d555f7be
>> Git:
>> 
>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.0.1-tentative
>> Artifacts:
>> 
>> https://repository.apache.org/content/repositories/orgapachecassandra-079/org/apache/cassandra/apache-cassandra/2.0.1/
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapachecassandra-079/
>> 
>> 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/URvgVt (CHANGES.txt)
>> [2]: http://goo.gl/EXLlJy (NEWS.txt)
>> 

Re: [VOTE] Release Apache Cassandra 1.2.10

[Pavel Yaskevich]

+1

> On Sep 19, 2013, at 8:15 AM, Yuki Morishita  wrote:
> 
> +1
> 
>> On Thu, Sep 19, 2013 at 8:15 AM, Gary Dusbabek  wrote:
>> +1
>> 
>> 
>> On Thu, Sep 19, 2013 at 3:59 AM, Sylvain Lebresne 
>> wrote:
>> 
>>> The changelog is getting big, I propose the following artifacts for release
>>> as 1.2.10.
>>> 
>>> sha1: 937536363a8a6d86ee32fe5ef90653264e67b6c7
>>> Git:
>>> 
>>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.2.10-tentative
>>> Artifacts:
>>> 
>>> https://repository.apache.org/content/repositories/orgapachecassandra-078/org/apache/cassandra/apache-cassandra/1.2.10/
>>> Staging repository:
>>> https://repository.apache.org/content/repositories/orgapachecassandra-078/
>>> 
>>> 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/x1wOFw (CHANGES.txt)
>>> [2]: http://goo.gl/VOHl5l (NEWS.txt)
> 
> 
> 
> -- 
> Yuki Morishita
> t:yukim (http://twitter.com/yukim)

Re: [VOTE] Release Apache Cassandra 2.0.1

[Pavel Yaskevich]

I'm done with my changes.


On Thu, Sep 19, 2013 at 1:57 PM, Pavel Yaskevich  wrote:

> Meanwhile, I'm going to release thrift-server 0.3.2, because thrift was
> updated to 0.9.1 and dump version in Cassandra (currently on it).
>
>
> On Thu, Sep 19, 2013 at 1:12 PM, Jonathan Ellis  wrote:
>
>> https://issues.apache.org/jira/browse/CASSANDRA-6067
>>
>> On Thu, Sep 19, 2013 at 3:01 PM, Jonathan Ellis 
>> wrote:
>> > I think  was merged incorrectly to 2.0 in the first place.
>> >
>> > On Thu, Sep 19, 2013 at 2:54 PM, Jonathan Ellis 
>> wrote:
>> >> Hmm, looks like we broke CASSANDRA- at some point, sstableloader
>> >> isn't supposed to be pooling at all.
>> >>
>> >> On Thu, Sep 19, 2013 at 2:37 PM, Yuki Morishita 
>> wrote:
>> >>> I think https://issues.apache.org/jira/browse/CASSANDRA-5661 broke
>> >>> offline tools like sstableloader.
>> >>>
>> >>> I am getting following error:
>> >>>
>> >>> Exception in thread "main" java.lang.ExceptionInInitializerError
>> >>> at
>> org.apache.cassandra.io.util.PoolingSegmentedFile.getSegment(PoolingSegmentedFile.java:36)
>> >>> at
>> org.apache.cassandra.io.util.SegmentedFile$SegmentIterator.next(SegmentedFile.java:161)
>> >>> at
>> org.apache.cassandra.io.util.SegmentedFile$SegmentIterator.next(SegmentedFile.java:142)
>> >>> at
>> org.apache.cassandra.io.sstable.SSTableReader.getPosition(SSTableReader.java:896)
>> >>> at
>> org.apache.cassandra.io.sstable.SSTableReader.getPosition(SSTableReader.java:831)
>> >>> at
>> org.apache.cassandra.io.sstable.SSTableReader.getPositionsForRanges(SSTableReader.java:743)
>> >>> at
>> org.apache.cassandra.io.sstable.SSTableLoader$1.accept(SSTableLoader.java:122)
>> >>> at java.io.File.list(File.java:1087)
>> >>> at
>> org.apache.cassandra.io.sstable.SSTableLoader.openSSTables(SSTableLoader.java:73)
>> >>> at
>> org.apache.cassandra.io.sstable.SSTableLoader.stream(SSTableLoader.java:155)
>> >>> at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:66)
>> >>> Caused by: java.lang.NullPointerException
>> >>> at
>> org.apache.cassandra.config.DatabaseDescriptor.getFileCacheSizeInMB(DatabaseDescriptor.java:1145)
>> >>> at
>> org.apache.cassandra.service.FileCacheService.(FileCacheService.java:41)
>> >>> ... 11 more
>> >>>
>> >>> Looks like new file_cache_size_in_mb does not have default value.
>> >>>
>> >>> On Thu, Sep 19, 2013 at 12:34 PM, Jonathan Ellis 
>> wrote:
>> >>>> Does that mean we need to rebuild the 2.0.1 artifacts?
>> >>>>
>> >>>> On Thu, Sep 19, 2013 at 12:18 PM, Pavel Yaskevich 
>> wrote:
>> >>>>> I want to bump disruptor_thrift_server version to 3.0.1 today
>> before C* 2.0.1, otherwise +1.
>> >>>>>
>> >>>>> Sent from my iPhone
>> >>>>>
>> >>>>>> On Sep 19, 2013, at 8:52 AM, Gary Dusbabek 
>> wrote:
>> >>>>>>
>> >>>>>> +1
>> >>>>>>
>> >>>>>>
>> >>>>>> On Thu, Sep 19, 2013 at 7:23 AM, Sylvain Lebresne <
>> sylv...@datastax.com>wrote:
>> >>>>>>
>> >>>>>>> We have quite a bunch of bug fixed and new stuffs on the 2.0
>> branch that we
>> >>>>>>> should get to the users. So I propose the following artifacts for
>> release
>> >>>>>>> as
>> >>>>>>> 2.0.1.
>> >>>>>>>
>> >>>>>>> sha1: 72c50bd7505c4d27838134882ef2c2d7d555f7be
>> >>>>>>> Git:
>> >>>>>>>
>> >>>>>>>
>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.0.1-tentative
>> >>>>>>> Artifacts:
>> >>>>>>>
>> >>>>>>>
>> https://repository.apache.org/content/repositories/orgapachecassandra-079/org/apache/cassandra/apache-cassandra/2.0.1/
>> >>>>>>> Staging repository:
>> >>>>>>>
>> https://repository.apache.org/content/repositories/orgapachecassandra-079/
>> >>>>>>>
>> >>>>>>> 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/URvgVt (CHANGES.txt)
>> >>>>>>> [2]: http://goo.gl/EXLlJy (NEWS.txt)
>> >>>>>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Jonathan Ellis
>> >>>> Project Chair, Apache Cassandra
>> >>>> co-founder, http://www.datastax.com
>> >>>> @spyced
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Yuki Morishita
>> >>>  t:yukim (http://twitter.com/yukim)
>> >>
>> >>
>> >>
>> >> --
>> >> Jonathan Ellis
>> >> Project Chair, Apache Cassandra
>> >> co-founder, http://www.datastax.com
>> >> @spyced
>> >
>> >
>> >
>> > --
>> > Jonathan Ellis
>> > Project Chair, Apache Cassandra
>> > co-founder, http://www.datastax.com
>> > @spyced
>>
>>
>>
>> --
>> Jonathan Ellis
>> Project Chair, Apache Cassandra
>> co-founder, http://www.datastax.com
>> @spyced
>>
>
>

Re: [VOTE] Release Apache Cassandra 2.0.1

[Pavel Yaskevich]

Meanwhile, I'm going to release thrift-server 0.3.2, because thrift was
updated to 0.9.1 and dump version in Cassandra (currently on it).


On Thu, Sep 19, 2013 at 1:12 PM, Jonathan Ellis  wrote:

> https://issues.apache.org/jira/browse/CASSANDRA-6067
>
> On Thu, Sep 19, 2013 at 3:01 PM, Jonathan Ellis  wrote:
> > I think  was merged incorrectly to 2.0 in the first place.
> >
> > On Thu, Sep 19, 2013 at 2:54 PM, Jonathan Ellis 
> wrote:
> >> Hmm, looks like we broke CASSANDRA- at some point, sstableloader
> >> isn't supposed to be pooling at all.
> >>
> >> On Thu, Sep 19, 2013 at 2:37 PM, Yuki Morishita 
> wrote:
> >>> I think https://issues.apache.org/jira/browse/CASSANDRA-5661 broke
> >>> offline tools like sstableloader.
> >>>
> >>> I am getting following error:
> >>>
> >>> Exception in thread "main" java.lang.ExceptionInInitializerError
> >>> at
> org.apache.cassandra.io.util.PoolingSegmentedFile.getSegment(PoolingSegmentedFile.java:36)
> >>> at
> org.apache.cassandra.io.util.SegmentedFile$SegmentIterator.next(SegmentedFile.java:161)
> >>> at
> org.apache.cassandra.io.util.SegmentedFile$SegmentIterator.next(SegmentedFile.java:142)
> >>> at
> org.apache.cassandra.io.sstable.SSTableReader.getPosition(SSTableReader.java:896)
> >>> at
> org.apache.cassandra.io.sstable.SSTableReader.getPosition(SSTableReader.java:831)
> >>> at
> org.apache.cassandra.io.sstable.SSTableReader.getPositionsForRanges(SSTableReader.java:743)
> >>> at
> org.apache.cassandra.io.sstable.SSTableLoader$1.accept(SSTableLoader.java:122)
> >>> at java.io.File.list(File.java:1087)
> >>> at
> org.apache.cassandra.io.sstable.SSTableLoader.openSSTables(SSTableLoader.java:73)
> >>> at
> org.apache.cassandra.io.sstable.SSTableLoader.stream(SSTableLoader.java:155)
> >>> at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:66)
> >>> Caused by: java.lang.NullPointerException
> >>> at
> org.apache.cassandra.config.DatabaseDescriptor.getFileCacheSizeInMB(DatabaseDescriptor.java:1145)
> >>> at
> org.apache.cassandra.service.FileCacheService.(FileCacheService.java:41)
> >>> ... 11 more
> >>>
> >>> Looks like new file_cache_size_in_mb does not have default value.
> >>>
> >>> On Thu, Sep 19, 2013 at 12:34 PM, Jonathan Ellis 
> wrote:
> >>>> Does that mean we need to rebuild the 2.0.1 artifacts?
> >>>>
> >>>> On Thu, Sep 19, 2013 at 12:18 PM, Pavel Yaskevich 
> wrote:
> >>>>> I want to bump disruptor_thrift_server version to 3.0.1 today before
> C* 2.0.1, otherwise +1.
> >>>>>
> >>>>> Sent from my iPhone
> >>>>>
> >>>>>> On Sep 19, 2013, at 8:52 AM, Gary Dusbabek 
> wrote:
> >>>>>>
> >>>>>> +1
> >>>>>>
> >>>>>>
> >>>>>> On Thu, Sep 19, 2013 at 7:23 AM, Sylvain Lebresne <
> sylv...@datastax.com>wrote:
> >>>>>>
> >>>>>>> We have quite a bunch of bug fixed and new stuffs on the 2.0
> branch that we
> >>>>>>> should get to the users. So I propose the following artifacts for
> release
> >>>>>>> as
> >>>>>>> 2.0.1.
> >>>>>>>
> >>>>>>> sha1: 72c50bd7505c4d27838134882ef2c2d7d555f7be
> >>>>>>> Git:
> >>>>>>>
> >>>>>>>
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.0.1-tentative
> >>>>>>> Artifacts:
> >>>>>>>
> >>>>>>>
> https://repository.apache.org/content/repositories/orgapachecassandra-079/org/apache/cassandra/apache-cassandra/2.0.1/
> >>>>>>> Staging repository:
> >>>>>>>
> https://repository.apache.org/content/repositories/orgapachecassandra-079/
> >>>>>>>
> >>>>>>> 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/URvgVt (CHANGES.txt)
> >>>>>>> [2]: http://goo.gl/EXLlJy (NEWS.txt)
> >>>>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Jonathan Ellis
> >>>> Project Chair, Apache Cassandra
> >>>> co-founder, http://www.datastax.com
> >>>> @spyced
> >>>
> >>>
> >>>
> >>> --
> >>> Yuki Morishita
> >>>  t:yukim (http://twitter.com/yukim)
> >>
> >>
> >>
> >> --
> >> Jonathan Ellis
> >> Project Chair, Apache Cassandra
> >> co-founder, http://www.datastax.com
> >> @spyced
> >
> >
> >
> > --
> > Jonathan Ellis
> > Project Chair, Apache Cassandra
> > co-founder, http://www.datastax.com
> > @spyced
>
>
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>

Re: [VOTE] Release Apache Cassandra 2.0.1 (strike 2)

[Pavel Yaskevich]

+1

> On Sep 20, 2013, at 5:55 AM, Gary Dusbabek  wrote:
> 
> +1
> 
> 
> On Fri, Sep 20, 2013 at 4:39 AM, Sylvain Lebresne wrote:
> 
>> Same player, try again. I propose the following artifacts for release as
>> 2.0.1.
>> 
>> sha1: eb96db6c19515e6d1215230f29d25b46fcd005ef
>> Git:
>> 
>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.0.1-tentative
>> Artifacts:
>> 
>> https://repository.apache.org/content/repositories/orgapachecassandra-085/org/apache/cassandra/apache-cassandra/2.0.1/
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapachecassandra-085/
>> 
>> 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/LNAdjU (CHANGES.txt)
>> [2]: http://goo.gl/KuHgLs (NEWS.txt)
>> 

Re: [VOTE] Release Apache Cassandra 1.2.12

[Pavel Yaskevich]

+1


On Wed, Nov 20, 2013 at 6:54 AM, Gary Dusbabek  wrote:

> +1
>
>
> On Wed, Nov 20, 2013 at 3: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: [VOTE] Release Apache Cassandra 2.0.6

[Pavel Yaskevich]

+1

> On Mar 7, 2014, at 7:52 AM, Sylvain Lebresne  wrote:
> 
> We're starting to have a really big changelog so I propose the following
> artifacts for release as 2.0.6.
> 
> sha1: 656edc529db59f0002a7fb0eed93339071fd3974
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.0.6-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1007/org/apache/cassandra/apache-cassandra/2.0.6/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1007/
> 
> 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/dpGEUu (CHANGES.txt)
> [2]: http://goo.gl/6RPO71 (NEWS.txt)

Re: Proposal: freeze Thrift starting with 2.1.0

[Pavel Yaskevich]

Sounds good to me, I was under an impression that we already did freeze
Thrift tho...


On Tue, Mar 11, 2014 at 10:00 AM, Jonathan Ellis  wrote:

> CQL3 is almost two years old now and has proved to be the better API
> that Cassandra needed.  CQL drivers have caught up with and passed the
> Thrift ones in terms of features, performance, and usability.  CQL is
> easier to learn and more productive than Thrift.
>
> With static columns and LWT batch support [1] landing in 2.0.6, and
> UDT in 2.1 [2], I don't know of any use cases for Thrift that can't be
> done in CQL.  Contrawise, CQL makes many things easy that are
> difficult to impossible in Thrift.  New development is overwhelmingly
> done using CQL.
>
> To date we have had an unofficial and poorly defined policy of "add
> support for new features to Thrift when that is 'easy.'"  However,
> even relatively simple Thrift changes can create subtle complications
> for the rest of the server; for instance, allowing Thrift range
> tombtones would make filter conversion for CASSANDRA-6506 more
> difficult.
>
> Thus, I think it's time to officially close the book on Thrift.  We
> will retain it for backwards compatibility, but we will commit to
> adding no new features or changes to the Thrift API after 2.1.0.  This
> will help send an unambiguous message to users and eliminate any
> remaining confusion from supporting two APIs.  If any new use cases
> come to light that can be done with Thrift but not CQL, we will commit
> to supporting those in CQL.
>
> (To a large degree, this merely formalizes what is already de facto
> reality.  Most thrift clients have not even added support for
> atomic_batch_mutate and cas from 2.0, and popular clients like
> Astyanax are migrating to the native protocol.)
>
> Reasonable?
>
> [1] https://issues.apache.org/jira/browse/CASSANDRA-6561
> [2] https://issues.apache.org/jira/browse/CASSANDRA-5590
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>

Re: [VOTE] Release Apache Cassandra 1.2.16

[Pavel Yaskevich]

+1


On Mon, Mar 24, 2014 at 12:05 PM, Jonathan Ellis  wrote:

> +1
>
> On Mon, Mar 24, 2014 at 12:24 PM, Sylvain Lebresne 
> wrote:
> > I propose the following artifacts for release as 1.2.16.
> >
> > sha1: 05fcfa2be4eba2cd6daeee62d943f48c45f42668
> > Git:
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.2.16-tentative
> > Artifacts:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1008/org/apache/cassandra/apache-cassandra/1.2.16/
> > Staging repository:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1008/
> >
> > 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/Cgiimu (CHANGES.txt)
> > [2]: http://goo.gl/gvKkBm (NEWS.txt)
>
>
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>

Re: [VOTE RESURRECTED] Release Apache Cassandra 1.2.16

[Pavel Yaskevich]

+1


On Thu, Mar 27, 2014 at 11:01 AM, Gary Dusbabek  wrote:

> +1
>
>
> On Thu, Mar 27, 2014 at 9:44 AM, Sylvain Lebresne  >wrote:
>
> > So, seems like CASSANDRA-6924 was kind of a false alarm. And since I've
> > never dropped
> > the artifacts and no commit has been done on 1.2 since then, I propose to
> > just resurrect the
> > vote. Since the vote had initially ran for 2 days, I'm going to propose
> > that we only extend for
> > just 24h more hours (provided we get enough +1 by then). Please do
> re-vote
> > however.
> >
> > --
> > Sylvain
> >
> >
> > On Wed, Mar 26, 2014 at 9:02 AM, Sylvain Lebresne  > >wrote:
> >
> > > Alright, let's figure out what's going on there and we'll restart a new
> > > vote from there.
> > >
> > >
> > >
> > > On Tue, Mar 25, 2014 at 7:57 PM, Tyler Hobbs 
> wrote:
> > >
> > >> Created https://issues.apache.org/jira/browse/CASSANDRA-6924 to
> > >> investigate.
> > >>
> > >>
> > >> On Tue, Mar 25, 2014 at 1:50 PM, Tyler Hobbs 
> > wrote:
> > >>
> > >> > After digging a bit, the regression is that data inserted
> immediately
> > >> > after secondary index creation may never get indexed.
> > >> >
> > >> > The operation order goes like this:
> > >> > 1) create CF
> > >> > 2) create secondary index
> > >> > 3) insert data
> > >> > 4) query secondary index
> > >> >
> > >> > If I add a short sleep in between steps 2 and 3, the data gets
> indexed
> > >> and
> > >> > the query is successful.
> > >> >
> > >> > If I only add a sleep in between steps 3 and 4, some of the data is
> > >> never
> > >> > indexed and the query will return incomplete results.  This appears
> to
> > >> be
> > >> > the case even if the sleep is relatively long (30s), which makes me
> > >> think
> > >> > the data may never get indexed.
> > >> >
> > >> >
> > >> > On Tue, Mar 25, 2014 at 11:14 AM, Tyler Hobbs 
> > >> wrote:
> > >> >
> > >> >> -1
> > >> >>
> > >> >> I'm seeing a regression from 1.2.15 on secondary index queries
> > (through
> > >> >> Thrift) with a LongType key validator.  Specifically, this test in
> > >> pycassa
> > >> >> is failing against 1.2.16-tentative:
> > >> >>
> > >>
> >
> https://github.com/pycassa/pycassa/blob/master/tests/test_autopacking.py#L793
> > >> >>
> > >> >> I haven't looked into the issue deeply yet to see what's going on.
> > >> >>
> > >> >>
> > >> >> On Mon, Mar 24, 2014 at 12:24 PM, Sylvain Lebresne <
> > >> sylv...@datastax.com>wrote:
> > >> >>
> > >> >>> I propose the following artifacts for release as 1.2.16.
> > >> >>>
> > >> >>> sha1: 05fcfa2be4eba2cd6daeee62d943f48c45f42668
> > >> >>> Git:
> > >> >>>
> > >> >>>
> > >>
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.2.16-tentative
> > >> >>> Artifacts:
> > >> >>>
> > >> >>>
> > >>
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1008/org/apache/cassandra/apache-cassandra/1.2.16/
> > >> >>> Staging repository:
> > >> >>>
> > >> >>>
> > >>
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1008/
> > >> >>>
> > >> >>> 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/Cgiimu (CHANGES.txt)
> > >> >>> [2]: http://goo.gl/gvKkBm (NEWS.txt)
> > >> >>>
> > >> >>
> > >> >>
> > >> >>
> > >> >> --
> > >> >> Tyler Hobbs
> > >> >> DataStax 
> > >> >>
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Tyler Hobbs
> > >> > DataStax 
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> Tyler Hobbs
> > >> DataStax 
> > >>
> > >
> > >
> >
>

Re: [VOTE] Release Apache Cassandra 2.0.7

[Pavel Yaskevich]

Can I push new release of the thrift-server before we roll 2.0.7?


On Mon, Apr 14, 2014 at 10:57 AM, Jonathan Ellis  wrote:

> +1
> On Apr 14, 2014 10:39 AM, "Sylvain Lebresne"  wrote:
>
> > sha1: 7dbbe9233ce83c2a473ba2510c827a661de99400
> > Git:
> >
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.0.7-tentative
> > Artifacts:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1009/org/apache/cassandra/apache-cassandra/2.0.7/
> > Staging repository:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1009/
> >
> > 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/6yg6Xh (CHANGES.txt)
> > [2]: http://goo.gl/GxmBC9 (NEWS.txt)
> >
>

Re: [VOTE] Release Apache Cassandra 2.1.0-beta2

[Pavel Yaskevich]

+1


On Thu, May 1, 2014 at 10:01 AM, Jake Luciani  wrote:

> +1
>
>
> On Thu, May 1, 2014 at 12:01 PM, Sylvain Lebresne  >wrote:
>
> > It's time to get the 2nd beta for 2.1 out. Note that we know it's not bug
> > free
> > at all, but every main features we wanted for 2.1 is in, so we want to
> get
> > that
> > out to get as much testing as possible to get a solid RC1.
> >
> > sha1: 48727b4ccb3930d4cd56c1fde3784f7e862a2f94
> > Git:
> >
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.1.0-beta2-tentative
> > Artifacts:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1010/org/apache/cassandra/apache-cassandra/2.1.0-beta2/
> > Staging repository:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1010/
> >
> > 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/Iwaoco (CHANGES.txt)
> > [2]: http://goo.gl/vUPmoz (NEWS.txt)
> >
>
>
>
> --
> http://twitter.com/tjake
>

Re: [VOTE] Release Apache Cassandra 2.0.8 (strike 2)

[Pavel Yaskevich]

+1


On Wed, May 21, 2014 at 10:32 AM, Mikhail Stepura <
mikhail.step...@outlook.com> wrote:

> +1
>
> -M
>
> On May 21, 2014, at 6:19, Sylvain Lebresne  wrote:
>
> > Since we closed the first try we've fixed even more bugs, with notable
> > things
> > like CASSANDRA-6285. In any case, that changelog is getting pretty damn
> > long so
> > I propose the following artifacts for release as 2.0.8.
> >
> > sha1: 484d2816940cd2eb22d2365fcb376dd27e059e2e
> > Git:
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.0.8-tentative
> > Artifacts:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1012/org/apache/cassandra/apache-cassandra/2.0.8/
> > Staging repository:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1012/
> >
> > 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/EE3aHy (CHANGES.txt)
> > [2]: http://goo.gl/dkl3Yu (NEWS.txt)
>
>

Re: [VOTE] Release Apache Cassandra 1.2.18

[Pavel Yaskevich]

+1


On Wed, Jul 2, 2014 at 9:35 AM, Gary Dusbabek  wrote:

> +1
>  On Jul 2, 2014 6:36 AM, "Sylvain Lebresne"  wrote:
>
> > 1.2.17 shipped with a reference to a java 7 class (see CASSANDRA-7147).
> As
> > consequence, the source don't build on java 6. Regarding the binary
> > artifacts,
> > they are still targeted to java 6 so the only thing that doesn't work is
> > the
> > use of the new cloudstack snitch (which is new in 1.2.17). So anyway,
> > having a
> > 1.2 release for which the source don't compile with java 6 is not ideal
> so
> > I
> > propose the following artifacts (which fix that problem) for release as
> > 1.2.18.
> > As the diff with 1.2.17 is really small, I also propose to stick to a
> short
> > 24h
> > vote.
> >
> > sha1: 5a658be5ed3339b7dc52084d7eb33dd8295fa9f3
> > Git:
> >
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.2.18-tentative
> > Artifacts:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1019/org/apache/cassandra/apache-cassandra/1.2.18/
> > Staging repository:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1019/
> >
> > The artifacts as well as the debian package are also available here:
> > http://people.apache.org/~slebresne/
> >
> > The vote will be open for 24 hours (longer if needed).
> >
> > [1]: http://goo.gl/uYg6tj (CHANGES.txt)
> > [2]: http://goo.gl/ak45bd (NEWS.txt)
> >
>

Re: Reminder: 68 patches pending review

[Pavel Yaskevich]

Hi Jonathan,

   I have commented on 7885 and can take something of Yuki or Marcus if
they don't mind.

Best Regards, Pavel.

On Wed, Oct 1, 2014 at 2:10 PM, Jonathan Ellis  wrote:

> All tickets patch available:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20AND%20status%20%3D%20%22Patch%20Available%22%20ORDER%20BY%20reviewer%20DESC
>
> Your reviews (if logged in):
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20AND%20status%20%3D%20%22Patch%20Available%22%20AND%20reviewer%20%3D%20currentUser%28%29%20ORDER%20BY%20priority%20DESC
>
> It's okay to review a patch even if it's assigned to someone else!
>
> Conversely, if you are assigned as reviewer to a ticket that you know you
> won't have time to get to for a while, let me know and I'll try to find
> someone to take a look at it.
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>

Re: Reminder: 68 patches pending review

[Pavel Yaskevich]

Sure!

On Thu, Oct 2, 2014 at 10:38 AM, Marcus Eriksson  wrote:

> On Thu, Oct 2, 2014 at 1:17 AM, Pavel Yaskevich  wrote:
>
> > Hi Jonathan,
> >
> >I have commented on 7885 and can take something of Yuki or Marcus if
> > they don't mind.
> >
>
> https://issues.apache.org/jira/browse/CASSANDRA-7872 perhaps?
>
> /Marcus
>

Re: 3.0 and the Cassandra release process

[Pavel Yaskevich]

+1

On Wed, Mar 18, 2015 at 3:50 PM, Michael Kjellman <
mkjell...@internalcircle.com> wrote:

> For most of my life I’ve lived on the software bleeding edge both
> personally and professionally. Maybe it’s a personal weakness, but I guess
> I get a thrill out of the problem solving aspect?
>
> Recently I came to a bit of an epiphany — the closer I keep to the daily
> build — generally the happier I am on a daily basis. Bugs happen, but for
> the most part (aside from show stopper bugs), pain points for myself in a
> given daily build can generally can be debugged to 1 or maybe 2 root
> causes, fixed in ~24 hours, and then life is better the next day again. In
> comparison, the old waterfall model generally means taking an “official”
> release at some point and waiting for some poor soul (or developer) to
> actually run the thing. No matter how good the QA team is, until it’s
> actually used in the real world, most bugs aren’t found.
>
> If you and your organization can wait 24 hours * number of bugs discovered
> after people actually started using the thing, you end up with a “usable
> build” around the holy-grail minor X.X.5 release of Cassandra.
>
> I love the idea of the LTS model Jonathan describes because it means more
> code can get real testing and “bake” for longer instead of sitting largely
> unused on some git repository in a datacenter far far away. A lot of code
> has changed between 2.0 and trunk today. The code has diverged to the point
> that if you write something for 2.0 (as the most stable major branch
> currently available), merging it forward to 3.0 or after generally means
> rewriting it. If the only thing that comes out of this is a smaller delta
> of LOC between the deployable version/branch and what we can develop
> against and what QA is focused on I think that’s a massive win.
>
> Something like CASSANDRA-8099 will need 2x the baking time of even many of
> the more risky changes the project has made. While I wouldn’t want to run a
> build with CASSANDRA-8099 in it anytime soon, there are now hundreds of
> other changes blocked, most likely many containing new bugs of their own,
> but have no exposure at all to even the most involved C* developers.
>
> I really think this will be a huge win for the project and I’m super
> thankful for Sylvian, Ariel, Jonathan, Aleksey, and Jake for guiding this
> change to a much more sustainable release model for the entire community.
>
> best,
> kjellman
>
>
> > On Mar 18, 2015, at 3:02 PM, Ariel Weisberg 
> wrote:
> >
> > Hi,
> >
> > Keep in mind it is a bug fix release every month and a feature release
> every two months.
> >
> > For development that is really a two month cycle with all bug fixes
> being backported one release. As a developer if you want to get something
> in a release you have two months and you should be sizing pieces of large
> tasks so they ship at least every two months.
> >
> > Ariel
> >> On Mar 18, 2015, at 5:58 PM, Terrance Shepherd 
> wrote:
> >>
> >> I like the idea but I agree that every month is a bit aggressive. I
> have no
> >> say but:
> >>
> >> I would say 4 releases a year instead of 12. with 2 months of new
> features
> >> and 1 month of bug squashing per a release. With the 4th quarter just
> bugs.
> >>
> >> I would also proposed 2 year LTS releases for the releases after the 4th
> >> quarter. So everyone could get a new feature release every quarter and
> the
> >> stability of super major versions for 2 years.
> >>
> >> On Wed, Mar 18, 2015 at 2:34 PM, Dave Brosius  >
> >> wrote:
> >>
> >>> It would seem the practical implications of this is that there would be
> >>> significantly more development on branches, with potentially more
> >>> significant delays on merging these branches. This would imply to me
> that
> >>> more Jenkins servers would need to be set up to handle auto-testing of
> more
> >>> branches, as if feature work spends more time on external branches, it
> is
> >>> then likely to be be less tested (even if by accident) as less
> developers
> >>> would be working on that branch. Only when a feature was blessed to
> make it
> >>> to the release-tracked branch, would it become exposed to the majority
> of
> >>> developers/testers, etc doing normal running/playing/testing.
> >>>
> >>> This isn't to knock the idea in anyway, just wanted to mention what i
> >>> think the outcome would be.
> >>>
> >>> dave
> >>>
> >>>
> >>>
> 
> >> On Tue, Mar 17, 2015 at 5:06 PM, Jonathan Ellis 
> > wrote:
> >>> Cassandra 2.1 was released in September, which means that if we
> were
> > on
> >>> track with our stated goal of six month releases, 3.0 would be done
> > about
> >>> now.  Instead, we haven't even delivered a beta.  The immediate
> cause
> >> this
> >>> time is blocking for 8099
> >>> , but the
> > reality
> >> is
> >>> that nobody should really be surprised.  Something always comes up
> --
> 

Re: CQL support for compound columns

[Pavel Yaskevich]

Hi, 

 I +1 Gamma. 

Best Regards
-- 
Pavel Yaskevich

Re: [VOTE] Release Apache Cassandra 1.0.9

[Pavel Yaskevich]

+1 

-- 
Pavel Yaskevich


On Monday 2 April 2012 at 17:25, Jonathan Ellis wrote:

> +1
> 
> On Mon, Apr 2, 2012 at 8:33 AM, Sylvain Lebresne  (mailto:sylv...@datastax.com)> wrote:
> > 1.0.8 has been release more than a month ago, we made quite a few bug fixes
> > and don't have any major outstanding issue open. I thus propose the 
> > following
> > artifacts for release as 1.0.9.
> > 
> > sha1: 4457839b9da623d9d4a090fa444614c35d39bb4c
> > Git: 
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.0.9-tentative
> > Artifacts: 
> > https://repository.apache.org/content/repositories/orgapachecassandra-001/org/apache/cassandra/apache-cassandra/1.0.9/
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachecassandra-001/
> > 
> > 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/CsEDg (CHANGES.txt)
> > [2]: http://goo.gl/4ByoR (NEWS.txt)
> > 
> 
> 
> 
> 
> -- 
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder of DataStax, the source for professional Cassandra support
> http://www.datastax.com
> 
> 

Re: [VOTE] Release Apache Cassandra 1.0.9 (strike 2)

[Pavel Yaskevich]

+1

3 apr 2012 kl. 22:38 skrev Jonathan Ellis :

> +1
>
> On Tue, Apr 3, 2012 at 10:21 AM, Sylvain Lebresne  
> wrote:
>> The first attempt was closed to include the fix for CASSANDRA-4112. After 
>> have
>> committed said fix, I'm proposing the following artifacts for release as 
>> 1.0.9.
>>
>> sha1: 3fd0fb6aa0038f0c8aaf34f98f2ceed2f308a501
>> Git: 
>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.0.9-tentative
>> Artifacts: 
>> https://repository.apache.org/content/repositories/orgapachecassandra-008/org/apache/cassandra/apache-cassandra/1.0.9/
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapachecassandra-008/
>>
>> 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/xmORw (CHANGES.txt)
>> [2]: http://goo.gl/t0sSe (NEWS.txt)
>
>
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder of DataStax, the source for professional Cassandra support
> http://www.datastax.com

Re: [VOTE] Release Apache Cassandra 1.1.0-rc1

[Pavel Yaskevich]

+1 

-- 
Pavel Yaskevich


On Thursday 12 April 2012 at 17:48, Jonathan Ellis wrote:

> +1
> 
> Would you be okay with a 24h period for this vote?
> 
> On Thu, Apr 12, 2012 at 4:56 AM, Sylvain Lebresne  (mailto:sylv...@datastax.com)> wrote:
> > We didn't get much issues from beta 2 and pretty much all current issues for
> > 1.1.0 has been resolved, so it is time for a release canditate. I thus 
> > propose
> > the following artifacts for release as 1.1.0-rc1.
> > 
> > sha1: cbbf54910f7f98e9f4b944b984b2460f42cd50bd
> > Git: 
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.1.0-rc1-tentative
> > Artifacts: 
> > https://repository.apache.org/content/repositories/orgapachecassandra-035/org/apache/cassandra/apache-cassandra/1.1.0-rc1/
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachecassandra-035/
> > 
> > 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/gjLT8 (CHANGES.txt)
> > [2]: http://goo.gl/VsciE (NEWS.txt)
> > 
> 
> 
> 
> 
> -- 
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder of DataStax, the source for professional Cassandra support
> http://www.datastax.com
> 
> 

Re: nosetests

[Pavel Yaskevich]

That happens sometimes when tests fail unexpectedly, you can delete 
/home/mildewey/Projects/cassandra/system_test.pid and start nosetests again.

On Sunday 15 April 2012 at 01:35, Mark Dewey wrote:

> With the =ve I got 92 copies of this (one for each test):
> 
> ==
> ERROR: system.test_thrift_server.TestTruncate.test_truncate
> --
> Traceback (most recent call last):
> File "/usr/lib/pymodules/python2.7/nose/case.py", line 367, in setUp
> try_run(self.inst, ('setup', 'setUp'))
> File "/usr/lib/pymodules/python2.7/nose/util.py", line 491, in try_run
> return func()
> File "/home/mildewey/Projects/cassandra/test/system/__init__.py", line
> 68, in setUp
> sys.exit()
> SystemExit:
>  >> begin captured stdout << -
> Unclean shutdown detected,
> (/home/mildewey/Projects/cassandra/system_test.pid found)
> 
> - >> end captured stdout << --
> 
> 
> On Sat, Apr 14, 2012 at 2:33 PM, Brandon Williams  (mailto:dri...@gmail.com)> wrote:
> 
> > Try nosetests -ve to see which one is failing and exit on the first error.
> > On Apr 14, 2012 1:34 PM, "Mark Dewey"  > (mailto:milde...@gmail.com)> wrote:
> > 
> > > I thought I followed the instructions to set up the nose tests, but when I
> > > run them all they do is (slowly) print out ".E" and then hang. Any clues?
> > > 
> > > Mark 

Re: [VOTE] Release Apache Cassandra 1.1

[Pavel Yaskevich]

+1

On Saturday 21 April 2012 at 00:31, Brandon Williams wrote:

> +1
> 
> On Fri, Apr 20, 2012 at 12:38 PM, Sylvain Lebresne  (mailto:sylv...@datastax.com)> wrote:
> > The RC1 went well and we basically don't have any issue open left, so I
> > think it's time to release the final Cassandra 1.1. I thus propose the
> > following artifacts for release as 1.1.0.
> > 
> > sha1: c671532825b9e05bd2b50e3aa2d1c5f5156d1c9f
> > Git: 
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.1.0-tentative
> > Artifacts: 
> > https://repository.apache.org/content/repositories/orgapachecassandra-077/org/apache/cassandra/apache-cassandra/1.1.0/
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachecassandra-077/
> > 
> > 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/KOOnk (CHANGES.txt)
> > [2]: http://goo.gl/o1la0 (NEWS.txt)
> > 
> 
> 
> 

Re: 6 months a more realistic release cycle?

[Pavel Yaskevich]

Sounds good to me, +1. 

-- 
Pavel Yaskevich


On Saturday 21 April 2012 at 01:07, Eric Evans wrote:

> On Fri, Apr 20, 2012 at 12:57 PM, Jonathan Ellis  (mailto:jbel...@gmail.com)> 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?
> 
> I agree; +1
> 
> -- 
> Eric Evans
> Acunu | http://www.acunu.com | @acunu
> 
> 

Re: [VOTE] Release Apache Cassandra 1.0.10

[Pavel Yaskevich]

+1

On Friday 4 May 2012 at 20:35, Brandon Williams wrote:

> +1
> 
> On Fri, May 4, 2012 at 11:33 AM, Sylvain Lebresne  (mailto:sylv...@datastax.com)> wrote:
> > It's been a month since 1.0.9 and CASSANDRA-4116 is kind of a big deal so I
> > propose the following artifacts for release as 1.0.10.
> > 
> > sha1: b2ca7f82122325f1fe83478e6609d71805dcfc84
> > Git: 
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.0.10-tentative
> > Artifacts: 
> > https://repository.apache.org/content/repositories/orgapachecassandra-036/org/apache/cassandra/apache-cassandra/1.0.10/
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachecassandra-036/
> > 
> > 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/M9Y5A (CHANGES.txt)
> > [2]: http://goo.gl/9xFe8 (NEWS.txt)
> > 
> 
> 
> 

Re: [VOTE] Release Apache Cassandra 1.1.1

[Pavel Yaskevich]

+1

On Saturday 2 June 2012 at 01:22, Brandon Williams wrote:

> +1
> 
> On Fri, Jun 1, 2012 at 1:21 PM, Sylvain Lebresne  (mailto:sylv...@datastax.com)> wrote:
> > We've have fixed tons of bugs since 1.1.0 and have nothing critical 
> > outstanding
> > so I propose the following artifacts for release as 1.1.1.
> > 
> > sha1: a788a23ca6fbb03f991a0c54325c371b4b1dd7cf
> > Git: 
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.1.1-tentative
> > Artifacts: 
> > https://repository.apache.org/content/repositories/orgapachecassandra-176/org/apache/cassandra/apache-cassandra/1.1.1/
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachecassandra-176/
> > 
> > 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/T2yfb (CHANGES.txt)
> > [2]: http://goo.gl/hP936 (NEWS.txt)
> > 
> 
> 
> 

Re: Cassandra in memory key index

[Pavel Yaskevich]

I would vote,  if possible, to compare it with y-fast trie [1] (it doesn't seem 
to be available java implementation unfortunately) by means of memory 
efficiency and lookup performance. As we use big integer tokens the main 
benefit from that trie could be O(log log M) predecessor lookup and compact 
in-memory size. 

[1] https://en.wikipedia.org/wiki/Y-fast_trie

Best Regards
-- 
Pavel Yaskevich


On Friday 8 June 2012 at 22:19, Jason Rutherglen wrote:

> Ok looks like the IndexSummary encapsulates everything, I can start with
> hacking that.
> 
> On Fri, Jun 8, 2012 at 11:50 AM, Jason Rutherglen <
> jason.rutherg...@gmail.com (mailto:jason.rutherg...@gmail.com)> wrote:
> 
> > The Cassandra integration is probably beyond the time I have available.
> > If the locations in the code that need to be rewritten to use the FST are
> > known, and a patch simply 'plugs-in' the FST, that would be much easier.
> > Eg, I don't know how Cassandra stores the current key index for example...
> > 
> > Basically I can write FST serializing, deserializing, and key lookup code
> > fairly easy by basing it on Lucene's terms dict.
> > 
> > 
> > On Fri, Jun 8, 2012 at 6:00 AM, Radim Kolar  > (mailto:h...@filez.com)> wrote:
> > 
> > > 
> > > If you are interested I can help, I used the FST on a Hadoop project
> > > > to implement a fast map side range join.
> > > 
> > > create JIRA item with patch attached, i will test it.
> > > 
> > 
> > 
> 
> 
> 

Re: Cassandra in memory key index

[Pavel Yaskevich]

Yeah, that is why I wrote "if possible" :) Also, does FST provide a predecessor 
lookup function, wasn't clear from the blog post?

On Friday 8 June 2012 at 22:53, Jason Rutherglen wrote:

> Yeah that's fine, however if there isn't a Java implementation that's a lot
> of extra work. The FST approach should be a clear quick and easy win. The
> current system of in heap keys and a binary search is what the FST replaced
> in Lucene. There are plenty of references to the improvement.
> 
> On Fri, Jun 8, 2012 at 3:50 PM, Pavel Yaskevich  (mailto:pove...@gmail.com)> wrote:
> 
> > I would vote, if possible, to compare it with y-fast trie [1] (it doesn't
> > seem to be available java implementation unfortunately) by means of memory
> > efficiency and lookup performance. As we use big integer tokens the main
> > benefit from that trie could be O(log log M) predecessor lookup and compact
> > in-memory size.
> > 
> > [1] https://en.wikipedia.org/wiki/Y-fast_trie
> > 
> > Best Regards
> > --
> > Pavel Yaskevich
> > 
> > 
> > On Friday 8 June 2012 at 22:19, Jason Rutherglen wrote:
> > 
> > > Ok looks like the IndexSummary encapsulates everything, I can start with
> > > hacking that.
> > > 
> > > On Fri, Jun 8, 2012 at 11:50 AM, Jason Rutherglen <
> > > jason.rutherg...@gmail.com (mailto:jason.rutherg...@gmail.com)> wrote:
> > > 
> > > > The Cassandra integration is probably beyond the time I have available.
> > > > If the locations in the code that need to be rewritten to use the FST
> > > > 
> > > 
> > > 
> > 
> > are
> > > > known, and a patch simply 'plugs-in' the FST, that would be much
> > > 
> > 
> > easier.
> > > > Eg, I don't know how Cassandra stores the current key index for
> > > 
> > 
> > example...
> > > > 
> > > > Basically I can write FST serializing, deserializing, and key lookup
> > code
> > > > fairly easy by basing it on Lucene's terms dict.
> > > > 
> > > > 
> > > > On Fri, Jun 8, 2012 at 6:00 AM, Radim Kolar  > > > (mailto:h...@filez.com) (mailto:
> > h...@filez.com (mailto:h...@filez.com))> wrote:
> > > > 
> > > > > 
> > > > > If you are interested I can help, I used the FST on a Hadoop project
> > > > > > to implement a fast map side range join.
> > > > > 
> > > > > 
> > > > > create JIRA item with patch attached, i will test it. 

Re: Cassandra jclouds/whirr test suite

[Pavel Yaskevich]

Hi Lewis,

   You can still find Whirr powered distributed tests in test/distributed 
directory of the cassandra-0.8 branch but it was removed from the later 
versions because we have moved to the distributed testing used ccm tool, new 
test suit could be found at https://github.com/riptano/cassandra-dtest.

Best Regards
--
Pavel Yaskevich


On Tuesday 12 June 2012 at 15:28, Lewis John Mcgibbney wrote:

> Good Afternoon dev@,
> 
> I resend this as I assume my first attempt didn't get through moderation.
> 
> I'm currently working on a Apache Gora GSoC project, the scope of
> which comprises a module to use Gora with Amazon DynamoDB. Some time
> ago I remember browsing over an excellent test suite for running
> Cassandra in the cloud using Whirr (I think). It was some time ago and
> now unfortunately I am unable to relocate the test suite... can anyone
> help me here?
> 
> We are looking to extend our current unit/integration tests for the
> GSoC project prior to writing the actual module and this Cassandra
> test suite would be an excellent resource if I can find it again.
> 
> Thanks very much in advance for any feedback or help anyone can provide.
> 
> Best
> 
> Lewis
> 
> 
> -- 
> Lewis
> 
> 

Re: Welcome David Capwell as Cassandra PMC Member!

[Pavel Yaskevich]

Congratulations, David!

On Mon, Apr 28, 2025 at 12:42 PM Maxim Muzafarov  wrote:

> Congratulations, David!
>
> On Mon, 28 Apr 2025 at 21:25, Ekaterina Dimitrova 
> wrote:
> >
> > Congrats!! 🍾 And thank you for everything you do for the project!
> >
> > On Mon, 28 Apr 2025 at 15:20, Yifan Cai  wrote:
> >>
> >> Congrats David!
> >>
> >> 
> >> From: Abe Ratnofsky 
> >> Sent: Monday, April 28, 2025 12:11:52 PM
> >> To: dev@cassandra.apache.org 
> >> Subject: Re: Welcome David Capwell as Cassandra PMC Member!
> >>
> >> Congrats David!
>