cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brandon Williams (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-6558) Failure Detector takes 4-5x longer than it used to
Date Wed, 08 Jan 2014 15:05:53 GMT


Brandon Williams commented on CASSANDRA-6558:

bq. Just so there is no misunderstanding, the java driver does not use the FD code client
side. It's just that there is whole family of tests in which you test behaviors that only
apply when a dead node has been detected as such by other nodes, and so such tests will kill
a node and then wait for the FD to kick in

If the shutdown is clean, why isn't CASSANDRA-3936 saving us? Or does the shutdown need to
be unclean to test some behavior?

bq. Maybe we can just add some startup variable to set the initial FD interval

That would be CASSANDRA-4375, I'll try to get to that today.

> Failure Detector takes 4-5x longer than it used to
> --------------------------------------------------
>                 Key: CASSANDRA-6558
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Joaquin Casares
>            Priority: Minor
>              Labels: datastax_qa
> The Failure Detector appears to also be used by the java-driver (
in determining if nodes are down or not. Because of the recent increase in time that it takes
for Cassandra to noticed downed nodes, tests within the java-driver integration suite are
currently failing.
> This should only impact driver usage minimally since it also relies on failed requests
to find out if a node is down, but fixing the issue means we get the tests back online and
the Failure Detector working as it previously had been.

This message was sent by Atlassian JIRA

View raw message