[
https://issues.apache.org/jira/browse/CASSANDRA-9369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14550567#comment-14550567
]
Michael Shuler edited comment on CASSANDRA-9369 at 5/19/15 2:56 PM:
--------------------------------------------------------------------
Speaking for myself and my own workflow, the only way to see what tests are
failing is to run them continually in CI. CI is the tool I am using to track
the tests that are failing repeatedly, intermittently failing, or blowing up
everything. If they are hidden from my view and I don't see them fail in CI,
then they don't get brought to my attention. I volunteered to track the testing
to try to get to the goal of 100% passing, and I found this particular ticket
from a git commit message that caught my attention - not from the tool I am
using to track the state of testing, which is where I would like it.
As an example of the problem I have with disabling tests with {{@require}}, I
just now removed this disabling for CASSANDRA-8049 CASSANDRA-9300 and
CASSANDRA-9194 - the committers of those may or may not have known these dtests
were disabled, I don't know.
So I understand your point, but I would kindly request that you leave failing
tests to fail in CI. It is much easier for me to help with tracking the state
of tests.
was (Author: mshuler):
Speaking for myself and my own workflow, the only way to see what tests are
failing is to run them continually in CI. CI is the tool I am using to track
the tests that are failing repeatedly, intermittently failing, or blowing up
everything. If they are hidden from my view and I don't see them fail in CI,
then they don't get brought to my attention. I volunteered to track the testing
to try to get to the goal of 100% passing, and I found this particular ticket
from a git commit message that caught my attention - not from the tool I am
using to track the state of testing, which is where I would like it.
As an example of the problem I have with disabling tests with {{@require}}, I
just now removed this disabling for CASSANDRA-8049 CASSANDRA-9300 and
CASSANDRA-9294 - the committers of those may or may not have known these dtests
were disabled, I don't know.
So I understand your point, but I would kindly request that you leave failing
tests to fail in CI. It is much easier for me to help with tracking the state
of tests.
> HSHA dtest for closing connections is failing on trunk
> ------------------------------------------------------
>
> Key: CASSANDRA-9369
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9369
> Project: Cassandra
> Issue Type: Test
> Components: Tests
> Reporter: Tyler Hobbs
> Assignee: Ariel Weisberg
> Fix For: 2.2.x
>
>
> The {{thrift_hsha_test.ThriftHSHATest.test_closing_connections}} dtest is
> failing against trunk (but not against 2.1). Here's an example failure:
> {noformat}
> Error Message
> There are non-closed connections: COMMAND PID USER FD TYPE DEVICE
> SIZE/OFF NODE NAME
> java 28202 automaton 7u IPv4 60767 0t0 TCP
> localhost:58436->localhost:9160 (CLOSE_WAIT)
> -------------------- >> begin captured logging << --------------------
> dtest: DEBUG: cluster ccm directory: /tmp/dtest-U0pP7H
> dtest: DEBUG: Creating connection pools..
> dtest: DEBUG: Disabling/Enabling thrift iteration #0
> dtest: DEBUG: Closing connections from the client side..
> pycassa.pool: INFO: Pool 139721997822224 was disposed
> pycassa.pool: INFO: Pool 139721997714512 was disposed
> pycassa.pool: INFO: Pool 139721997749904 was disposed
> --------------------- >> end captured logging << ---------------------
> Stacktrace
> File "/usr/lib/python2.7/unittest/case.py", line 331, in run
> testMethod()
> File "/home/automaton/cassandra-dtest/thrift_hsha_test.py", line 59, in
> test_closing_connections
> self.assertEqual(len(lines), 0, "There are non-closed connections: %s" %
> stdout)
> File "/usr/lib/python2.7/unittest/case.py", line 515, in assertEqual
> assertion_func(first, second, msg=msg)
> File "/usr/lib/python2.7/unittest/case.py", line 508, in _baseAssertEqual
> raise self.failureException(msg)
> 'There are non-closed connections: COMMAND PID USER FD TYPE DEVICE
> SIZE/OFF NODE NAME\njava 28202 automaton 7u IPv4 60767 0t0 TCP
> localhost:58436->localhost:9160 (CLOSE_WAIT)\n\n-------------------- >> begin
> captured logging << --------------------\ndtest: DEBUG: cluster ccm
> directory: /tmp/dtest-U0pP7H\ndtest: DEBUG: Creating connection
> pools..\ndtest: DEBUG: Disabling/Enabling thrift iteration #0\ndtest: DEBUG:
> Closing connections from the client side..\npycassa.pool: INFO: Pool
> 139721997822224 was disposed\npycassa.pool: INFO: Pool 139721997714512 was
> disposed\npycassa.pool: INFO: Pool 139721997749904 was
> disposed\n--------------------- >> end captured logging <<
> ---------------------'
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
