[SERVER-26704] Refactor DataReplicator::getLatestOplogEntry() to use _scheduleLastOplogEntryFetcher_inlock() Created: 19/Oct/16  Updated: 05/Apr/17  Resolved: 06/Dec/16

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

Type: Bug Priority: Major - P3
Reporter: Judah Schvimer Assignee: Benety Goh
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-27052 Add asynchronous operation support to... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Repl 2016-12-12
Participants:

 Description   

Currently getLatestOplogEntry is synchronous and its callback handle is not held onto and thus not cancellable. Refactoring it would make it cancellable.



 Comments   
Comment by Benety Goh [ 06/Dec/16 ]

This function was removed as part of SERVER-27052

Comment by Scott Hernandez (Inactive) [ 24/Oct/16 ]

I'm not sure what was discussed in person but simply replacing getLatestOplogEntry with a version that does _scheduleLastOplogEntryFetcher_inlock and waits, would be a drop-in replacement without needing to changing _doInitialSync (or really _runInitialSyncAttempt_inlock) in any way, and would be cancelable (at DR shutdown) and more testable.

Comment by Judah Schvimer [ 24/Oct/16 ]

Per my discussion with benety.goh, I think the best solution would be to make it completely asynchronous with _scheduleLastOplogEntryFetcher_inlock(). This will make the code slightly more confusing because it breaks up the _doInitialSync function considerably, but will be best for testing and safest.

Comment by Benety Goh [ 24/Oct/16 ]

In either case, we are lacking test coverage for the code that fetches the latest oplog entry. In 3.4, there's no way to cancel/interrupt this operation because the task executor is shutdown after the DataReplicator is destroyed.

Comment by Judah Schvimer [ 24/Oct/16 ]

We definitely could and I think it would be just as good as the TaskExecutor version, but the TaskExecutor version already exists so it might be easier just to use that one. benety.goh, do you have any thoughts on this?

Comment by Andy Schwerin [ 19/Oct/16 ]

Could we change its implementation to not use task executor if it's synchronous?

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