[SERVER-35906] Decouple the interfaces of the OpObserverRegistry, the generic OpObservers, and the ReplicationOpObserver Created: 28/Jun/18  Updated: 06/Dec/22

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

Type: Task Priority: Major - P3
Reporter: Spencer Brody (Inactive) Assignee: Backlog - Replication Team
Resolution: Unresolved Votes: 0
Labels: former-quick-wins
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-32897 Separate ReplicationOpObserver from O... Backlog
related to SERVER-33116 Split logOp functions out of oplog.cp... Backlog
related to SERVER-33733 Remove all callers of repl::logOp fro... Backlog
Assigned Teams:
Replication
Participants:

 Description   

The ReplicationOpObserver is fundamentally special. It is responsible for generating OpTimes and writing oplog entries. No other OpObserver should ever generate an OpTime or oplog entry. Currently all OpObservers and the OpObserverRegistry implement the OpObserver interface, which includes returning OpTimes for some (but not all) observer methods, even though the majority of OpObservers must not generate optimes and thus always return null optimes.

Rather than trying to coerce these different objects into having the same interface, we should acknowledge that the OpObserverRegistry isn't an OpObserver, and the ReplicationOpObserver is different from all other OpObservers. This would allow the ReplicationOpObserver and the OpObserverRegistry to return OpTimes as needed, without complicating the API for the rest of the generic OpObservers



 Comments   
Comment by Spencer Brody (Inactive) [ 28/Jun/18 ]

This, along with the linked tickets, are part of theme of work around refactoring the OpObserver subsystem. We made some changes to the OpObservers in 4.0 that left them in a bit of a weird state that is difficult to understand. Also transactions and other projects rely heavily on the OpObservers - making them easier to understand, use, and unit test would be a high value improvement to the code base.

Comment by Spencer Brody (Inactive) [ 28/Jun/18 ]

As part of this we should consider if there's still a way to make the compiler enforce that if a method is added to one of the three interfaces that it must be added to the other two as well.

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