Info

The PeriodicBalancerConfigRefresher puts its PeriodicJob on the ServiceContext's PeriodicRunner, and PeriodicJobs on the ServiceContext's PeriodicRunner can be modified directly by shutdown. The PeriodicBalancerConfigRefresher is also modified on stepdown. Since shutdown and stepdown can occur concurrently, and PeriodicJob has invariants that its methods are called in a specific order, either PeriodicBalancerConfigRefresher needs to add synchronization on top of its PeriodicJob, or PeriodicJob should have more lax invariants.

Top User Comments

esha.maharishi@10gen.com commented on Tue, 19 Mar 2019 14:48:16 +0000: matthew.saltz oh, yes, it is. Closing as a dupe. matthew.saltz commented on Tue, 19 Mar 2019 14:46:21 +0000: I think this is a duplicate of SERVER-38679, which I'm working on already. Marking it as such. esha.maharishi if you want to take a look to verify and make sure I'm not missing something, feel free to do so. kaloian.manassiev commented on Fri, 15 Mar 2019 22:25:51 +0000: Since the PeriodicRunner is a generic server utility, it doesn't seem right to be owned by the sharding team. I am moving this ticket to Service Arch. I remember that matthew.saltz worked on it so if this is a regression from that work we can pick it up, but otherwise I don't want sharding to be supporting it. jason.carey commented on Fri, 15 Mar 2019 20:41:03 +0000: I think it's how it was intended to work (for a first cut, not having to deal with race conditions on the handles is easier to reason about), but I'm okay with loosening things a bit. I'd probably make pause() on a PAUSED task a noop, along with resume() on a RUNNING job, and throw for the other illegal transitions esha.maharishi@10gen.com commented on Fri, 15 Mar 2019 20:26:22 +0000: CC mira.carey@mongodb.com, is this the way PeriodicRunner/PeriodicJobs are intended to work?

Steps to Reproduce