Skip to content
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

[DCJ-457] Stairway can be built with a provided ThreadPoolTaskExecutor #149

Merged

Conversation

okotsopoulos
Copy link
Contributor

@okotsopoulos okotsopoulos commented Jun 28, 2024

Addresses

Partially addresses https://broadworkbench.atlassian.net/browse/DCJ-457

PRs will need to be merged in the following order:

  1. This PR
  2. [DCJ-457] Register a ThreadPoolTaskExecutor for Stairway as a Bean terra-common-lib#187
  3. A forthcoming TDR PR to update its TCL version

Summary of changes

This PR allows calling services to bring their own instrumented executor to serve as their Stairway's threadpool.

If unspecified in StairwayBuilder, a DefaultThreadPoolTaskExecutor will be constructed and used.

DefaultThreadPoolTaskExecutor is a public class: calling services may elect to instantiate it themselves (e.g. a Spring Boot service would register this as a Bean for automatic actuator instrumentation).

Testing Strategy

Expanded unit tests.

Verified end-to-end behavior manually:

  • Publishing Stairway and TCL to my local Maven repository
  • Booting up TDR, with and without maxParallelFlights specified
  • Observed that stairwayExecutor metrics were automatically flowing through TDR's Actuator endpoint
  • Initiated a Stairway flight which succeeded. Executor occupancy was reflected in actuator metrics.

Example where TDR configured its maxParallelFlights to be 120, has one actively running flight, and one completed flight:

(base) okotsopo@wm111-e35 jade-data-repo % curl http://localhost:8080/actuator/prometheus | grep 'stairwayExecutor'
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 87022  100 8executor_pool_core_threads{name="stairwayExecutor",} 120.0   0
7022    0     0  10.1M      0 --:--:-- --:--:-- --:--:-- 10.3M
executor_queue_remaining_tasks{name="stairwayExecutor",} 2.147483647E9
executor_completed_tasks_total{name="stairwayExecutor",} 1.0
executor_pool_size_threads{name="stairwayExecutor",} 2.0
executor_queued_tasks{name="stairwayExecutor",} 0.0
executor_pool_max_threads{name="stairwayExecutor",} 120.0
executor_active_threads{name="stairwayExecutor",} 1.0

This allows calling services to bring their own instrumented executor to serve as their Stairway's threadpool.

If unspecified in StairwayBuilder, a DefaultThreadPoolTaskExecutor will be constructed and used.

DefaultThreadPoolTaskExecutor is a public class: calling services may elect to instantiate it themselves (e.g. a Spring Boot service would register this as a Bean for automatic actuator instrumentation).
@okotsopoulos okotsopoulos marked this pull request as ready for review June 28, 2024 18:34
@okotsopoulos
Copy link
Contributor Author

(Only marked as "ready for review" to see if that helps with checks not running… but it seems that GitHub is experiencing issues: https://www.githubstatus.com/incidents/9vwllhs2w1kj)

@okotsopoulos okotsopoulos marked this pull request as draft June 28, 2024 18:36
@okotsopoulos okotsopoulos marked this pull request as ready for review June 28, 2024 19:55
Copy link

@rtitle rtitle left a comment

Choose a reason for hiding this comment

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

This looks good to me -- I like the approach of decoupling StairwayThreadPool from the executor (instead of inheriting from it).

Copy link
Collaborator

@nmalfroy nmalfroy left a comment

Choose a reason for hiding this comment

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

This looks great! The reason I put in request changes is about some questions. All minor but probably worthy of calling out

If this value were to change in the future, the javadoc rendered view would reflect the change.
Mainly because my usage of Optional.ofNullable…orElse… constructs a new default executor every time, and throws it away if the builder has one set.  This is discouraged.

I decided to adhere with the existing convention for initializing instance variables from the StairwayBuilder object, which makes the constructor easier to follow.  If it's updated in the future with Optional handling, that would be acceptable as long as it's updated completely.
Copy link
Collaborator

@nmalfroy nmalfroy left a comment

Choose a reason for hiding this comment

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

You've answered all the questions I had :). Looks great!

This matches TDR's current build file -- the useMavenLocal flag makes it a little easier to leverage locally published artifacts on demand.
Copy link

sonarcloud bot commented Jul 1, 2024

@okotsopoulos okotsopoulos merged commit c4e3b26 into develop Jul 1, 2024
3 checks passed
@okotsopoulos okotsopoulos deleted the okotsopo-DCJ-457-stairway-threadpooltaskexecutor branch July 1, 2024 19:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants