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)