[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:
Duplicate
duplicates SERVER-37880 Add in backoff for retrying sending c... Closed
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 SERVER-37880.

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.

Generated at Thu Feb 08 04:48:58 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.