[SERVER-21431] Sharding host targeting logic should use the remaining time from the OperationContext as a timeout Created: 12/Nov/15  Updated: 07/Feb/19  Resolved: 07/Feb/19

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: David Storch Assignee: Mathias Stearn
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-38295 ReplSetMonitor::getHostOrRefresh shou... Closed
Sprint: Service Arch 2019-02-11
Participants:

 Description   

Currently RemoteCommandTargeter::selectFindHostMaxWaitTime() will always return a default timeout:

https://github.com/mongodb/mongo/blob/master/src/mongo/client/remote_command_targeter.cpp#L48-L49

This is the timeout which we use when targeting a particular host within a shard. Instead of using a default, we should attach a timeout to the OperationContext (potentially the maxTimeMS value) and use this as the host targeting timeout.



 Comments   
Comment by Mathias Stearn [ 07/Feb/19 ]

Fixed as of https://github.com/mongodb/mongo/commit/aa236ed4f3096c85118f00618eec834c82363527

Comment by Kaloian Manassiev [ 01/Feb/19 ]

redbeard0531, assigning this ticket to you to verify whether it is still applicable with your RSM work.

If it is still needed, please put it on the backlog and leave it in the Epic.

Comment by David Storch [ 12/Nov/15 ]

Done.

Comment by Spencer Brody (Inactive) [ 12/Nov/15 ]

david.storch, can you add a description to this ticket to help us understand the impact and priority of this issue?

Generated at Thu Feb 08 03:57:20 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.