[jira] [Resolved] (CASSANDRA-8745) Ambiguous WriteTimeoutException during atomic batch execution

["Sylvain Lebresne (JIRA)" <ji...@apache.org>]

     [ 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)