RE: Using quorum to read data

[Michael Vaknine]

Thank you for your reply
Do you know if there are documentation of hector I can read to understand this 
behavior?

Thanks
Michael


-Original Message-
From: sc...@scode.org [mailto:sc...@scode.org] On Behalf Of Peter Schuller
Sent: Monday, January 09, 2012 5:29 PM
To: dev@cassandra.apache.org
Subject: Re: Using quorum to read data

> 2012-01-09 11:58:33,325 WARN
> [me.prettyprint.cassandra.connection.CassandraHostRetryService] -  192.168.80.31(192.168.80.31):9160 host still appears to be down: Unable to
> open transport to 192.168.80.31(192.168.80.31):9160 ,
> java.net.ConnectException: Connection refused: connect>
>
> What am I missing?

That's not a timeout, but a failure to connect. Did you give Hector
all of the nodes in the cluster or enable auto-discovery? If the above
is the only error you see, it seems likely that you just need to
configure your client to talk to the entire cluster.

(I don't remember off hand how to tell hector to use auto-discovery.)

-- 
/ Peter Schuller (@scode, http://worldmodscode.wordpress.com)

Re: Using quorum to read data

[Jérémy SEVELLEC]

Hi,

I think it's what you need :

http://rantav.github.com/hector/build/html/content/services.html


Jérémy

2012/1/10 Michael Vaknine 

> Thank you for your reply
> Do you know if there are documentation of hector I can read to understand
> this behavior?
>
> Thanks
> Michael
>
>
> -Original Message-
> From: sc...@scode.org [mailto:sc...@scode.org] On Behalf Of Peter Schuller
> Sent: Monday, January 09, 2012 5:29 PM
> To: dev@cassandra.apache.org
> Subject: Re: Using quorum to read data
>
> > 2012-01-09 11:58:33,325 WARN
> > [me.prettyprint.cassandra.connection.CassandraHostRetryService] -  > 192.168.80.31(192.168.80.31):9160 host still appears to be down: Unable
> to
> > open transport to 192.168.80.31(192.168.80.31):9160 ,
> > java.net.ConnectException: Connection refused: connect>
> >
> > What am I missing?
>
> That's not a timeout, but a failure to connect. Did you give Hector
> all of the nodes in the cluster or enable auto-discovery? If the above
> is the only error you see, it seems likely that you just need to
> configure your client to talk to the entire cluster.
>
> (I don't remember off hand how to tell hector to use auto-discovery.)
>
> --
> / Peter Schuller (@scode, http://worldmodscode.wordpress.com)
>
>


-- 
Jérémy

Fwd: [1/4] git commit: note that using KEY instead of the defined key_alias has been removed

[Eric Evans]

This is a breaking change, isn't it?  Are we breaking the language and
updating the CQL major *again*?


-- Forwarded message --
From:  
Date: Tue, Jan 10, 2012 at 2:01 PM
Subject: [1/4] git commit: note that using KEY instead of the defined
key_alias has been removed
To: comm...@cassandra.apache.org


Updated Branches:
 refs/heads/cassandra-1.0 044eb1ede -> e2231a197
 refs/heads/trunk a3f2e9c3b -> d48a6c14f


note that using KEY instead of the defined key_alias has been removed


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/d48a6c14
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/d48a6c14
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/d48a6c14

Branch: refs/heads/trunk
Commit: d48a6c14f370dfe97eb4e45c567ea9d1923914c6
Parents: d371edf
Author: Jonathan Ellis 
Authored: Tue Jan 10 12:56:23 2012 -0600
Committer: Jonathan Ellis 
Committed: Tue Jan 10 12:56:23 2012 -0600

--
 NEWS.txt                                           |    5 +
 src/java/org/apache/cassandra/cql/WhereClause.java |    4 +---
 2 files changed, 6 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/d48a6c14/NEWS.txt
--
diff --git a/NEWS.txt b/NEWS.txt
index 24039e6..868ff73 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -39,6 +39,11 @@ Upgrading
    - Hadoop input and output details are now separated.  If you were
      previously using methods such as getRpcPort you now need to use
      getInputRpcPort or getOutputRpcPort depending on the circumstance.
+    - CQL changes:
+      + Prior to 1.1, you could use KEY as the primary key name in some
+        select statements, even if the PK was actually given a different
+        name.  In 1.1+ you must use the defined PK name.
+

 Features
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/d48a6c14/src/java/org/apache/cassandra/cql/WhereClause.java
--
diff --git a/src/java/org/apache/cassandra/cql/WhereClause.java
b/src/java/org/apache/cassandra/cql/WhereClause.java
index 13e27e9..0007c98 100644
--- a/src/java/org/apache/cassandra/cql/WhereClause.java
+++ b/src/java/org/apache/cassandra/cql/WhereClause.java
@@ -160,7 +160,7 @@ public class WhereClause
        for (Relation relation : clauseRelations)
        {
            String name = relation.getEntity().getText().toUpperCase();
-            if (name.equals(realKeyAlias) || name.equals("KEY"))
+            if (name.equals(realKeyAlias))
            {
                if (keyAlias == null) // setting found key as an alias
                    keyAlias = name;
@@ -199,6 +199,4 @@ public class WhereClause
                             multiKey,
                             keyAlias);
    }
-
-
 }



-- 
Eric Evans
Acunu | http://www.acunu.com | @acunu

Re: [1/4] git commit: note that using KEY instead of the defined key_alias has been removed

[Jonathan Ellis]

Pedantic answer: yes, hence the NEWS entry

More accurate answer: we've fixed a bug that allowed nonsense queries

Long answer: we started off requiring the C* row key, aka PRIMARY KEY
in CQL DDL, to be named "key."  We fixed that in 0.8.1, and required
that SELECT statements use the actual PK name in most situations.
However, we missed the range scan case (WHERE key > X), which
continued to allow "key" even when that was not the PK name.  The
breaking change then for 1.1 was to bring that in line with other
SELECT forms by requiring the actual PK name be used.

On Tue, Jan 10, 2012 at 2:11 PM, Eric Evans  wrote:
> This is a breaking change, isn't it?  Are we breaking the language and
> updating the CQL major *again*?
>
>
> -- Forwarded message --
> From:  
> Date: Tue, Jan 10, 2012 at 2:01 PM
> Subject: [1/4] git commit: note that using KEY instead of the defined
> key_alias has been removed
> To: comm...@cassandra.apache.org
>
>
> Updated Branches:
>  refs/heads/cassandra-1.0 044eb1ede -> e2231a197
>  refs/heads/trunk a3f2e9c3b -> d48a6c14f
>
>
> note that using KEY instead of the defined key_alias has been removed
>
>
> Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
> Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/d48a6c14
> Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/d48a6c14
> Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/d48a6c14
>
> Branch: refs/heads/trunk
> Commit: d48a6c14f370dfe97eb4e45c567ea9d1923914c6
> Parents: d371edf
> Author: Jonathan Ellis 
> Authored: Tue Jan 10 12:56:23 2012 -0600
> Committer: Jonathan Ellis 
> Committed: Tue Jan 10 12:56:23 2012 -0600
>
> --
>  NEWS.txt                                           |    5 +
>  src/java/org/apache/cassandra/cql/WhereClause.java |    4 +---
>  2 files changed, 6 insertions(+), 3 deletions(-)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/cassandra/blob/d48a6c14/NEWS.txt
> --
> diff --git a/NEWS.txt b/NEWS.txt
> index 24039e6..868ff73 100644
> --- a/NEWS.txt
> +++ b/NEWS.txt
> @@ -39,6 +39,11 @@ Upgrading
>     - Hadoop input and output details are now separated.  If you were
>       previously using methods such as getRpcPort you now need to use
>       getInputRpcPort or getOutputRpcPort depending on the circumstance.
> +    - CQL changes:
> +      + Prior to 1.1, you could use KEY as the primary key name in some
> +        select statements, even if the PK was actually given a different
> +        name.  In 1.1+ you must use the defined PK name.
> +
>
>  Features
>  
>
> http://git-wip-us.apache.org/repos/asf/cassandra/blob/d48a6c14/src/java/org/apache/cassandra/cql/WhereClause.java
> --
> diff --git a/src/java/org/apache/cassandra/cql/WhereClause.java
> b/src/java/org/apache/cassandra/cql/WhereClause.java
> index 13e27e9..0007c98 100644
> --- a/src/java/org/apache/cassandra/cql/WhereClause.java
> +++ b/src/java/org/apache/cassandra/cql/WhereClause.java
> @@ -160,7 +160,7 @@ public class WhereClause
>         for (Relation relation : clauseRelations)
>         {
>             String name = relation.getEntity().getText().toUpperCase();
> -            if (name.equals(realKeyAlias) || name.equals("KEY"))
> +            if (name.equals(realKeyAlias))
>             {
>                 if (keyAlias == null) // setting found key as an alias
>                     keyAlias = name;
> @@ -199,6 +199,4 @@ public class WhereClause
>                              multiKey,
>                              keyAlias);
>     }
> -
> -
>  }
>
>
>
> --
> Eric Evans
> Acunu | http://www.acunu.com | @acunu



-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com

Re: [1/4] git commit: note that using KEY instead of the defined key_alias has been removed

[Eric Evans]

On Tue, Jan 10, 2012 at 2:45 PM, Jonathan Ellis  wrote:
> Pedantic answer: yes, hence the NEWS entry
>
> More accurate answer: we've fixed a bug that allowed nonsense queries
>
> Long answer: we started off requiring the C* row key, aka PRIMARY KEY
> in CQL DDL, to be named "key."  We fixed that in 0.8.1, and required
> that SELECT statements use the actual PK name in most situations.
> However, we missed the range scan case (WHERE key > X), which
> continued to allow "key" even when that was not the PK name.  The
> breaking change then for 1.1 was to bring that in line with other
> SELECT forms by requiring the actual PK name be used.

How do users that created schemas before named keys fit in?  Or are
you saying that we had already broken them?

> On Tue, Jan 10, 2012 at 2:11 PM, Eric Evans  wrote:
>> This is a breaking change, isn't it?  Are we breaking the language and
>> updating the CQL major *again*?
>>
>>
>> -- Forwarded message --
>> From:  
>> Date: Tue, Jan 10, 2012 at 2:01 PM
>> Subject: [1/4] git commit: note that using KEY instead of the defined
>> key_alias has been removed
>> To: comm...@cassandra.apache.org
>>
>>
>> Updated Branches:
>>  refs/heads/cassandra-1.0 044eb1ede -> e2231a197
>>  refs/heads/trunk a3f2e9c3b -> d48a6c14f
>>
>>
>> note that using KEY instead of the defined key_alias has been removed
>>
>>
>> Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
>> Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/d48a6c14
>> Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/d48a6c14
>> Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/d48a6c14
>>
>> Branch: refs/heads/trunk
>> Commit: d48a6c14f370dfe97eb4e45c567ea9d1923914c6
>> Parents: d371edf
>> Author: Jonathan Ellis 
>> Authored: Tue Jan 10 12:56:23 2012 -0600
>> Committer: Jonathan Ellis 
>> Committed: Tue Jan 10 12:56:23 2012 -0600
>>
>> --
>>  NEWS.txt                                           |    5 +
>>  src/java/org/apache/cassandra/cql/WhereClause.java |    4 +---
>>  2 files changed, 6 insertions(+), 3 deletions(-)
>> --
>>
>>
>> http://git-wip-us.apache.org/repos/asf/cassandra/blob/d48a6c14/NEWS.txt
>> --
>> diff --git a/NEWS.txt b/NEWS.txt
>> index 24039e6..868ff73 100644
>> --- a/NEWS.txt
>> +++ b/NEWS.txt
>> @@ -39,6 +39,11 @@ Upgrading
>>     - Hadoop input and output details are now separated.  If you were
>>       previously using methods such as getRpcPort you now need to use
>>       getInputRpcPort or getOutputRpcPort depending on the circumstance.
>> +    - CQL changes:
>> +      + Prior to 1.1, you could use KEY as the primary key name in some
>> +        select statements, even if the PK was actually given a different
>> +        name.  In 1.1+ you must use the defined PK name.
>> +
>>
>>  Features
>>  
>>
>> http://git-wip-us.apache.org/repos/asf/cassandra/blob/d48a6c14/src/java/org/apache/cassandra/cql/WhereClause.java
>> --
>> diff --git a/src/java/org/apache/cassandra/cql/WhereClause.java
>> b/src/java/org/apache/cassandra/cql/WhereClause.java
>> index 13e27e9..0007c98 100644
>> --- a/src/java/org/apache/cassandra/cql/WhereClause.java
>> +++ b/src/java/org/apache/cassandra/cql/WhereClause.java
>> @@ -160,7 +160,7 @@ public class WhereClause
>>         for (Relation relation : clauseRelations)
>>         {
>>             String name = relation.getEntity().getText().toUpperCase();
>> -            if (name.equals(realKeyAlias) || name.equals("KEY"))
>> +            if (name.equals(realKeyAlias))
>>             {
>>                 if (keyAlias == null) // setting found key as an alias
>>                     keyAlias = name;
>> @@ -199,6 +199,4 @@ public class WhereClause
>>                              multiKey,
>>                              keyAlias);
>>     }
>> -
>> -
>>  }
>>
>>
>>
>> --
>> Eric Evans
>> Acunu | http://www.acunu.com | @acunu
>
>
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder of DataStax, the source for professional Cassandra support
> http://www.datastax.com



-- 
Eric Evans
Acunu | http://www.acunu.com | @acunu

Re: 1.1 freeze approaching

[Jonathan Ellis]

I've tagged 7 tickets as "critical" [1] for 1.1.  All of them deal
with CQL; I strongly believe that 1.1 needs to be where CQL goes from
being "the future" to being "the present."  We've been promising this
for almost a year now and it's time to deliver.

All of these (with the exception of 3707, which is relatively quick)
are in progress, and some (2475, 1391) are almost complete, but I
don't think we're going to get all of them done by the 18th.

Thus, I'd like to propopose postponing the freeze one more week, until the 25th.

[1] 
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+CASSANDRA+AND+fixVersion+%3D+%221.1%22+AND+resolution+%3D+Unresolved+ORDER+BY+due+ASC%2C+priority+DESC%2C+created+ASC

On Mon, Dec 19, 2011 at 11:56 AM, Jonathan Ellis  wrote:
> Just a reminder that for us to meet our four-month major release
> schedule (i.e., 1.1 = Feb 18), we need to code freeze on Jan 18, which
> is just about a month away on the calendar but significantly closer in
> terms of man-hours as people take holiday vacations.
>
> I've taken a first stab at moving issues to 1.2 that were tagged 1.1
> but I'm pretty sure won't be done in time, with 34 issues remaining in
> 1.1, which is fairly optimistic [1].  Please be aware of the timeline
> if you are working on or reviewing one of these tickets, or if you are
> planning to volunteer for one before the freeze.
>
> [1] 
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+CASSANDRA+AND+fixVersion+%3D+%221.1%22+AND+resolution+%3D+Unresolved+ORDER+BY+due+ASC%2C+priority+DESC%2C+created+ASC&mode=hide
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder of DataStax, the source for professional Cassandra support
> http://www.datastax.com



-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com

Re: [1/4] git commit: note that using KEY instead of the defined key_alias has been removed

[Jonathan Ellis]

Those were grandfathered in back in the day by CFMetaData.getKeyName
simply returning KEY in that case.

So if you have no key_alias defined, or it was defined to KEY, nothing
changes.  But if you did define PK to be something else, then you need
to use that PK name in your queries.  (Which, again, was already the
case except we missed range scans.)

On Tue, Jan 10, 2012 at 2:58 PM, Eric Evans  wrote:
> On Tue, Jan 10, 2012 at 2:45 PM, Jonathan Ellis  wrote:
>> Pedantic answer: yes, hence the NEWS entry
>>
>> More accurate answer: we've fixed a bug that allowed nonsense queries
>>
>> Long answer: we started off requiring the C* row key, aka PRIMARY KEY
>> in CQL DDL, to be named "key."  We fixed that in 0.8.1, and required
>> that SELECT statements use the actual PK name in most situations.
>> However, we missed the range scan case (WHERE key > X), which
>> continued to allow "key" even when that was not the PK name.  The
>> breaking change then for 1.1 was to bring that in line with other
>> SELECT forms by requiring the actual PK name be used.
>
> How do users that created schemas before named keys fit in?  Or are
> you saying that we had already broken them?
>
>> On Tue, Jan 10, 2012 at 2:11 PM, Eric Evans  wrote:
>>> This is a breaking change, isn't it?  Are we breaking the language and
>>> updating the CQL major *again*?
>>>
>>>
>>> -- Forwarded message --
>>> From:  
>>> Date: Tue, Jan 10, 2012 at 2:01 PM
>>> Subject: [1/4] git commit: note that using KEY instead of the defined
>>> key_alias has been removed
>>> To: comm...@cassandra.apache.org
>>>
>>>
>>> Updated Branches:
>>>  refs/heads/cassandra-1.0 044eb1ede -> e2231a197
>>>  refs/heads/trunk a3f2e9c3b -> d48a6c14f
>>>
>>>
>>> note that using KEY instead of the defined key_alias has been removed
>>>
>>>
>>> Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
>>> Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/d48a6c14
>>> Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/d48a6c14
>>> Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/d48a6c14
>>>
>>> Branch: refs/heads/trunk
>>> Commit: d48a6c14f370dfe97eb4e45c567ea9d1923914c6
>>> Parents: d371edf
>>> Author: Jonathan Ellis 
>>> Authored: Tue Jan 10 12:56:23 2012 -0600
>>> Committer: Jonathan Ellis 
>>> Committed: Tue Jan 10 12:56:23 2012 -0600
>>>
>>> --
>>>  NEWS.txt                                           |    5 +
>>>  src/java/org/apache/cassandra/cql/WhereClause.java |    4 +---
>>>  2 files changed, 6 insertions(+), 3 deletions(-)
>>> --
>>>
>>>
>>> http://git-wip-us.apache.org/repos/asf/cassandra/blob/d48a6c14/NEWS.txt
>>> --
>>> diff --git a/NEWS.txt b/NEWS.txt
>>> index 24039e6..868ff73 100644
>>> --- a/NEWS.txt
>>> +++ b/NEWS.txt
>>> @@ -39,6 +39,11 @@ Upgrading
>>>     - Hadoop input and output details are now separated.  If you were
>>>       previously using methods such as getRpcPort you now need to use
>>>       getInputRpcPort or getOutputRpcPort depending on the circumstance.
>>> +    - CQL changes:
>>> +      + Prior to 1.1, you could use KEY as the primary key name in some
>>> +        select statements, even if the PK was actually given a different
>>> +        name.  In 1.1+ you must use the defined PK name.
>>> +
>>>
>>>  Features
>>>  
>>>
>>> http://git-wip-us.apache.org/repos/asf/cassandra/blob/d48a6c14/src/java/org/apache/cassandra/cql/WhereClause.java
>>> --
>>> diff --git a/src/java/org/apache/cassandra/cql/WhereClause.java
>>> b/src/java/org/apache/cassandra/cql/WhereClause.java
>>> index 13e27e9..0007c98 100644
>>> --- a/src/java/org/apache/cassandra/cql/WhereClause.java
>>> +++ b/src/java/org/apache/cassandra/cql/WhereClause.java
>>> @@ -160,7 +160,7 @@ public class WhereClause
>>>         for (Relation relation : clauseRelations)
>>>         {
>>>             String name = relation.getEntity().getText().toUpperCase();
>>> -            if (name.equals(realKeyAlias) || name.equals("KEY"))
>>> +            if (name.equals(realKeyAlias))
>>>             {
>>>                 if (keyAlias == null) // setting found key as an alias
>>>                     keyAlias = name;
>>> @@ -199,6 +199,4 @@ public class WhereClause
>>>                              multiKey,
>>>                              keyAlias);
>>>     }
>>> -
>>> -
>>>  }
>>>
>>>
>>>
>>> --
>>> Eric Evans
>>> Acunu | http://www.acunu.com | @acunu
>>
>>
>>
>> --
>> Jonathan Ellis
>> Project Chair, Apache Cassandra
>> co-founder of DataStax, the source for professional Cassandra support
>> http://www.datastax.com
>
>
>
> --
> Eric Evans
> Acunu | http://www.acunu.com | @acunu



-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for pr

Re: [1/4] git commit: note that using KEY instead of the defined key_alias has been removed

[Eric Evans]

On Tue, Jan 10, 2012 at 3:03 PM, Jonathan Ellis  wrote:
> Those were grandfathered in back in the day by CFMetaData.getKeyName
> simply returning KEY in that case.
>
> So if you have no key_alias defined, or it was defined to KEY, nothing
> changes.  But if you did define PK to be something else, then you need
> to use that PK name in your queries.  (Which, again, was already the
> case except we missed range scans.)

I got it now, thanks; Sorry for the noise.

-- 
Eric Evans
Acunu | http://www.acunu.com | @acunu

Re: 1.1 freeze approaching

[Eric Evans]

On Tue, Jan 10, 2012 at 2:59 PM, Jonathan Ellis  wrote:
> I've tagged 7 tickets as "critical" [1] for 1.1.  All of them deal
> with CQL; I strongly believe that 1.1 needs to be where CQL goes from
> being "the future" to being "the present."  We've been promising this
> for almost a year now and it's time to deliver.
>
> All of these (with the exception of 3707, which is relatively quick)
> are in progress, and some (2475, 1391) are almost complete, but I
> don't think we're going to get all of them done by the 18th.
>
> Thus, I'd like to propopose postponing the freeze one more week, until the 
> 25th.

I think that would be for the best, +1

-- 
Eric Evans
Acunu | http://www.acunu.com | @acunu

Re: 1.1 freeze approaching

[Brandon Williams]

On Tue, Jan 10, 2012 at 2:59 PM, Jonathan Ellis  wrote:
> I've tagged 7 tickets as "critical" [1] for 1.1.  All of them deal
> with CQL;

Actually 1391 doesn't, but is quite important nonetheless.

> All of these (with the exception of 3707, which is relatively quick)
> are in progress, and some (2475, 1391) are almost complete, but I
> don't think we're going to get all of them done by the 18th.
>
> Thus, I'd like to propopose postponing the freeze one more week, until the 
> 25th.

+1

-Brandon

Re: 1.1 freeze approaching

[Jonathan Ellis]

On Tue, Jan 10, 2012 at 3:59 PM, Brandon Williams  wrote:
> On Tue, Jan 10, 2012 at 2:59 PM, Jonathan Ellis  wrote:
>> I've tagged 7 tickets as "critical" [1] for 1.1.  All of them deal
>> with CQL;
>
> Actually 1391 doesn't, but is quite important nonetheless.

The connection there is that if it works as planned, we get
CASSANDRA-2477 for free.

-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com

FYI Cassandra Git Repo on Apache servers

[Dave Brosius]

Greetings,

   I wanted to mention this to folks who may be running into this 
issue. A user on IRC reporting that cloning the cassandra repo on the 
apache servers


http://git-wip-us.apache.org/repos/asf/cassandra.git

fails with error

error: RPC failed; result=22, HTTP code = 417

Obviously most folks do not have this issue.

417 is a server's response to a request that includes an expectation 
header specifying level of service that the server can not fulfill.


After some discover it looks as if the user in question was effected by 
squid  and that was 
injecting the expect header, based on the output from curl -v 
http://git-wip-us.apache.org/repos/asf/cassandra.git


Clones from github for him do not fail, which I infer to mean that the 
github servers are more modern than the apache ones.


Not sure if there is anything that can be done in the apache 
infrastructure to address this.


dave

Re: 1.1 freeze approaching

[Sylvain Lebresne]

+1

On Tue, Jan 10, 2012 at 11:30 PM, Jonathan Ellis  wrote:
> On Tue, Jan 10, 2012 at 3:59 PM, Brandon Williams  wrote:
>> On Tue, Jan 10, 2012 at 2:59 PM, Jonathan Ellis  wrote:
>>> I've tagged 7 tickets as "critical" [1] for 1.1.  All of them deal
>>> with CQL;
>>
>> Actually 1391 doesn't, but is quite important nonetheless.
>
> The connection there is that if it works as planned, we get
> CASSANDRA-2477 for free.
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder of DataStax, the source for professional Cassandra support
> http://www.datastax.com