[ https://issues.apache.org/jira/browse/CASSANDRA-11317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15210570#comment-15210570 ]
Joel Knighton commented on CASSANDRA-11317: ------------------------------------------- [~yukim] It looks like this was "solved" by the backport of [CASSANDRA-10679] in [CASSANDRA-9598], since that put cassandra.yaml on the classpath so it can be loaded by client tools now. Is that a good enough fix, or should we still set Config.clientMode(true) for all the tools that explicitly init DatabaseDescriptor after [CASSANDRA-10412]. (This includes SSTableExpiredBlockers, SSTableExport, SSTableImport, SSTableLevelResetter, SSTableMetadataViewer, SSTableOfflineRelevel, SSTableRepairedAtSetter, StandaloneScrubber, StandaloneSplitter, StandaloneUpgrader, StandaloneVerifier). It looks like at least some of these were failing in the same way before [CASSANDRA-9598]. From my perspective (with limited experience here), it looks like the fact that this was fixed was accidental, and we don't want the client tools loading cassandra.yaml. > dtest failure in > repair_tests.incremental_repair_test.TestIncRepair.sstable_repairedset_test > -------------------------------------------------------------------------------------------- > > Key: CASSANDRA-11317 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11317 > Project: Cassandra > Issue Type: Bug > Reporter: Jim Witschey > Assignee: Joel Knighton > Labels: dtest > Fix For: 2.2.x > > > example failure: > http://cassci.datastax.com/job/cassandra-2.2_dtest/536/testReport/repair_tests.incremental_repair_test/TestIncRepair/sstable_repairedset_test > Here's the failure and stack trace: > {code} > [' 0'] > -------------------- >> begin captured logging << -------------------- > dtest: DEBUG: cluster ccm directory: /mnt/tmp/dtest-4WjpOf > dtest: DEBUG: Custom init_config not found. Setting defaults. > dtest: DEBUG: Done setting configuration options: > { 'initial_token': None, > 'num_tokens': '32', > 'phi_convict_threshold': 5, > 'start_rpc': 'true'} > dtest: DEBUG: Repair timestamps are: [' 0', ' 0'] > --------------------- >> end captured logging << --------------------- > Stacktrace > File "/usr/lib/python2.7/unittest/case.py", line 329, in run > testMethod() > File > "/home/automaton/cassandra-dtest/repair_tests/incremental_repair_test.py", > line 198, in sstable_repairedset_test > self.assertGreaterEqual(len(uniquematches), 2, uniquematches) > File "/usr/lib/python2.7/unittest/case.py", line 948, in assertGreaterEqual > self.fail(self._formatMessage(msg, standardMsg)) > File "/usr/lib/python2.7/unittest/case.py", line 410, in fail > raise self.failureException(msg) > "[' 0']\n-------------------- >> begin captured logging << > --------------------\ndtest: DEBUG: cluster ccm directory: > /mnt/tmp/dtest-4WjpOf\ndtest: DEBUG: Custom init_config not found. Setting > defaults.\ndtest: DEBUG: Done setting configuration options:\n{ > 'initial_token': None,\n 'num_tokens': '32',\n 'phi_convict_threshold': > 5,\n 'start_rpc': 'true'}\ndtest: DEBUG: Repair timestamps are: [' 0', ' > 0']\n--------------------- >> end captured logging << ---------------------" > {code} > This has failed in this way on CassCI build cassandra-2.2_dtest 536-9. > [~philipthompson] Could you have a first look at this? You had a recent look > at this test in CASSANDRA-11220. -- This message was sent by Atlassian JIRA (v6.3.4#6332)