Re: Nodes failed to bootstrap, no nodetool info but system.peer populated.

2015-05-11 Thread Carlos Rolo
Thanks! Regards, Carlos Juzarte Rolo Cassandra Consultant Pythian - Love your data rolo@pythian | Twitter: cjrolo | Linkedin: *linkedin.com/in/carlosjuzarterolo http://linkedin.com/in/carlosjuzarterolo* Mobile: +31 6 159 61 814 | Tel: +1 613 565 8696 x1649 www.pythian.com On Mon, May 11, 2015

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

2015-05-11 Thread Jonathan Ellis
On Sun, May 10, 2015 at 2:42 PM, Aleksey Yeschenko alek...@apache.org wrote: 3.0, however, will require a stabilisation period, just by the nature of it. It might seem like 2.2 and 3.0 are closer to each other than 2.1 and 2.2 are, if you go purely by the feature list, but in fact the opposite

Re: Wrap around CQL queries for token ranges?

2015-05-11 Thread Aleksey Yeschenko
That was an intentional decision on our side. Have a look at  https://issues.apache.org/jira/browse/CASSANDRA-5573 - Sylvain’s comment in particular. --  AY On May 11, 2015 at 20:05:54, Brian O'Neill (b...@alumni.brown.edu) wrote: Looks like the java-driver supplies the hack I need.

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

2015-05-11 Thread Alex Popescu
On Mon, May 11, 2015 at 1:32 PM, Aleksey Yeschenko alek...@apache.org wrote: The drivers, actually, aren’t ready at all for 3.0 with 8099, because 6717 will be pushed shortly after 8099, and break things. Apologies, I didn't mean they are ready today. Version-wise, renaming this proposed 2.2

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

2015-05-11 Thread Brian Hess
One thing that does jump out at me, though, is about CQL2. As much as we have advised against using cassandra-jdbc, I have encountered a few that actually have used that as an integration point. I believe that cassandra-jdbc is CQL2-based, which is the main reason we have been advising folks

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

2015-05-11 Thread Alex Popescu
On Mon, May 11, 2015 at 1:41 PM, Aleksey Yeschenko alek...@apache.org wrote: 3.0 to 2.2? Python and C# have already used 2.5 (I wouldn't have brought this up if I had other options). -- Bests, Alex Popescu | @al3xandru Sen. Product Manager @ DataStax

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

2015-05-11 Thread Jonathan Ellis
Sounds good. I will add the new version to Jira. Planned tickets to block 2.2 beta for: #8374 #8984 #9190 Any others? (If it's not code complete today we should not block for it.) On Mon, May 11, 2015 at 1:59 PM, Aleksey Yeschenko alek...@apache.org wrote: So I think EOLing 2.0.x when

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

2015-05-11 Thread Jeremiah Jordan
Cassandra-jdbc can do cql3 as well as cql2. The rub (and why I would never recommend it) is that it does cql3 over thrift. So you lose out on all the native protocol features. On May 11, 2015, at 2:53 PM, Brian Hess brianmh...@gmail.com wrote: One thing that does jump out at me, though,

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

2015-05-11 Thread Alex Popescu
On Sun, May 10, 2015 at 2:14 PM, Robert Stupp sn...@snazy.de wrote: Instead of labeling it 2.2, I’d like to propose to label it 3.0 (so basically just move 8099 to 3.1). In the end it’s ”only a label”. But there are a lot of new user-facing features in it that justifies a major release. +1

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

2015-05-11 Thread Jake Luciani
Overall +1. I'm -0 on EOL of 2.0 once 2.2 is release. I'd rather keep 2.0 around till 3.0 comes out. As for 2.2 blockers, we might want to vet and make sure everything we need in protocol v4 is finished before we release 2.2 https://issues.apache.org/jira/browse/CASSANDRA-8043 On Sat, May 9,

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

2015-05-11 Thread Jonathan Ellis
Unresolved issues tagged for 2.2b1: https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20AND%20fixVersion%20%3D%20%222.2%20beta%201%22%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC On Mon, May 11, 2015 at 2:42 PM, Jonathan

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

2015-05-11 Thread Brian Hess
Jeremiah - still need to worry about whether folks are doing CQL2 or CQL3 over cassandra-jdbc. If it is not in much use, that's fine by me. I just wanted to raise one place where folks might be using CQL2 without realizing it. On Mon, May 11, 2015 at 4:00 PM, Jeremiah Jordan

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

2015-05-11 Thread Jonathan Ellis
I do like 2.2 and 3.0 over 3.0 and 3.1 because going from 2.x to 3.x signals that 8099 really is a big change. On Mon, May 11, 2015 at 3:28 PM, Alex Popescu al...@datastax.com wrote: On Sun, May 10, 2015 at 2:14 PM, Robert Stupp sn...@snazy.de wrote: Instead of labeling it 2.2, I’d like to

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

2015-05-11 Thread Michael Kjellman
Last I checked — and I could be wrong — we’ve never had to think about what to number a Cassandra version due to a ticket that could “impact” our users so dramatically due to the scope of the changes from a single ticket. Food for thought. love, kjellman On May 11, 2015, at 2:20 PM, Alex

Re: Wrap around CQL queries for token ranges?

2015-05-11 Thread Brian O'Neill
Looks like the java-driver supplies the hack I need. (TokenRange.unwrap) I¹ll leave it to you guys to decide if it is more elegant to support wrapping natively in CQL. -brian --- Brian O'Neill Chief Technology Officer Health Market Science, a LexisNexis Company 215.588.6024 Mobile €

Wrap around CQL queries for token ranges?

2015-05-11 Thread Brian O'Neill
I was doing some testing around data locality today (and adding it to our distributed processing layer). I retrieved all of the TokenRanges back using: tokenRanges = metadata.getTokenRanges(keyspace, localhost) And when I spun through the token ranges returned, I ended up missing records. The

Re: Nodes failed to bootstrap, no nodetool info but system.peer populated.

2015-05-11 Thread Sebastian Estevez
I hit this issue today with the c# driver. I still think the drivers should handle peers inconsistencies better and maybe even output warnings about them. I opened CSHARP-296, @rolo, it's probably a good idea to open a similar one for java. On May 11, 2015 11:24 AM, Carlos Rolo r...@pythian.com