[SERVER-41588] We should not expect repl.apply.ops to be the same as repl.apply.batchSize when testing server status metrics Created: 07/Jun/19 Updated: 29/Oct/23 Resolved: 13/Jun/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | 4.2.0-rc2, 4.3.1 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Jason Chan | Assignee: | Jason Chan |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Operating System: | ALL | ||||||||
| Backport Requested: |
v4.2
|
||||||||
| Sprint: | Repl 2019-06-17 | ||||||||
| Participants: | |||||||||
| Linked BF Score: | 14 | ||||||||
| Description |
|
Currently, server_status_metrics.js expects the repl.apply.ops to always be the same as repl.apply.batchSize. This is not always true as we will skip applying operations where the optime is <= the beginApplyingOpTime. |
| Comments |
| Comment by Githook User [ 14/Jun/19 ] |
|
Author: {'name': 'Jason Chan', 'email': 'jason.chan@10gen.com', 'username': 'jasonjhchan'}Message: (cherry picked from commit 2263b578a724e4dea834d648bdb2288edc372e7b) |
| Comment by Githook User [ 13/Jun/19 ] |
|
Author: {'name': 'Jason Chan', 'email': 'jason.chan@10gen.com', 'username': 'jasonjhchan'}Message: |
| Comment by Jason Chan [ 10/Jun/19 ] |
|
suganthi.mani You are correct, the actual metrics are being incremented properly. The issue is that the test always expects repl.apply.ops to be identical to repl.apply.batchSize which it turns out is not the case in initial sync. I will update the ticket description to address this issue. |
| Comment by Suganthi Mani [ 10/Jun/19 ] |
|
jason.chan, I think we missed noticing this earlier. For needToDoUpsert is false, we do increment the repl.apply.ops counter when we are able to successfully commit the storage transaction. Here is where we commit the storage transaction and after which we don't return from the function immediately but go to line 1633 which increments the repl.apply.ops counter. |