Loading...

XML

Word

Printable

JSON

Type: Bug
Resolution: Fixed
Priority: Major - P3
Fix Version/s: 4.1.7
Affects Version/s: None
Component/s: Sharding
Labels:

Backwards Compatibility:
Fully Compatible
Operating System:
ALL
Sprint:
Sharding 2019-01-14, Sharding 2019-01-28
Linked BF Score:
0
Confidence Status:
None
Work Order:
3
CAR Domain/s:
None

Aha! Reference:
None
Tracking Level:
None
Risk Status:
None
Exec Notes:
None
Goal Name(s):
None
Goal Link:
None

Right now, if a commit, abort, or prepare message to a transaction participant fails, we retry immediately. It might be worth adding some sort of backoff so that we slow down retries if they keep failing. Same goes for targeting a shard in the coordinator code.

is duplicated by

SERVER-38798 shard registry busy-loops in commitTransaction

Closed

SERVER-38444 Coordinating a transaction should run fully in the ThreadPoolTaskExecutor for sharding tasks

Closed

SERVER-38795 Add test that if coordinator fails to target host in participant shard, coordinator schedules a retry attempt

Closed

SERVER-38881 Use ThreadClient rather than onCreateThread to create Clients for work done by TransactionCoordinatorService

Closed

Assignee:: Kaloian Manassiev
Reporter:: Matthew Saltz (Inactive)
Participants:: Githook User, Kaloian Manassiev, Matthew Saltz
Votes:: 0 Vote for this issue
Watchers:: 4 Start watching this issue

Created:: Nov 01 2018 09:59:50 PM UTC
Updated:: Oct 29 2023 10:26:57 PM UTC
Resolved:: Jan 16 2019 02:50:36 PM UTC

Details

Description

Attachments

Issue Links

Forms

Activity

People

Dates