cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Motta (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-11850) cannot use cql since upgrading python to 2.7.11+
Date Tue, 19 Jul 2016 22:55:20 GMT


Paulo Motta commented on CASSANDRA-11850:

Thanks for the patch and detailed explanation! Overall it looks good, see follow-up:
* The 2.1 patch looks, can you just update to use the 2.7.2 zip now that [#606|]
got in?
* Similarly, can you regenerate the 2.2+ cassandra-driver libs after [#617|]
was merged?
* I didn't get [this change|],
is this related to this patch? won't {{prev_worker_no=-1}} and thus {{i=0}} always?
* +1 to dtest and cdc-related changes (afaic)
* The original intent of {{test_refresh_schema_on_timeout_error}} on CASSANDRA-9689 was to
make sure a newly created keyspace/table will show up if there is a down node during the {{DDL}}
statement, but since down nodes no longer causes schema mismatches after [PYTHON-531|]
the schema mismatch assertions are no longer necessary (even though we still need to keep
the {{--request-timeout}} option on 2.1 dtest to avoid flakiness - see CASSANDRA-10686), so
I renamed the test to {{test_update_schema_with_down_node}}. Here is the [dtest branch|]
with these changes.
* I also added a [new commit|]
with the following changes:
** Refactor {{perform_simple_statement}} to always [try to reload the schema|]
if there's a mismatch in order to cover both CASSANDRA-9689 and CASSANDRA-10686.
** [Remove|]
the schema mismatch check on startup, since this is no longer necessary after [PYTHON-303|].
** Update the schema mismatch warning [message|]
* It would be nice to add a dtest to verify that the schema mismatch warning is being print
on a proper schema mismatch but I didn't find a simple way to induce a schema mismatch without
adding a special test flag on C* which is not an ideal solution. I tested manually by disabling
the {{schema_version}} update on the {{system.peers}} table, and the warning is being printed
correctly. We could probably achieve that easily with byteman but since that is not yet integrated
with dtests let's maybe leave it for another ticket.
* Submitted multiplexer 100x runs for [2.1|]
and [trunk|]
so we can remove the {{@known_failure}} annotations and close CASSANDRA-11999 and CASSANDRA-10884.
* It would be nice if you could maybe extract CASSANDRA-11979 to a separate commit to improve

Submitted tests with updates below:

> cannot use cql since upgrading python to 2.7.11+
> ------------------------------------------------
>                 Key: CASSANDRA-11850
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: CQL
>         Environment: Development
>            Reporter: Andrew Madison
>            Assignee: Stefania
>              Labels: cqlsh
>             Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x
> OS: Debian GNU/Linux stretch/sid 
> Kernel: 4.5.0-2-amd64 #1 SMP Debian 4.5.4-1 (2016-05-16) x86_64 GNU/Linux
> Python version: 2.7.11+ (default, May  9 2016, 15:54:33)
> [GCC 5.3.1 20160429]
> cqlsh --version: cqlsh 5.0.1
> cassandra -v: 3.5 (also occurs with 3.0.6)
> Issue:
> when running cqlsh, it returns the following error:
> cqlsh -u dbarpt_usr01
> Password: *****
> Connection error: ('Unable to connect to any servers', {'odbasandbox1': TypeError('ref()
does not take keyword arguments',)})
> I cleared PYTHONPATH:
> python -c "import json; print dir(json); print json.__version__"
> ['JSONDecoder', 'JSONEncoder', '__all__', '__author__', '__builtins__', '__doc__', '__file__',
'__name__', '__package__', '__path__', '__version__', '_default_decoder', '_default_encoder',
'decoder', 'dump', 'dumps', 'encoder', 'load', 'loads', 'scanner']
> 2.0.9
> Java based clients can connect to Cassandra with no issue. Just CQLSH and Python clients
> nodetool status also works.
> Thank you for your help.

This message was sent by Atlassian JIRA

View raw message