Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OperationTimedOutException translated to CassandraUncategorizedException [DATACASS-402] #569

Closed
spring-projects-issues opened this issue Feb 14, 2017 · 8 comments
Assignees
Labels
type: bug A general bug
Milestone

Comments

@spring-projects-issues
Copy link

James Howe opened DATACASS-402 and commented

Instead it should translate to an appropriate TransientDataAccessException or maybe DataAccessResourceFailureException.

    at com.datastax.driver.core.RequestHandler$SpeculativeExecution.onTimeout(RequestHandler.java:770)
    at com.datastax.driver.core.Connection$ResponseHandler$1.run(Connection.java:1374)
    at io.netty.util.HashedWheelTimer$HashedWheelTimeout.expire(HashedWheelTimer.java:625)
    at io.netty.util.HashedWheelTimer$HashedWheelBucket.expireTimeouts(HashedWheelTimer.java:700)
    at io.netty.util.HashedWheelTimer$Worker.run(HashedWheelTimer.java:428)
    at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
    ... 1 common frames omitted
Wrapped by: com.datastax.driver.core.exceptions.OperationTimedOutException: [...] Timed out waiting for server response
    at com.datastax.driver.core.exceptions.OperationTimedOutException.copy(OperationTimedOutException.java:44)
    at com.datastax.driver.core.exceptions.OperationTimedOutException.copy(OperationTimedOutException.java:26)
    at com.datastax.driver.core.DriverThrowables.propagateCause(DriverThrowables.java:37)
    at com.datastax.driver.core.DefaultResultSetFuture.getUninterruptibly(DefaultResultSetFuture.java:245)
    at com.datastax.driver.core.AbstractSession.execute(AbstractSession.java:68)
    at org.springframework.cassandra.core.CqlTemplate$11.doInSession(CqlTemplate.java:565)
    at org.springframework.cassandra.core.CqlTemplate$11.doInSession(CqlTemplate.java:559)
    at org.springframework.cassandra.core.CqlTemplate.doExecute(CqlTemplate.java:276)
    ... 143 common frames omitted
Wrapped by: org.springframework.cassandra.support.exception.CassandraUncategorizedException: [...] Timed out waiting for server response; nested exception is com.datastax.driver.core.exceptions.OperationTimedOutException: [...] Timed out waiting for server response
    at org.springframework.cassandra.support.CassandraExceptionTranslator.translateExceptionIfPossible(CassandraExceptionTranslator.java:129)
    at org.springframework.cassandra.core.CqlTemplate.potentiallyConvertRuntimeException(CqlTemplate.java:946)
    at org.springframework.cassandra.core.CqlTemplate.translateExceptionIfPossible(CqlTemplate.java:930)
    at org.springframework.cassandra.core.CqlTemplate.translateExceptionIfPossible(CqlTemplate.java:912)
    at org.springframework.cassandra.core.CqlTemplate.doExecute(CqlTemplate.java:278)
    at org.springframework.cassandra.core.CqlTemplate.doExecute(CqlTemplate.java:559)

Affects: 1.5 GA (Ingalls), 2.0 M1 (Kay)

Referenced from: commits 451f658, 901872f, 690ebe5

Backported to: 1.5.1 (Ingalls SR1)

@spring-projects-issues
Copy link
Author

James Howe commented

In fact the same is true for TransportException as well

@spring-projects-issues
Copy link
Author

James Howe commented

I've ended up extending the translator to use existing DAEs that appear to mean basically the same thing:
ConnectionException -> CassandraConnectionFailureException
BusyConnectionException -> CassandraConnectionFailureException
BusyPoolException -> CassandraConnectionFailureException
ReadFailureException -> CassandraInsufficientReplicasAvailableException
WriteFailureException -> CassandraInsufficientReplicasAvailableException
OverloadedException -> CassandraInsufficientReplicasAvailableException
BootstrappingException -> CassandraInsufficientReplicasAvailableException

@spring-projects-issues
Copy link
Author

Mark Paluch commented

I'd make a suggestion regarding the mapping:

  • BusyConnectionException, ConnectionException -> CassandraConnectionFailureException
  • QueryConsistencyException, BusyPoolException -> DataAccessResourceFailureException
  • OverloadedException, BootstrappingException -> TransientDataAccessResourceException

That mapping uses the type hierarchy to catch exceptions in a more generic way retaining the semantic of the original exception.

I'd argue that:

  • CassandraConnectionFailureException maps to NoHostAvailableException and we should not change that behavior.
  • CassandraInsufficientReplicasAvailableException does not fit to BootstrappingException and the other mentioned types because it deals with a single host, maybe multi-node execution, with a specific failure that is not related to consistency in the first place.

Does this make sense?

@spring-projects-issues
Copy link
Author

James Howe commented

But the other two QueryConsistencyException should still go to the respective timeout exceptions - they need special handling.
My reasoning was to separate the driver->coordinator failures from the coordinator->node failures. I don't care about the distinction much beyond that.

@spring-projects-issues
Copy link
Author

Mark Paluch commented

WriteTimeoutException -> CassandraWriteTimeoutException and ReadTimeoutException -> CassandraReadTimeoutException stay the way they are right now.

Sorry for confusion, with QueryConsistencyException I was talking about everything else that remains unmapped once all other mappings are processed.

@spring-projects-issues
Copy link
Author

James Howe commented

Just checking. When extending the easiest way is to customise before calling super, so you have to be specific

@spring-projects-issues
Copy link
Author

Mark Paluch commented

That's right. Using exception instanceof … before calling CassandraExceptionTranslator.translateExceptionIfPossible(…) is the way how to customize exception translation.

@spring-projects-issues
Copy link
Author

Mark Paluch commented

I updated

  • OverloadedException, BootstrappingException -> TransientDataAccessResourceException

to reflect that operations throwing these exceptions might be executed again and their execution might succeed at a later time

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug A general bug
Projects
None yet
Development

No branches or pull requests

2 participants