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

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

Activity

People

Dates