[SERVER-38444] Coordinating a transaction should run fully in the ThreadPoolTaskExecutor for sharding tasks Created: 06/Dec/18 Updated: 27/Oct/23 Resolved: 25/Jan/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Esha Maharishi (Inactive) | Assignee: | [DO NOT USE] Backlog - Sharding Team |
| Resolution: | Gone away | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Sharding
|
||||||||
| Participants: | |||||||||
| Description |
|
Currently, coordinating a transaction "hops" between the TransactionCoordinatorService's ThreadPool and the fixed ThreadPoolTaskExecutor on the Grid. It does so in order to run the parts of the commit coordination that block on the local storage engine in a separate thread pool from the Grid's fixed ThreadPoolTaskExecutor. This ticket is to make coordinating the transaction run wholly on the fixed ThreadPoolTaskExecutor on the Grid, and set the size of the thread pool in that ThreadPoolTaskExecutor to unbounded. |
| Comments |
| Comment by Kaloian Manassiev [ 25/Jan/19 ] |
|
Gone away as result of the changes for |
| Comment by Matthew Saltz (Inactive) [ 27/Dec/18 ] |
|
After discussion we've decided to eliminate the TransactionCoordinatorService's ThreadPool and instead use the fixed ThreadPoolTaskExecutor on the Grid for all operations. We'll ramp up the max number of threads on the TaskExecutor to be essentially infinite. |