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)
