Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Troubleshooting general errors in Amazon Keyspaces

Getting general errors? Here are some common issues and how to resolve them.

General errors

You're getting one of the following top-level exceptions that can occur due to many different reasons.

These exceptions are generated by the client driver and can occur either when you're establishing the control connection or when you're performing read/write/prepare/execute/batch requests.

When the error occurs while you're establishing the control connection, it's a sign that all the contact points specified in your application are unreachable. When the error occurs while performing read/write/prepare/execute queries, it indicates that all of the retries for that request have been exhausted. Each retry is attempted on a different node when you're using the default retry policy.

How to isolate the underlying error from top-level Java driver exceptions

These general errors can be caused either by connection issues or when performing read/write/prepare/execute operations. Transient failures have to be expected in distributed systems, and should be handled by retrying the request. The Java driver doesn't automatically retry when connection errors are encountered, so it's recommended to implement the retry policy when establishing the driver connection in your application. For a detailed overview of connection best practices, see Optimize client driver connections for the serverless environment.

By default, the Java driver sets idempotence to false for all request, which means the Java driver doesn't automatically retry failed read/write/prepare request. To set idempotence to true and tell the driver to retry failed requests, you can do so in a few different ways. Here's one example how you can set idempotence programmatically for a single request in your Java application.

Statement s = new SimpleStatement("SELECT * FROM my_table WHERE id = 1");
s.setIdempotent(true);

Or you can set the default idempotence for your entire Java application programmatically as shown in the following example.

// Make all statements idempotent by default:
cluster.getConfiguration().getQueryOptions().setDefaultIdempotence(true);
//Set the default idempotency to true in your Cassandra configuration
basic.request.default-idempotence = true

Another recommendation is to create a retry policy at the application level. In this case, the application needs to catch the NoNodeAvailableException and retry the request. We recommend 10 retries with exponential backoff starting at 10ms and working up to 100ms with a total time of 1 second for all retries.

Another option is to apply the Amazon Keyspaces exponential retry policy when establishing the Java driver connection available on Github.

Confirm that you have established connections to more than one node when using the default retry policy. You can do so using the following query in Amazon Keyspaces.

SELECT * FROM system.peers;

If the response for this query is empty, this indicates that you're working with a single node for Amazon Keyspaces. If you're using the default retry policy, there will be no retries because the default retry always occurs on a different node. To learn more about establishing connections over VPC endpoints, see How to configure connections over VPC endpoints in Amazon Keyspaces.

For a step-by-step tutorial that shows how to establish a connection to Amazon Keyspaces using the Datastax 4.x Cassandra driver, see Step-by-step tutorial to connect to Amazon Keyspaces using the 4.x DataStax Java driver for Apache Cassandra and the SigV4 authentication plugin.