[
https://issues.apache.org/jira/browse/CASSANDRA-11850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15388849#comment-15388849
]
Paulo Motta commented on CASSANDRA-11850:
-----------------------------------------
bq. During debugging I noticed that failed attempts were always sent to child
process no. 0. This change ensures that failed attempts are sent to the child
process following the one that failed.
ah OK, now it makes sense, thanks for the explanation!
bq. Thanks for the manual tests. Perhaps we can open a ticket to create a test
once byteman is integrated with dtests?
Sure, I created CASSANDRA-12272 for this matter and assigned to [~cassandra-te]
so it's not forgotten (hope it's OK [~philipthompson] :))
bq. OK, I think you've already removed the known failures in you commit. I will
close those tickets when we commit this.
The multiplexer 3 x 100 run looks good for
[trunk|https://cassci.datastax.com/view/Parameterized/job/parameterized_dtest_multiplexer/173/],
but on
[2.1|https://cassci.datastax.com/view/Parameterized/job/parameterized_dtest_multiplexer/177/]
there are a few test runs failing with {{21 Jul 2016 09:39:25 \[node1\]
Missing: \['127.0.0.2 is now \[dead|DOWN\]'\]:}}, but it seems to be some
environmental problem unrelated to this particular test so I guess we're safe
to remove the flaky annotations and close CASSANDRA-11999/CASSANDRA-10884.
Can you please include the excerpt below on your dtest PR to hopefully increase
resilience to this?
{noformat}
diff --git a/cqlsh_tests/cqlsh_tests.py b/cqlsh_tests/cqlsh_tests.py
index 721d81f..c9f03c8 100644
--- a/cqlsh_tests/cqlsh_tests.py
+++ b/cqlsh_tests/cqlsh_tests.py
@@ -1468,7 +1468,7 @@ Tracing session:""")
@jira_ticket CASSANDRA-9689
"""
self.cluster.populate(3)
- self.cluster.start(wait_for_binary_proto=True)
+ self.cluster.start(wait_for_binary_proto=True, wait_other_notice=True)
node1, node2, node3 = self.cluster.nodelist()
node2.stop(wait_other_notice=True)
{noformat}
bq. I've extracted the change and put it on a separate branch. Details are on
CASSANDRA-11979, I've put you as reviewer.
Sounds good, will follow-up there.
bq. Here are the up-to-date branches and latest tests results:
Final patch and test results look good. The only final nit is that I'm still a
bit unsure if this meets the critical requirement to go on 2.1 though, WDYT
[~Stefania]? In particular I'm not sure at which point we stop supporting
python upgrades. [~thobbs] Would you have any suggestion on this?
> cannot use cql since upgrading python to 2.7.11+
> ------------------------------------------------
>
> Key: CASSANDRA-11850
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11850
> 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 cannot.
> nodetool status also works.
> Thank you for your help.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
