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

Add support for setting the awaitTeminationSeconds and waitForTasksToCompleteOnShutdown #15951

Conversation

filiphr
Copy link
Contributor

@filiphr filiphr commented Feb 14, 2019

to the TaskExecutorBuilder and via the TaskExecutionProperties

I started the migration to Spring Boot 2.1 and I wanted to get rid of our custom executor configuration as we can reuse the one from Boot. Awesome job on adding that in 2.1. I noticed that there are 2 methods that we use and are not exposed. With this PR I am exposing those 2 properties.

Let me know if the target to 2.1.x and the PR in general is acceptable for you. If there is something that I need to change please do let me know.

…CompleteOnShutdown to the TaskExecutorBuilder and via the TaskExecutionProperties
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Feb 14, 2019
Copy link
Member

@snicoll snicoll left a comment

Choose a reason for hiding this comment

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

Thanks for the PR, this looks good overall and I am not sure I remember why I didn't added those. I've added a few suggestions and we'll figure out next where that should land. In theory, master is the rule.

@@ -36,6 +39,22 @@
*/
private String threadNamePrefix = "task-";

/**
* The maximum number of time that the executor is supposed to block on shutdown in
Copy link
Member

Choose a reason for hiding this comment

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

Configuration properties descriptions do not start with "The", "A", etc. The first sentence must be much shorter as it's used by IDEs on auto-completion.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Wasn't aware about that. Will change it to

The maximum number of time that the executor is supposed to block on shutdown waiting for remaining tasks to complete.

Is this text acceptable?

Copy link
Member

Choose a reason for hiding this comment

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

No it is isn't. It starts with The and I've indicated previously we're not documenting keys that way.

On a second thought those two keys are related to shutdown so it might be interesting to crete a sub group for them the same way we did for pool

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sorry, I actually removed The in my commit. Yes I'll move them into a shutdown sub group

private Duration awaitTermination;

/**
* Whether the executor should wait for scheduled tasks to complete on shutdown, not
Copy link
Member

Choose a reason for hiding this comment

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

Ditto. The sentence should stop at the current comma IMO.

"spring.task.execution.pool.allow-core-thread-timeout=true",
"spring.task.execution.pool.keep-alive=5s",
"spring.task.execution.await-termination=30s",
"spring.task.execution.wait-for-tasks-to-complete-on-shutdown=true",
Copy link
Member

Choose a reason for hiding this comment

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

Let's try to keep a consistent ordering in things. Adding those two properties at the end looks ok to me as they are logically grouped. Let's keep the same here and add them after the thread-name-prefix

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I initially wanted not to create a lot of unnecessary changes, but the format already did that 😄. I will change the ordering

@@ -79,6 +81,10 @@ public void taskExecutorBuilderShouldApplyCustomSettings() {
.hasFieldOrPropertyWithValue("allowCoreThreadTimeOut", true);
assertThat(taskExecutor.getKeepAliveSeconds()).isEqualTo(5);
assertThat(taskExecutor.getThreadNamePrefix()).isEqualTo("mytest-");
assertThat(ReflectionTestUtils.getField(taskExecutor,
Copy link
Member

Choose a reason for hiding this comment

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

We don't use ReflectionTestUtils for such basic assertion but assertJ (assertFieldOrPropertyWithValue).

@@ -175,6 +175,8 @@ content into your application. Rather, pick only the properties that you need.
spring.task.execution.pool.max-size= # Maximum allowed number of threads. If tasks are filling up the queue, the pool can expand up to that size to accommodate the load. Ignored if the queue is unbounded.
spring.task.execution.pool.queue-capacity= # Queue capacity. An unbounded capacity does not increase the pool and therefore ignores the "max-size" property.
spring.task.execution.thread-name-prefix=task- # Prefix to use for the names of newly created threads.
spring.task.execution.await-termination= # The maximum number of time that the executor is supposed to block on shutdown in order to wait for remaining tasks to complete their execution before the rest of the container continues to shut down. This is particularly useful if your remaining tasks are likely to need access to other resources that are also managed by the container. If a duration suffix is not specified, seconds will be used.
Copy link
Member

Choose a reason for hiding this comment

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

Keys are ordered alphabetically and the description is way too long as well.

}

/**
* /** Set the maximum number of time that the executor is supposed to block on
Copy link
Member

Choose a reason for hiding this comment

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

Formatting glitch here.

@snicoll snicoll added the status: waiting-for-feedback We need additional information before we can continue label Feb 14, 2019
@filiphr
Copy link
Contributor Author

filiphr commented Feb 14, 2019

I've added a few suggestions and we'll figure out next where that should land. In theory, master is the rule.

Thanks for the review @snicoll. I've applied the fixes you mentioned. If the text is still not satisfiable I can adapt it. I more or less copied that from the ExecutorConfigurationSupport.

The reason why I did it against 2.1.x was that I was hoping it might go in it so I can remove more from our code. I also saw that there were a lot of commits on 2.1.x and which were then merged to master.

Feel free to squash everything in one commit, if you want me to do that let me know

@snicoll
Copy link
Member

snicoll commented Feb 14, 2019

@filiphr thanks but I believe the workaround for now is easy enough. You can inject the builder, apply it and then set the two properties you need. It doesn't remove your custom arrangement but it allows to configure the 2.1 properties at least.

I need to give a bit this a bit more thought. As I've indicated, those properties are related to shutdown so I am quite keen to group them, especially as the current form is too long IMO.

I'll pick up from here.

@filiphr
Copy link
Contributor Author

filiphr commented Feb 14, 2019

Yes the current workaround works perfectly.

I need to give a bit this a bit more thought. As I've indicated, those properties are related to shutdown so I am quite keen to group them, especially as the current form is too long IMO.

I'll pick up from here.

No problem, if there is something that I can do please let me know.

@snicoll snicoll added type: enhancement A general enhancement and removed status: waiting-for-feedback We need additional information before we can continue status: waiting-for-triage An issue we've not yet triaged labels Feb 15, 2019
@snicoll snicoll added this to the 2.2.x milestone Feb 15, 2019
@snicoll snicoll changed the base branch from 2.1.x to master February 18, 2019 16:53
@snicoll snicoll self-assigned this Feb 18, 2019
@snicoll snicoll modified the milestones: 2.2.x, 2.2.0.M1 Feb 18, 2019
@snicoll snicoll closed this in d2cbf08 Feb 18, 2019
snicoll added a commit that referenced this pull request Feb 18, 2019
* pr/15951:
  Add support for task scheduling shutdown related properties
  Polish "Add support for task executor shutdown related properties"
  Add support for task executor shutdown related properties
@snicoll
Copy link
Member

snicoll commented Feb 18, 2019

@filiphr thanks for the contribution. I've polished it and also added support for TaskScheduling as they share a common feature there.

@filiphr filiphr deleted the task-execution-configuration-more-properties branch February 18, 2019 20:19
@filiphr
Copy link
Contributor Author

filiphr commented Feb 18, 2019

Thanks for merging the PR and for extending on it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement A general enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants