-
Notifications
You must be signed in to change notification settings - Fork 15
Allow using more threads to refresh cassandra pools #5900
Conversation
Generate changelog in
|
There was a problem hiding this 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( |
There was a problem hiding this comment.
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(); | ||
} |
There was a problem hiding this comment.
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.
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. |
Released 0.543.0 |
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