You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Mikael Sitruk (JIRA)" <ji...@apache.org> on 2011/01/27 15:20:43 UTC
[jira] Created: (CASSANDRA-2064) When the target node is down and
the replication factor is 1. Any batch mutate/read with consistency level
QUORUM will fail to succeed.
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.
-
You can reply to this email to add a comment to the issue online.
[jira] [Resolved] (CASSANDRA-2064) When the target node is down and
the replication factor is 1. Any batch mutate/read with consistency level
QUORUM will fail to succeed.
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ 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