[SERVER-29140] Return 'invalidate' entries and close the cursor on relevant drop, dropDatabase, and renameCollection oplog entries Created: 11/May/17 Updated: 30/Oct/23 Resolved: 09/Aug/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 3.5.12 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Crystal Horn | Assignee: | Siyuan Zhou |
| 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: | Repl 2017-07-31, Repl 2017-08-21 | ||||||||
| Participants: | |||||||||
| Description |
|
If someone was trying to use changeNotifications to keep a cache in sync with changes to a mongodb collection or database, certain operations would cause that cache to need to be invalidated, namely drop, dropDatabase, and renameCollection operations that affect the collection or database that notifications are being received on. When a change notification feed encounters one of those operations it should return an 'invalidate' entry and close the change notification cursor |
| Comments |
| Comment by Githook User [ 10/Aug/17 ] | ||||||||||||||||||||||
|
Author: {'name': 'Siyuan Zhou', 'email': 'siyuan.zhou@mongodb.com'}Message: | ||||||||||||||||||||||
| Comment by Githook User [ 10/Aug/17 ] | ||||||||||||||||||||||
|
Author: {'name': 'Max Hirschhorn', 'email': 'max.hirschhorn@mongodb.com'}Message: Revert " This reverts commit a73070d49470cd0ff1f7d2f5189b59d231e5c9ff. | ||||||||||||||||||||||
| Comment by Githook User [ 09/Aug/17 ] | ||||||||||||||||||||||
|
Author: {'username': 'visualzhou', 'email': 'siyuan.zhou@mongodb.com', 'name': 'Siyuan Zhou'}Message: This reverts commit ddcc982e9b1ecca89fc315d698990176ba73df25. | ||||||||||||||||||||||
| Comment by Siyuan Zhou [ 07/Aug/17 ] | ||||||||||||||||||||||
|
The comparison behavior is surprising to me.
| ||||||||||||||||||||||
| Comment by Siyuan Zhou [ 07/Aug/17 ] | ||||||||||||||||||||||
|
max.hirschhorn, thanks for the debugging! I'm investigating the failure. For the issue of comparison, maybe we should fix assert.neq() as the same as assert.eq() using friendlyEqual()? | ||||||||||||||||||||||
| Comment by Max Hirschhorn [ 04/Aug/17 ] | ||||||||||||||||||||||
|
I reverted the changes from a73070d under ddcc982 due to the jstests/aggregation/sources/changeNotification/change_notification_invalidation.js test consistently failing. See this aggregation task as an example of a failure. On a separate note, siyuan.zhou, I'd be careful about using assert.neq() when comparing a cursor id returned by the server. It'll get deserialized by the mongo shell as a NumberLong instance, so the != in assert.neq() will compare the by-object references (rather than by-value) and always return false. I'd suggest asserting on the return value of bsonWoCompare() or bsonBinaryEqual() to be explicit and work around JavaScript's comparison semantics. | ||||||||||||||||||||||
| Comment by Siyuan Zhou [ 14/Jul/17 ] | ||||||||||||||||||||||
|
We should include a test case where the client is able to resume from an "invalidate" entry. |