Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id F0FFB200C3F for ; Wed, 8 Mar 2017 00:52:44 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id EF874160B74; Tue, 7 Mar 2017 23:52:44 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 45B5F160B68 for ; Wed, 8 Mar 2017 00:52:44 +0100 (CET) Received: (qmail 14617 invoked by uid 500); 7 Mar 2017 23:52:43 -0000 Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cassandra.apache.org Delivered-To: mailing list commits@cassandra.apache.org Received: (qmail 14606 invoked by uid 99); 7 Mar 2017 23:52:43 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 Mar 2017 23:52:43 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id E3A30C320B for ; Tue, 7 Mar 2017 23:52:42 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.652 X-Spam-Level: X-Spam-Status: No, score=0.652 tagged_above=-999 required=6.31 tests=[RP_MATCHES_RCVD=-0.001, SPF_NEUTRAL=0.652, URIBL_BLOCKED=0.001] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id thQBY9IsixfI for ; Tue, 7 Mar 2017 23:52:41 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTP id 36B025F1F4 for ; Tue, 7 Mar 2017 23:52:41 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 6DE57E0041 for ; Tue, 7 Mar 2017 23:52:38 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id EC7B224162 for ; Tue, 7 Mar 2017 23:52:37 +0000 (UTC) Date: Tue, 7 Mar 2017 23:52:37 +0000 (UTC) From: "Matt Byrd (JIRA)" To: commits@cassandra.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Created] (CASSANDRA-13307) The specification of protocol version in cqlsh means the python driver doesn't automatically downgrade protocol version. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Tue, 07 Mar 2017 23:52:45 -0000 Matt Byrd created CASSANDRA-13307: ------------------------------------- Summary: The specification of protocol version in cqlsh means the python driver doesn't automatically downgrade protocol version. Key: CASSANDRA-13307 URL: https://issues.apache.org/jira/browse/CASSANDRA-13307 Project: Cassandra Issue Type: Bug Components: Tools Reporter: Matt Byrd Assignee: Matt Byrd Priority: Minor Hi, Looks like we've regressed on the issue described in: https://issues.apache.org/jira/browse/CASSANDRA-9467 In that we're no longer able to connect from newer cqlsh versions (e.g trunk) to older versions of Cassandra with a lower version of the protocol (e.g 2.1 with protocol version 3) The problem seems to be that we're relying on the ability for the client to automatically downgrade protocol version implemented in Cassandra here: https://issues.apache.org/jira/browse/CASSANDRA-12838 and utilised in the python client here: https://datastax-oss.atlassian.net/browse/PYTHON-240 The problem however comes when we implemented: https://datastax-oss.atlassian.net/browse/PYTHON-537 "Don't downgrade protocol version if explicitly set" (included when we bumped from 3.5.0 to 3.7.0 of the python driver as part of fixing: https://issues.apache.org/jira/browse/CASSANDRA-11534) Since we do explicitly specify the protocol version in the bin/cqlsh.py. I've got a patch which just adds an option to explicitly specify the protocol version (for those who want to do that) and then otherwise defaults to not setting the protocol version, i.e using the protocol version from the client which we ship, which should by default be the same protocol as the server. Then it should downgrade gracefully as was intended. Let me know if that seems reasonable. Thanks, Matt -- This message was sent by Atlassian JIRA (v6.3.15#6346)