-
Notifications
You must be signed in to change notification settings - Fork 119
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: support setting core pool size for async API in system property #2632
Conversation
Add support for setting the core pool size for the thread pool that is used for the Async API using a system property. This allows users to change this property without having to change code, and to set the property if they are using a framework that builds on top of the client library, but that does not have a configuration option for setting a custom executor provider. Fixes #2631
@@ -913,6 +914,49 @@ public void testCustomAsyncExecutorProvider() { | |||
assertSame(service, options.getAsyncExecutorProvider().getExecutor()); | |||
} | |||
|
|||
@Test | |||
public void testAsyncExecutorProviderCoreThreadCount() throws Exception { | |||
assertEquals(8, SpannerOptions.getDefaultAsyncExecutorProviderCoreThreadCount()); |
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: Should we add a check to ensure that the system property was originally unset? Or maybe explicitly set the property to null?
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.
I see that there is a handling of this scenario within the finally
block of runWithSystemProperty
method, but thought if explicitly setting null would be better to ensure that the default behaviour is due to null property and not because somehow the property was already set to 8.
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.
I added a test for both null
and an empty string.
…googleapis#2632) Add support for setting the core pool size for the thread pool that is used for the Async API using a system property. This allows users to change this property without having to change code, and to set the property if they are using a framework that builds on top of the client library, but that does not have a configuration option for setting a custom executor provider. Fixes googleapis#2631
🤖 I have created a release *beep* *boop* --- ## [6.50.0](https://togithub.com/googleapis/java-spanner/compare/v6.49.0...v6.50.0) (2023-10-09) ### Features * Support setting core pool size for async API in system property ([#2632](https://togithub.com/googleapis/java-spanner/issues/2632)) ([e51c55d](https://togithub.com/googleapis/java-spanner/commit/e51c55d332bacb9d174a24b0d842b2cba4762db8)), closes [#2631](https://togithub.com/googleapis/java-spanner/issues/2631) ### Dependencies * Update dependency com.google.cloud:google-cloud-trace to v2.24.0 ([#2577](https://togithub.com/googleapis/java-spanner/issues/2577)) ([311c2ad](https://togithub.com/googleapis/java-spanner/commit/311c2ad97311490893f3abf4da5fe4d511c445dd)) --- This PR was generated with [Release Please](https://togithub.com/googleapis/release-please). See [documentation](https://togithub.com/googleapis/release-please#release-please).
|
||
@VisibleForTesting | ||
static int getDefaultAsyncExecutorProviderCoreThreadCount() { | ||
String propertyName = "SPANNER_ASYNC_NUM_CORE_THREADS"; |
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.
magic string!
should we maintain list of constants/enums property names?
Add support for setting the core pool size for the thread pool that is used for the Async API using a system property. This allows users to change this property without having to change code, and to set the property if they are using a framework that builds on top of the client library, but that does not have a configuration option for setting a custom executor provider.
Fixes #2631