[
https://issues.apache.org/jira/browse/CASSANDRA-2064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-2064.
---------------------------------------
Resolution: Not A Problem
Note that more information is logged at DEBUG, but in general if you have a
single replica downtime should not be a surprise...
> When the target node is down and the replication factor is 1. Any batch
> mutate/read with consistency level QUORUM will fail to succeed.
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-2064
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2064
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Affects Versions: 0.7.0
> Reporter: Mikael Sitruk
>
> When the target node is down and the replication factor is 1. Any batch
> mutate or read (with consistency level QUORUM) will fail to succeed.
> This case occurs because the quorum cannot be verified.
> The storage proxy will write the data on its own log, but cannot assure the
> quorum (since the quorum definition requires the replica to respond) - the
> responseHandler.assureSufficientLiveNodes(); will throw UnavailableException.
> While it is OK to send an exception i think that the exception should contain
> an appropriate message - like consistency level: <Quorum>, replication
> factor: <replication factor> cannot be verified for key... (adding the
> natural and the hinted node should be nice too at least in the log). Perhaps
> a separate exception should be thrown (sub type of UnavailableException)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
