[SERVER-2998] mongos does not guarantee ordering between getmores and unchecked write operations run on the same connection Created: 26/Apr/11  Updated: 12/Dec/23

Status: Backlog
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: features we're not sure of

Type: Question Priority: Major - P3
Reporter: Aaron Staple Assignee: Backlog - Cluster Scalability
Resolution: Unresolved Votes: 0
Labels: RachitaD
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Cluster Scalability
Participants:

 Description   

For example:

c = t.find( {$or:[

{a:2}

,

{b:3}

,

{c:4}

]} ).batchSize( 2 );
c.next();
t.remove(

{b:3}

);
assert.eq.automsg( "3", c.itcount() );

The first getmore, caused by itcount(), may happen either before or after the remove if mediated by mongos. The following workaround is currently needed:

c = t.find( {$or:[

{a:2}

,

{b:3}

,

{c:4}

]} ).batchSize( 2 );
c.next();
t.remove(

{b:3}

);
db.getLastError();
assert.eq.automsg( "3", c.itcount() );

Here is an example logging expected behavior from the above script:

m30001| Mon Apr 25 23:31:42 [conn4] query test.jstests_or5 ntoreturn:2 reslen:102 nreturned:2 0ms
m30001| Mon Apr 25 23:31:42 [conn4] remove test.jstests_or5 query:

{ b: 3.0 }

0ms
m30001| Mon Apr 25 23:31:42 [conn8] getmore test.jstests_or5 cid:4546250274389464629 ntoreturn:2 getMore: { $or: [

{ a: 2.0 }

,

{ b: 3.0 }

,

{ c: 4.0 }

] } bytes:86 nreturned:2 0ms
m30001| Mon Apr 25 23:31:42 [conn8] getmore test.jstests_or5 cid:4546250274389464629 ntoreturn:2 getMore: { $or: [

{ a: 2.0 }

,

{ b: 3.0 }

,

{ c: 4.0 }

] } bytes:20 nreturned:0 0ms

Here is an example of unexpected behavior that sometimes occurs:

m30001| Mon Apr 25 23:11:51 [conn4] query test.jstests_or5 ntoreturn:2 reslen:102 nreturned:2 0ms
m30001| Mon Apr 25 23:11:51 [conn8] getmore test.jstests_or5 cid:5426795093500586304 ntoreturn:2 getMore: { $or: [

{ a: 2.0 }

,

{ b: 3.0 }

,

{ c: 4.0 }

] } bytes:86 nreturned:2 0ms
m30001| Mon Apr 25 23:11:51 [conn8] getmore test.jstests_or5 cid:5426795093500586304 ntoreturn:2 getMore: { $or: [

{ a: 2.0 }

,

{ b: 3.0 }

,

{ c: 4.0 }

] } bytes:86 nreturned:2 0ms
m30001| Mon Apr 25 23:11:51 [conn8] getmore test.jstests_or5 cid:5426795093500586304 ntoreturn:2 getMore: { $or: [

{ a: 2.0 }

,

{ b: 3.0 }

,

{ c: 4.0 }

] } bytes:20 nreturned:0 0ms
m30001| Mon Apr 25 23:11:51 [conn4] remove test.jstests_or5 query:

{ b: 3.0 }

0ms

As far as I know there is a single connection from mongo to mongos in these examples, but there seem to be two connections from mongos to mongod and this causes the unexpected operation ordering.



 Comments   
Comment by Eliot Horowitz (Inactive) [ 27/Apr/11 ]

@andrew, no, it doesn't violate read your own writes. writes after an initial query before other getMore calls might not be seen, but you can't rely on that since you don't know the batch sizes, etc...
the actual query is guaranteed on the same connection

Comment by Andrew Armstrong [ 27/Apr/11 ]

I'm not sure if this is entirely related to the problem, but I know from experience with MySQL in the past that without explicitly providing an 'order by' clause, if you attempt to page this result set (such as LIMIT 0, 20..., LIMIT 20, 20, ....) you may re-read previous records because the underlying data has changed (or just happened to be fetched differently on your second query), so paging an unordered result set (like your above example) has undefined behavior I suppose.

Our fix for that particular problem was to simply just order by an id field (something consistent that was indexed) which then did provide consistent behavior.

PS: Isn't your example violating the 'read your own writes' property that is currently expected?

Cheers

Comment by Aaron Staple [ 26/Apr/11 ]

Just wanted to add a note that we've seen similar behavior with ordering between an unchecked write and an admin command. Apparently the admin commands use a separate connection from mongos to mongod.

Comment by Eliot Horowitz (Inactive) [ 26/Apr/11 ]

Ithink its as designed.
The only reason it came up is that there were tests that relied on ordering, and mongos doesn't guarantee.

Comment by Dwight Merriman [ 26/Apr/11 ]

it's normal for getmores to be lazy, so i wonder, is this actually a problem or works as designed?

Comment by auto [ 26/Apr/11 ]

Author:

{u'login': u'astaple', u'name': u'Aaron', u'email': u'aaron@10gen.com'}

Message: SERVER-2998 workarounds
Branch: master
https://github.com/mongodb/mongo/commit/ef0cae716fe0a1433ec7531ffa1a4f746d8336c4

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