[
https://issues.apache.org/jira/browse/CASSANDRA-8745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne resolved CASSANDRA-8745.
-----------------------------------------
Resolution: Not a Problem
There *is* a way to distinguish those two case, and that is through the
"writeType" argument that a WriteTimeoutException contains. That writeType will
be BATCH for syncWriteBatchedMutations and BATCH_LOG for syncWriteToBatchlog.
> 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)
