[SERVER-38128] Create a periodic task associated with the KV engine to notify listeners of stable/oldest/checkpointed timestamp changes Created: 14/Nov/18 Updated: 29/Oct/23 Resolved: 12/Dec/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | 4.1.7 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Dianna Hohensee (Inactive) | Assignee: | Gregory Wlodarek |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Sprint: | Storage NYC 2018-12-03, Storage NYC 2018-12-17 | ||||||||
| Participants: | |||||||||
| Description |
|
This periodic task should only be registered to run if the storage engine supports timestamps. |
| Comments |
| Comment by Githook User [ 12/Dec/18 ] |
|
Author: {'name': 'Gregory Wlodarek', 'email': 'gregory.wlodarek@mongodb.com', 'username': 'GWlodarek'}Message: |
| Comment by Githook User [ 12/Dec/18 ] |
|
Author: {'name': 'Gregory Wlodarek', 'email': 'gregory.wlodarek@mongodb.com', 'username': 'GWlodarek'}Message: |
| Comment by Githook User [ 12/Dec/18 ] |
|
Author: {'name': 'Gregory Wlodarek', 'email': 'gregory.wlodarek@mongodb.com', 'username': 'GWlodarek'}Message: |
| Comment by Githook User [ 12/Dec/18 ] |
|
Author: {'name': 'Gregory Wlodarek', 'email': 'gregory.wlodarek@mongodb.com', 'username': 'GWlodarek'}Message: |
| Comment by Andy Schwerin [ 14/Nov/18 ] |
|
That makes sense. I think that as long as the system isn’t used to advertise timestamps that could roll back, asynchronous reporting would work |
| Comment by Dianna Hohensee (Inactive) [ 14/Nov/18 ] |
|
The idea is that we have operations that need to wait for a certain timestamp to be reached before acting, in a lazy manner, which I think is alright but haven't thought out all the way. Storage wants it for things like two-phase collection and index drops. Once the timestamp of the first phase of a drop reaches some safe persistence guarantee, we trigger the second phase of the drop. I'm not sure on the design yet. One of my thoughts was a periodic task, since we don't need an instant response, that updates some state about what the timestamps were at the last check and notifies any caller waiting on an update – say a shared condition variable or something akin to that. The design is up to this ticket to figure out. |
| Comment by Andy Schwerin [ 14/Nov/18 ] |
|
Who are the listeners, and how frequently do they need to be notified? |