[SERVER-5220] Assertion error with data sets being in same order on master and slave during drop_dups.js test Created: 06/Mar/12  Updated: 11/Jul/16  Resolved: 03/Apr/12

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: 2.0.5, 2.1.1

Type: Bug Priority: Major - P3
Reporter: Ian Whalen (Inactive) Assignee: Eric Milkie
Resolution: Done Votes: 0
Labels: buildbot
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

V2.0 Linux 64-bit Legacy


Issue Links:
Duplicate
is duplicated by SERVER-5430 Intermittent failure with array order... Closed
Operating System: ALL
Participants:

 Description   

http://buildbot.mongodb.org/builders/V2.0%20Linux%2064-bit%20Legacy/builds/187/steps/test_6/logs/stdio



 Comments   
Comment by auto [ 17/Apr/12 ]

Author:

{u'login': u'milkie', u'name': u'Eric Milkie', u'email': u'milkie@10gen.com'}

Message: SERVER-5220 removing unreliable '64bit-only' check
Branch: v2.0
https://github.com/mongodb/mongo/commit/30f515ac163e4b930fd7c65703d6cab5f7b1a96a

Comment by Ian Whalen (Inactive) [ 26/Mar/12 ]

Reopening as issue does not appear to have been backported; it just showed up on he V2.0 64bit RHEL build: http://buildbot.mongodb.org/builders/V2.0%20Linux%20RHEL%2064-bit/builds/50/steps/test_11/logs/stdio

Comment by auto [ 12/Mar/12 ]

Author:

{u'login': u'milkie', u'name': u'Eric Milkie', u'email': u'milkie@10gen.com'}

Message: SERVER-5220 removing unreliable '64bit-only' check
Branch: master
https://github.com/mongodb/mongo/commit/4e202ec5bfeff036ff42274e1594dcb82a74e942

Comment by Eric Milkie [ 06/Mar/12 ]

There is a race in this test; it assumes that it can insert two objects on both the master and the slave before replication has enough time to replicate the inserted data. If you just run each line of the test by hand in a mongo process, you will always hit this error.
I think we should just remove the assertion check for ordering (it's only checking on 64-bit platforms right now; I assume this is because it was too slow on 32-bit builds to pass reliably?)
Should this be backported to 2.0? It's a very easy change.

Generated at Thu Feb 08 03:08:15 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.