Scylla Documentation Logo Documentation
  • Server
    • Scylla Open Source
    • Scylla Enterprise
    • Scylla Alternator
  • Cloud
    • Scylla Cloud
    • Scylla Cloud Docs
  • Tools
    • Scylla Manager
    • Scylla Monitoring Stack
    • Scylla Operator
  • Drivers
    • CQL Drivers
    • DynamoDB Drivers
Download
Menu

Caution

You're viewing documentation for a previous version of Scylla Java Driver. Switch to the latest stable version.

Scylla Java Driver Manual Core driver Reconnection

Reconnection¶

Quick overview¶

When a connection is lost, try to reestablish it at configured intervals.

  • advanced.reconnection-policy in the configuration; defaults to exponential backoff, also available: constant delay, write your own.

  • applies to connection pools and the control connection.

  • advanced.reconnect-on-init (false by default) controls whether the session tries to reconnect when it is first created


At runtime¶

If a running session loses a connection to a node, it tries to re-establish it according to a configurable policy. This is used in two places:

  • connection pools: for each node, a session has a fixed-size pool of connections to execute user requests. If one or more connections drop, a reconnection gets started for the pool; each attempt tries to reopen the missing number of connections. This goes on until the pool is back to its expected size;

  • control connection: a session uses a single connection to an arbitrary node for administrative requests. If that connection goes down, a reconnection gets started; each attempt iterates through all active nodes until one of them accepts a connection. This goes on until we have a control node again.

The reconnection policy controls the interval between each attempt. It is defined in the configuration:

datastax-java-driver {
  advanced.reconnection-policy {
    class = ExponentialReconnectionPolicy
    base-delay = 1 second
    max-delay = 60 seconds
  }
}

ExponentialReconnectionPolicy is the default; it starts with a base delay, and then doubles it after each attempt. ConstantReconnectionPolicy uses the same delay every time, regardless of the previous number of attempts.

You can also write your own policy; it must implement ReconnectionPolicy and declare a public constructor with a DriverContext argument.

For best results, use reasonable values: very low values (for example a constant delay of 10 milliseconds) will quickly saturate your system.

The policy works by creating a schedule each time a reconnection starts. These schedules are independent across reconnection attempts, meaning that each pool will start with a fresh delay even if other pools are already reconnecting. For example, assuming that the pool size is 3, the policy is the exponential one with the default values, and the control connection is initially on node1:

  • [t = 0] 2 connections to node2 go down. A reconnection starts for node2’s pool, with the next attempt in 1 second;

  • [t = 1] node2’s pool tries to open the 2 missing connections. One succeeds but the other fails. Another attempt is scheduled in 2 seconds;

  • [t = 1.2] 1 connection to node3 goes down. A reconnection starts for node3’s pool, with the next attempt in 1 second;

  • [t = 1.5] the control connection to node1 goes down. A reconnection starts for the control connection, with the next attempt in 1 second;

  • [t = 2.2], node3’s pool tries to open its missing connection, which succeeds. The pool is back to its expected size, node3’s reconnection stops;

  • [t = 2.5] the control connection tries to find a new node. It invokes the load balancing policy to get a query plan, which happens to start with node4. The connection succeeds, node4 is now the control node and the reconnection stops;

  • [t = 3] node2’s pool tries to open the last missing connection, which succeeds. The pool is back to its expected size, node2’s reconnection stops.

At init time¶

If a session fails to connect when it is first created, the default behavior is to abort and throw an error immediately.

If you prefer to retry, you can set the configuration option advanced.reconnect-on-init to true. Instead of failing, the driver will keep attempting to initialize the session at regular intervals, according to the reconnection policy, until at least one contact point replies. This can be useful when dealing with containers and microservices.

Note that the session is not accessible until it is fully ready: the CqlSessionBuilder.build() call — or the future returned by buildAsync() — will not complete until the connection was established.

PREVIOUS
Reactive Style Programming
NEXT
Request tracker
  • 4.12.0.x
    • 4.13.0.x
    • 4.12.0.x
    • 4.11.1.x
    • 4.10.0.x
    • 4.7.2.x
    • 3.11.2.x
    • 3.11.0.x
    • 3.10.2.x
    • 3.7.2.x
  • Java Driver for Scylla and Apache Cassandra®
  • API Documentation
  • Manual
    • API conventions
    • Case sensitivity
    • Core driver
      • Address resolution
      • Asynchronous programming
      • Authentication
      • Bill of Materials (BOM)
      • Compression
      • Configuration
        • Reference configuration
      • Control connection
      • Custom codecs
      • Detachable types
      • Query idempotence
      • Integration
      • Load balancing
      • Logging
      • Metadata
        • Node metadata
        • Schema metadata
        • Token metadata
      • Metrics
      • Native protocol
      • Non-blocking programming
      • Paging
      • Performance
      • Connection pooling
      • Query timestamps
      • Reactive Style Programming
      • Reconnection
      • Request tracker
      • Retries
      • Using the shaded JAR
      • Speculative query execution
      • SSL
      • Statements
        • Batch statements
        • Per-query keyspace
        • Prepared statements
        • Simple statements
      • Temporal types
      • Request throttling
      • Query tracing
      • Tuples
      • User-defined types
    • Developer docs
      • Administrative tasks
      • Common infrastructure
        • Concurrency
        • Driver context
        • Event bus
      • Native protocol layer
      • Netty pipeline
      • Request execution
    • Mapper
      • Integration
        • Kotlin
        • Lombok
        • Java 14 Records
        • Scala
      • DAOs
        • Custom result types
        • Delete methods
        • GetEntity methods
        • Increment methods
        • Insert methods
        • Null saving strategy
        • Query methods
        • Query provider methods
        • Select methods
        • SetEntity methods
        • Statement attributes
        • Update methods
      • Entities
      • Mapper interface
    • OSGi
    • Query builder
      • Conditions
      • DELETE
      • Idempotence in the query builder
      • INSERT
      • Relations
      • Schema builder
        • Aggregate
        • Function
        • Index
        • Keyspace
        • Materialized View
        • Table
        • Type
      • SELECT
      • Terms
      • TRUNCATE
      • UPDATE
  • Upgrade guide
  • Frequently asked questions
  • Changelog
  • Create an issue
  • Edit this page

On this page

  • Reconnection
    • Quick overview
    • At runtime
    • At init time
Logo
Docs Contact Us About Us
Mail List Icon Slack Icon
© 2022, ScyllaDB. All rights reserved.
Last updated on 25 May 2022.
Powered by Sphinx 4.3.2 & ScyllaDB Theme 1.2.2