• Glossary
  • Support
  • Downloads
  • DataStax Home
Get Live Help
Expand All
Collapse All

Developing applications with DataStax drivers

    • Getting started
    • Best practices
    • Connecting to the database
      • Connecting to DataStax Astra databases
      • Authentication in DataStax drivers
      • Using SSL in DataStax drivers
      • Load balancing with DataStax drivers
      • Connection pooling
      • Retry policies
      • Reconnection policies
      • Execution profiles
    • Submitting queries
      • Working with multi-workload clusters
      • Using DSE Search with the DataStax drivers
      • Submitting DSE Graph queries with the DataStax drivers
      • Result paging with DataStax drivers
      • Synchronous and asynchronous query execution
      • Managing concurrency in asynchronous query execution
      • Speculative query execution
      • Query idempotence
      • Driver metrics
      • Object mappers in DSE drivers
      • Query timestamps
    • Error handling
      • Server errors
      • Client errors
    • Example applications
      • Connecting to Astra
      • Executing CQL statements
      • Executing bound statements
  • Developing applications with DataStax drivers
  • Connecting to the database
  • Reconnection policies

Reconnection policies

Reconnection policies allow the DataStax drivers to automatically reestablish a connection to a node that was previously marked as down.

A node can be marked down by the server’s gossip process or as a result of an idle connection timeout. Status changes are passed along the control connection back to the driver.

All of the drivers offer a standard reconnection policy. Some drivers offer additional reconnection policies:

  • Constant: The driver waits a constant amount of time between each reconnection attempt.

  • Exponential: The driver waits exponentially longer between each reconnection attempt.

  • Fixed: The driver waits a different amount of time between each reconnection attempt.

Drivers that offer the exponential reconnection policy use that policy as their default. For other drivers, the constant reconnection policy is the default policy.

Table 1. Reconnection policies for drivers

C/C++

C#

Java

Node.js

PHP

Python

Ruby

Gossip reconnection

The control connection for the drivers listens to push notifications from the DSE server cluster. When a node is marked up, all scheduled reconnections are canceled and a new connection to that node is established.

Gossip reconnection policy example
Figure 1. Gossip reconnection policy example

Idle disconnect and reconnection

To prevent intermediate network devices like routers and firewalls from disconnecting the drivers from a node, an OPTIONS request is sent to a connection at a constant interval, also known as a heartbeat. If the connection becomes idle and the node does not respond to the heartbeat in a given amount of time, the node is marked down. Once this occurs, the driver waits a specified amount of time based on the reconnection policy before attempting to reconnect to the node.

Idle disconnect and reconnection policy example
Figure 2. Idle disconnect and reconnection policy example
Retry policies Execution profiles

General Inquiries: +1 (650) 389-6000 info@datastax.com

© DataStax | Privacy policy | Terms of use

DataStax, Titan, and TitanDB are registered trademarks of DataStax, Inc. and its subsidiaries in the United States and/or other countries.

Apache, Apache Cassandra, Cassandra, Apache Tomcat, Tomcat, Apache Lucene, Apache Solr, Apache Hadoop, Hadoop, Apache Pulsar, Pulsar, Apache Spark, Spark, Apache TinkerPop, TinkerPop, Apache Kafka and Kafka are either registered trademarks or trademarks of the Apache Software Foundation or its subsidiaries in Canada, the United States and/or other countries.

Kubernetes is the registered trademark of the Linux Foundation.

landing_page landingpage