Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 5 Feb 2015 14:10:34 +0000 (UTC)
From: "Stefan Podkowinski (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12772697.1423145410000.266169.1423145434423@Atlassian.JIRA>
In-Reply-To: <JIRA.12772697.1423145410000@Atlassian.JIRA>
References: <JIRA.12772697.1423145410000@Atlassian.JIRA>
 <JIRA.12772697.1423145410078@arcas>
Subject: [jira] [Created] (CASSANDRA-8745) Ambiguous WriteTimeoutException
 during atomic batch execution
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Stefan Podkowinski created CASSANDRA-8745:
---------------------------------------------

             Summary: Ambiguous WriteTimeoutException during atomic batch execution
                 Key: CASSANDRA-8745
                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8745
             Project: Cassandra
          Issue Type: Bug
          Components: Core
         Environment: 2.1.x
            Reporter: Stefan Podkowinski


StorageProxy will handle atomic batches in mutateAtomically() the following way:
* syncWriteToBatchlog() <- WriteTimeoutException
* syncWriteBatchedMutations() <- WriteTimeoutException
* asyncRemoveFromBatchlog()

All WriteTimeoutExceptions for syncWrite will be catched and passed to the caller. Unfortunately the caller will not be able to tell if the timeout occured while creating/sending the batchlog or executing the individual batch statements.

# Timeout during batchlog creation: client must retry operation or batch might be lost
# Timout during mutations: client should not retry as a new batchlog will be created on every StorageProxy.mutateAtomically() call while previous batchlogs would not be deleted. This can have performance implications for large batches on stressed out clusters

There should be a way to tell if a batchlog was successfully created, so we can let the client move on and assume batch execution based on batchlog at some point in the future. 

See also CASSANDRA-8672 for similar error handling issue


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)