[SERVER-57714] Support changing ShardingTaskExecutorPoolMinSize via setParameter without restart Created: 15/Jun/21  Updated: 29/Oct/23  Resolved: 12/Jan/22

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 5.0.0, 4.2.14, 4.4.6, 4.0.25
Fix Version/s: 4.2.0

Type: Improvement Priority: Major - P3
Reporter: Eric Sedor Assignee: Tyler Seip (Inactive)
Resolution: Fixed Votes: 1
Labels: original-top-20, servicearch-wfbf-day
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Documented
is documented by DOCS-15028 Investigate changes in SERVER-57714: ... Closed
Duplicate
duplicates SERVER-39819 Add HostGroup Controller impl to tie ... Closed
Initiative
Backwards Compatibility: Fully Compatible
Sprint: Service Arch 2022-1-10, Service Arch Test, Service Arch 2022-1-24
Participants:
Story Points: 4

 Description   

Currently, changing ShardingTaskExecutorPoolMinSize requires a restart.

But safe settings require consideration of total router count. So, in clusters that use this setting to keep connection pools as warm as possible, adding or removing shards requires a restart of all routers.

Allowing ShardingTaskExecutorPoolMinSize to be configured via setParameter without restart allows shards to be added and removed without the added operational complexity and service interruption.

Note that the related setting, ShardingTaskExecutorPoolMaxSize, is not as coupled to router count as the min size is. But as these settings are commonly paired it probably makes sense to allow both to be changed without restart. That said, *MinSize is more important to be able to change on the fly.

(cc jason.carey)



 Comments   
Comment by Tyler Seip (Inactive) [ 12/Jan/22 ]

It looks like this work has actually been done on SERVER-39819 a few years ago, and that our documentation is out of date. I'm going to close this as complete with the caveat that the documentation needs to be updated to indicate that we do support setting the minimum pool size during runtime.

Comment by Lauren Lewis (Inactive) [ 16/Nov/21 ]

shameek.ray is flagging this as an Operational Resilience ticket, we will slate for an upcoming sprint.

Generated at Thu Feb 08 05:42:36 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.