Skip to content
This repository has been archived by the owner on Nov 14, 2024. It is now read-only.

Allow using more threads to refresh cassandra pools #5900

Merged
merged 4 commits into from
Feb 11, 2022
Merged

Conversation

gmaretic
Copy link
Contributor

Goals (and why):
Currently, only a single thread does all client pool refreshes for all transaction managers. Turns out that can be too slow if we use ~100 TMs, and manifests itself in two ways: refreshes are much slower than anticipated, and we leak resources because our infinite queue constantly grows. This is not a fullproof solution, but it allows users to specify a more reasonable number of threads.

==COMMIT_MSG==
Cassandra users can now specify the number of threads to be used for refreshing pools
==COMMIT_MSG==

Implementation Description (bullets):
This is a bit on the awful side, but it is usable enough until we figure out if we want to do something better

Testing (What was existing testing like? What have you done to improve it?):
Unit tests, existing tests

Concerns (what feedback would you like?):
People can break themselves if they do things wrong, but barring really awful configurations, it shouldn't really be worse than it is now

Where should we start reviewing?:

Priority (whenever / two weeks / yesterday):
asap

@gmaretic gmaretic requested a review from jeremyk-91 February 10, 2022 19:19
@changelog-app
Copy link

changelog-app bot commented Feb 10, 2022

Generate changelog in changelog/@unreleased

Type

  • Feature
  • Improvement
  • Fix
  • Break
  • Deprecation
  • Manual task
  • Migration

Description

Cassandra users can now specify the number of threads to be used for refreshing pools

Check the box to generate changelog(s)

  • Generate changelog entry

Copy link
Contributor

@sudiksha27 sudiksha27 left a comment

Choose a reason for hiding this comment

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

The changes look correct and the tests are good but I think we have added a bit of complexity. Is there a reason we cannot init a common ScheduledThreadPoolExecutor in CassAtlasDbFactory? Surely there must be just one factory across namespaces.

private static final ScheduledExecutorService sharedRefreshDaemon =
PTExecutors.newScheduledThreadPool(1, new NamedThreadFactory("CassandraClientPoolRefresh", true));
private static final InitializeableScheduledExecutorServiceSupplier sharedExecutorSupplier =
new InitializeableScheduledExecutorServiceSupplier(
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: static final should be all caps?

supplier.get().schedule(task, 0, TimeUnit.SECONDS);
supplier.get().schedule(task, 0, TimeUnit.SECONDS);
assertThat(latch.await(1, TimeUnit.SECONDS)).isFalse();
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Hm the test makes sense.

@sudiksha27
Copy link
Contributor

The factory creation path is janky and it is okay to roll out the change now and see if this works - hopefully at some point we fix our creation paths.

@bulldozer-bot bulldozer-bot bot merged commit 4847635 into develop Feb 11, 2022
@bulldozer-bot bulldozer-bot bot deleted the execute branch February 11, 2022 11:55
@svc-autorelease
Copy link
Collaborator

Released 0.543.0

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants