-
Type: Bug
-
Resolution: Done
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Aggregation Framework
-
None
-
ALL
The aggregate command takes a read lock for the duration of its operation. This lock may be yielded when the source Cursor is advanced (and is only yielded in this case I believe).
A sort or group stage in the pipeline will read all the results of its own source before generating its own first result. This means that yielding will not occur after the first sort or group stage of the pipeline returns its first result.
Test
c = db.c; c.drop(); // Insert a million docs. for( i = 0; i < 1*1000*1000; ++i ) { c.save( { a:i, b:i, c:i } ); } db.getLastError(); print( "saved" ); // Run a pipeline with a large sort and some time consuming steps after it. printjson( c.aggregate( { $sort:{ a:1 } }, { $project:{ d:{ $add:[ '', '$a', '.', { $multiply:[ '$a', '$b' ] }, '.', { $multiply:[ '$a', '$b', '$c' ] } ] } } }, { $limit:10 } ) );
You can observe a long lived read lock by attempting periodic writes from a separate client.
Observed behavior: An aggregate command may hold a read lock for a prolonged interval without yielding.
Expected behavior: An aggregate command should only hold a read lock when necessary to read documents or access other shared state.
- is related to
-
SERVER-6286 deadlock between db mutex and sm mutex
- Closed
-
SERVER-5089 aggregation needs to yield
- Closed
- related to
-
SERVER-6296 improve aggregation framework concurrency implementation
- Closed