DA to Vertica (DR) Connectivity Fails with VX001/7540 'Session Timed Out!' after Vertica 23.4.x Upgrade
search cancel

DA to Vertica (DR) Connectivity Fails with VX001/7540 'Session Timed Out!' after Vertica 23.4.x Upgrade

book

Article ID: 418376

calendar_today

Updated On:

Products

Network Observability

Issue/Introduction

During the installation of Data Aggregator (DA) or attempting to establish connectivity between the Data Aggregator and the Vertica Data Repository (DR), the connection fails with a session timeout error. This issue often arises after the Vertica Data Repository has been upgraded to version 23.4.x or later. This is not seen in all environments.

The Vertica log (e.g., vertica.log) will show entries similar to the following:

2025-09-22 09:51:24.546 Connection listener:0x7f69c3fff700 [Session] <INFO> Accepted new connection. Total connection count is 1 2025-09-22 09:51:24.546 Init Session:0x7f69f8ff9700 <LOG> @v_db_node0001: 00000/11152: Initializing session for host=<IP Address> port=50308 (total sockets in use by all connections 1) 2025-09-22 09:51:24.546 Init Session:0x7f69f8ff9700 [Session] <INFO> Set idle timeout for remote host <Ip Address> to 00:00:10 2025-09-22 09:51:34.556 Init Session:0x7f69f8ff9700 <FATAL> @v_db_node0001: {SessionRun} VX001/7540: Session idle for more than 10000 ms. Session Timed Out! LOCATION: read, /data/jenkins/workspace/RE-ReleaseBuilds/RE-Laserbeam/server/vertica/Util/TLS.cpp:763.

Key symptoms:

  • The connection is initially accepted by Vertica.
  • The session initialization process takes longer than 10 seconds.
  • The error VX001/7540: Session idle for more than 10000 ms. Session Timed Out! is logged.
  • DA components (e.g., installer, services) cannot establish a stable connection to Vertica.

Environment

  • Component: Data Aggregator (DA)
  • Database: Vertica Data Repository (DR) version 23.4.x or later.
  • Affected process: DA installation, upgrade, or ongoing DA-to-DR communication.

Cause

The IdleTimeoutInitializingConnectionsMs Vertica parameter controls how long a newly accepted but not yet fully initialized connection can remain idle before being terminated. The default value for this parameter is 10000 milliseconds (10 seconds). With Vertica 23.4.x and potentially other factors (like network latency, TLS handshake complexity, or specific client/server interaction patterns), the initial connection handshake and negotiation phase between the Data Aggregator and Vertica may exceed this 10-second default timeout, leading to the session being forcibly closed before it can be fully established.

Resolution

To resolve this issue, increase the IdleTimeoutInitializingConnectionsMs parameter in Vertica to allow more time for the connection initialization process.

Steps:

  1. Connect to Vertica:
    Log in to one of your Vertica nodes as the dbadmin user (or another superuser with sufficient privileges) and open a vsql session.

    /opt/vertica/bin/vsql -U dbadmin
  2. Increase the Timeout Parameter:
    Execute the following SQL command to increase the timeout value to 30000 milliseconds (30 seconds). This change will be applied cluster-wide and persist across Vertica restarts for new connections.

    select set_config_parameter ('IdleTimeoutInitializingConnectionsMs', 30000);

    Verify the Change (Optional but Recommended):
    You can check the current value of the parameter using:

    SHOW ALL LIKE 'IdleTimeoutInitializingConnectionsMs'; The output should show 30000.
  3. Retry DA Installation/Connectivity:
    Once the parameter has been updated in Vertica, re-attempt the Data Aggregator installation or connectivity process that was previously failing. The increased timeout should now allow enough time for the session to initialize successfully.

  4. Once the installation is done you can revert the setting back to 10000.

Additional Information

  • A value of 30000 ms (30 seconds) is generally sufficient for most environments. In cases of extremely high latency or specific network conditions, this value could be further increased, but excessive timeouts can tie up resources unnecessarily.
  • This parameter only affects the initialization phase of a connection. Once a session is established, other timeout parameters govern its behavior (e.g., ClientQueryTimeout).