Skip to content

HIVE-29513: Increase HikariCP connection timeout default from 30s to 60s#6381

Closed
rtrivedi12 wants to merge 3 commits into
apache:masterfrom
rtrivedi12:HIVE-29513
Closed

HIVE-29513: Increase HikariCP connection timeout default from 30s to 60s#6381
rtrivedi12 wants to merge 3 commits into
apache:masterfrom
rtrivedi12:HIVE-29513

Conversation

@rtrivedi12

Copy link
Copy Markdown
Contributor

What changes were proposed in this pull request?

Set HikariCP connection timeout to an explicit default of 60 seconds (60,000 ms) in HikariCPDataSourceProvider, making it configurable via hikaricp.connectionTimeout property.

Why are the changes needed?

MetaStore experiences connection timeout errors when database response is slow or during peak load, as HikariCP's implicit 30-second default is insufficient.

Does this PR introduce any user-facing change?

Yes. Connection timeout default changes from HikariCP's implicit 30 seconds to Hive's explicit 60 seconds. Users can override this by setting hikaricp.connectionTimeout in hive-site.xml.

How was this patch tested?

Added/updated unit tests in TestDataSourceProviderFactory:

@ayushtkn ayushtkn left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a minor refactor suggestion, otherwise change LGTM


Properties properties = replacePrefix(DataSourceProvider.getPrefixedProperties(hdpConfig, HIKARI));
// connectionTimeout is handled separately with getTimeDuration()
properties.remove("connectionTimeout");

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we instead handle it in the getPrefixedProperties itself?

  static Properties getPrefixedProperties(Configuration hdpConfig, String prefix, Map<String, Long> timeDurationConfigs) {
    Properties props = new Properties();

    Iterables.filter(hdpConfig, e -> e.getKey() != null && e.getKey().startsWith(prefix)).forEach(e -> {
      String fullKey = e.getKey();
      String keyName = fullKey.substring(prefix.length());
      Long defaultVal = timeDurationConfigs.get(keyName);
      if (defaultVal != null) {
        long timeMs = hdpConfig.getTimeDuration(fullKey, defaultVal, TimeUnit.MILLISECONDS);
        props.setProperty(fullKey, String.valueOf(timeMs));
      } else {
        props.setProperty(fullKey, e.getValue());
      }
    });

    return props;
  }

and define a MAP like

  private static final Map<String, Long> TIME_DURATION_CONFIGS = Map.of("connectionTimeout",
      DEFAULT_CONNECTION_TIMEOUT_MS);

@rtrivedi12 rtrivedi12 Apr 8, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, thanks for suggestion!

@okumin

okumin commented Apr 2, 2026

Copy link
Copy Markdown
Contributor

Does it often happen that the backend RDBMS is unavailable for 30-60 seconds?

@rtrivedi12

Copy link
Copy Markdown
Contributor Author

Does it often happen that the backend RDBMS is unavailable for 30-60 seconds?

Yes, we've mainly observed connection drops during peak traffic or heavy transactional table usage. However, increasing the connection timeout to 60 seconds generally allows the system to recover sucessfully.

@sonarqubecloud

sonarqubecloud Bot commented Apr 8, 2026

Copy link
Copy Markdown

@okumin

okumin commented Apr 9, 2026

Copy link
Copy Markdown
Contributor

In my honest opinion, the configuration should be tuned by users, or we should drastically increase the default if it is evident that typical connection pool settings don't fit HMS's workload.
If it takes 40 seconds today in someone's environment today, it might take 61 seconds on another day or in another environment. It might be too ad-hoc to update the default timeout every time someone hits the issue.

@github-actions

github-actions Bot commented Jun 9, 2026

Copy link
Copy Markdown

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
Feel free to reach out on the dev@hive.apache.org list if the patch is in need of reviews.

@github-actions github-actions Bot added the stale label Jun 9, 2026
@github-actions github-actions Bot closed this Jun 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants