[SERVER-28019] shard version not ok: version epoch mismatch detected Created: 15/Feb/17  Updated: 31/May/17  Resolved: 02/May/17

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 3.2.10, 3.4.2
Fix Version/s: None

Type: Bug Priority: Critical - P2
Reporter: Steffen Assignee: Kelsey Schubert
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File app-0_mongodb-router-27017.log     Text File app-1_mongodb-router-27017.log     Text File mongs-3_mongodb-shard.log     Text File mongs-4_mongodb-shard.log    
Issue Links:
Duplicate
duplicates SERVER-27286 Cluster find command with batchSize o... Closed
Operating System: ALL
Participants:

 Description   

System information

PHP 7.0.15-1+deb.sury.org~trusty+1 (cli) (built: Jan 20 2017 09:16:11) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
    with Zend OPcache v7.0.15-1+deb.sury.org~trusty+1, Copyright (c) 1999-2017, by Zend Technologies
 
pecl mongodb   1.2.5
mongodb 3.4.2
Ubuntu 14.04.5
Linux 3.13.0-100-generic #147-Ubuntu SMP Tue Oct 18 16:48:51 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

We run a cluster with 27 shards and each application uses a local mongos to connect to it. We have the balancer stopped.

We often see Exception for querys to collections which are sharded. Everytime there is a change to shard version of the collection, our PHP clients report an error on a simple find operation. Sofar we have never seen an exception for our non PHP clients.
It seems that this issue was introduced with mongodb version 3.2.x, but we can also reproduce it on 3.4.2 in our dev environment.

To reproduce it in our dev environemnt I started to shard a collection, but I could also move a chunk or split a chunk. I choose this collection because we see problems for querys to this collection in production which runs version 3.2.10 and we hadn't sharded it in our dev environment so far (very small in dev).
There are no errors in router.log

Before we sharded the collection our PHP application showed no errors.
After sharding our PHP client reports:

[data.items] shard version not ok: version epoch mismatch detected for data.items, the collection may have been dropped and recreated ( ns : data.items, received : 0|0||000000000000000000000000, wanted : 1|0||58a46d88be4b4925a7638e2f, send ) /path/to/code/vendor/php/mongodb/Find.php (206) MongoDB\Driver\Server::executeQuery

Stacktrace:

[23]
File:      /path/to/code/src/model/dfp/connectors/mdb/MdbLineItemConnector.php in line 68
Method:    rg\ODM\MongoDB\Cursor->toArray
 
[24]
File:      /path/to/code/vendor/composer/rg/mongodb-odm-light/lib/rg/ODM/MongoDB/Cursor.php in line 277
Method:    Doctrine\MongoDB\Cursor->toArray
Parameter: [true]
 
[25]
File:      /path/to/code/vendor/composer/rg/mongodb-odm-light/lib/Doctrine/MongoDB/Cursor.php in line 629
Method:    Doctrine\MongoDB\Cursor->retry
Parameter: [Closure, true]
 
[26]
File:      /path/to/code/vendor/composer/rg/mongodb-odm-light/lib/Doctrine/MongoDB/Cursor.php in line 666
Method:    Doctrine\MongoDB\Cursor->Doctrine\MongoDB\{closure}
 
[27]
File:      /path/to/code/vendor/composer/rg/mongodb-odm-light/lib/Doctrine/MongoDB/Cursor.php in line 628
Parameter: [rg\core\base\objectManagers\mongodb\LoggingCursor]
 
[28]
Method:    rg\core\base\objectManagers\mongodb\LoggingCursor->rewind
 
[29]
File:      /path/to/code/src/core/base/objectManagers/mongodb/LoggingCursor.php in line 253
Method:    Doctrine\MongoDB\Cursor->rewind
 
[30]
File:      /path/to/code/vendor/composer/rg/mongodb-odm-light/lib/Doctrine/MongoDB/Cursor.php in line 490
Method:    Doctrine\MongoDB\Cursor->retry
Parameter: [Closure, false]
 
[31]
File:      /path/to/code/vendor/composer/rg/mongodb-odm-light/lib/Doctrine/MongoDB/Cursor.php in line 666
Method:    Doctrine\MongoDB\Cursor->Doctrine\MongoDB\{closure}
 
[32]
File:      /path/to/code/vendor/composer/rg/mongodb-odm-light/lib/Doctrine/MongoDB/Cursor.php in line 489
Method:    Alcaeus\MongoDbAdapter\AbstractCursor->rewind
 
[33]
File:      /path/to/code/vendor/composer/alcaeus/mongo-php-adapter/lib/Alcaeus/MongoDbAdapter/AbstractCursor.php in line 190
Method:    Alcaeus\MongoDbAdapter\AbstractCursor->ensureIterator
 
[34]
File:      /path/to/code/vendor/composer/alcaeus/mongo-php-adapter/lib/Alcaeus/MongoDbAdapter/AbstractCursor.php in line 297
Method:    MongoCursor->ensureCursor
 
[35]
File:      /path/to/code/vendor/composer/alcaeus/mongo-php-adapter/lib/Mongo/MongoCursor.php in line 443
Method:    MongoCursor->doQuery
 
[36]
File:      /path/to/code/vendor/composer/alcaeus/mongo-php-adapter/lib/Mongo/MongoCursor.php in line 166
Method:    MongoDB\Collection->find
Parameter: [MongoDB\Model\BSONDocument: ['o' => MongoDB\Model\BSONDocument: ['$in' => ['0' => 123456, '1' => 275383959000, '2' => 114204279, '3' => 233433999, '4' => 233014719, '5' => 237809079, '6' => 247189479, '7' => 251772159, '8' => 260437839, '9' => 275383959, '10' => 285140199, [10more ...]]], '$comment' => 'cId f8688c0e3b4b6de7b86d0c38569fb290,vId 165...'], ['batchSize' => 0, 'modifiers' => [], 'projection' => [], 'readPreference' => MongoDB\Driver\ReadPreference, 'readConcern' => MongoDB\Driver\ReadConcern, 'typeMap' => ['array' => 'MongoDB\Model\BSONArray', 'document' => 'MongoDB\Model\BSONDocument', 'root' => 'MongoDB\Model\BSONDocument']]]
 
[37]
File:      /path/to/code/vendor/composer/mongodb/mongodb/src/Collection.php in line 525
Method:    MongoDB\Operation\Find->execute
Parameter: [MongoDB\Driver\Server: [MongoDB\Driver\Server Object
(
    [host] => localhost
    [port] => 27017
    [type] => 2
    [is_primary] => 
    [is_secondary] => 
    [is_arbiter] => 
    [is_hidden] => 
    [is_passive] => 
    [last_is_master] => Array
        (
            [ismaster] => 1
            [msg] => isdbgrid
            [maxBsonObjectSize] => 16777216
            [maxMessageSizeBytes] => 48000000
            [maxWriteBatchSize] => 1000
            [localTime] => MongoDB\BSON\UTCDateTime Object
                (
                    [milliseconds] => 1487171166812
                )
 
            [maxWireVersion] => 5
            [minWireVersion] => 0
            [ok] => 1
        )
 
    [round_trip_time] => 0
)
]]
 
[38]
File:      /path/to/code/vendor/php/mongodb/Find.php in line 206
Method:    MongoDB\Driver\Server->executeQuery
Parameter: ['data.items', MongoDB\Driver\Query, MongoDB\Driver\ReadPreference]

To fix the router reporting this exception on a query we found 3 ways:

  • restart router
  • flushRouterConfig
  • do a find query on this collection via mongo shell. (tested with version 3.4.2 only)

Could it be that routers only trigger chunk information updates when a client does an operation on a collection? -> this is broken for php driver only?

Since we can reproduce it in our dev environment with version 3.4.2, we our glad to debug this with your help.

This is a blocker for us in production since even the balancer is off, autosplits also cause this issue.



 Comments   
Comment by Steffen [ 27/Apr/17 ]

With new version we don't have this issue anymore.

Comment by Andreas B. [ 27/Apr/17 ]

Thanks jmikola for bringing me into the loop. I've released 1.0.11 for the adapter library which fixes what seems to be the root cause of this.

Comment by Jeremy Mikola [ 25/Apr/17 ]

Cross-linking with an upstream issue on alcaeus/mongo-php-adapter#170 to address a batchSize of zero appearing in find commands.

Comment by Jeremy Mikola [ 25/Apr/17 ]

Quoting an analysis from esha.maharishi:

Ah, so the issue is that the find is being issued with a batchSize=0, and it's a known issue that issuing a find with batchSize=0 against mongos in versions before 3.5.6 delays actually contacting the shards until data is requested through getMore (SERVER-27286).

Then, because the getMore command on mongos does not handle retrying on stale version errors (and the error is bubbled up as an error status rather than an exception, so it is not caught by the stale version retry loop in Strategy::clientCommandOp), the error is bubbled all the way back up to the client. This is why the PHP driver is seeing the error.

...

Until then, a fix for users could be to not issue finds with batchSize=0 (does the PHP driver automatically do this?).

The batchSize issue is described in more detail in this comment in SERVER-27286.

As for PHP, neither the driver nor libmongoc set batchSize on the find command by default. That said, the stack trace in the OP includes the community-developed mongo-php-adapter library, which implements the legacy ext-mongo driver API for the newer ext-mongodb driver. This may be supplying a default value based on the following code:

Since the $batchSize property defaults to 0 instead of null, I believe it's included in the options passed to MongoDB\Collection::find() in our library, which will include the option when the driver and libmongoc issue the find command. An immediate work-around may be to patch the default value to 0 until the adapter library can address this. That's likely easier than explicitly specifying a null batchSize through all of your ODM queries.

Comment by Esha Maharishi (Inactive) [ 25/Apr/17 ]

Ah, so the issue is that the find is being issued with a batchSize=0, and it's a known issue that issuing a find with batchSize=0 against mongos in versions before 3.5.6 delays actually contacting the shards until data is requested through getMore (SERVER-27286).

Then, because the getMore command on mongos does not handle retrying on stale version errors (and the error is bubbled up as an error status rather than an exception, so it is not caught by the stale version retry loop in Strategy::clientCommandOp), the error is bubbled all the way back up to the client. This is why the PHP driver is seeing the error.

I'm posting a walk through of steffen's logs in a developer-only comment below this, to keep the logs private.

I can think of a couple fixes:

  • re-triage the backports for SERVER-27286 from 'won't fix', since it still seems to be causing issues
  • re-triage SERVER-28943 to make the shard re-check the version after it refreshes (and backport it...)
  • put a band-aid in for 3.4 (and maybe 3.2) to make mongos's getMore throw on stale version errors, so that the exception is caught by the retry loop in Strategy::clientCommandOp and the command is re-tried

kaloian.manassiev, david.storch?

Until then, a fix for users could be to not issue finds with batchSize=0 (does the PHP driver automatically do this?).

Comment by Esha Maharishi (Inactive) [ 25/Apr/17 ]

Thanks steffen, anonymous.user for the quick response, taking a look at these now.

Comment by Steffen [ 25/Apr/17 ]

I uploaded some logs.
Collection: dfp.lineItems

Timeline:
2017-04-25T06:48:24.990 moveChunk via router master-1

2017-04-25T06:51:07 query on dfp.lineItems via php driver on router app-0
->

RequirementException: MongoException: [dfp.lineItems] shard version not ok: version mismatch detected for dfp.lineItems ( ns : dfp.lineItems, received : 18|0||58a46d88be4b4925a7638e2f, wanted : 17|1||58a46d88be4b4925a7638e2f, send ) in /vendor/composer/alcaeus/mongo-php-adapter/lib/Alcaeus/MongoDbAdapter/ExceptionConverter.php (83) when fullfilling requirement [lineItems] in [rg\modules\adminads\actions\AdCampaignListItem]

Comment by Kelsey Schubert [ 25/Apr/17 ]

Hi Steffen,

I've created a secure upload portal. Files uploaded to this portal are visible only to MongoDB employees and are routinely deleted after some time.

Thank you,
Thomas

Comment by Steffen [ 25/Apr/17 ]

Where can I upload the logs and keep them private?

Comment by Esha Maharishi (Inactive) [ 24/Apr/17 ]

So I can see that a shard returns the same stale version error in 3.4 by issuing a find from a stale mongos after moving the (only) chunk out of a shard, but mongos is supposed to (and seems to) retry up to 10 times after getting the error:

// stale mongos refreshes its chunks
[js_test:test] 2017-04-24T10:52:22.556-0400 s15513| 2017-04-24T10:52:22.556-0400 I SHARDING [conn1] Refreshing chunks for collection test.foo based on version 1|0||58fe11257b31e29c057ad03c
[js_test:test] 2017-04-24T10:52:22.563-0400 s15513| 2017-04-24T10:52:22.563-0400 I SHARDING [CatalogCacheLoader-0] Refresh for collection test.foo took 7 ms and found version 2|0||58fe11257b31e29c057ad03c
 
// donor shard throws because its expected version is 0|0; it does a refresh just before sending the response back to mongos
[js_test:test] 2017-04-24T10:52:22.568-0400 d15511| 2017-04-24T10:52:22.568-0400 I SHARDING [conn13] Refreshing chunks for collection test.foo based on version 1|0||58fe11257b31e29c057ad03c
[js_test:test] 2017-04-24T10:52:22.576-0400 d15511| 2017-04-24T10:52:22.575-0400 I SHARDING [CatalogCacheLoader-0] Refresh for collection test.foo took 7 ms and found version 2|0||58fe11257b31e29c057ad03c
[js_test:test] 2017-04-24T10:52:22.576-0400 d15511| 2017-04-24T10:52:22.576-0400 I SHARDING [conn13] Refreshing metadata for collection test.foo from collection version: 1|0||58fe11257b31e29c057ad03c, shard version: 0|0||58fe11257b31e29c057ad03c to collection version: 2|0||58fe11257b31e29c057ad03c, shard version: 2|0||58fe11257b31e29c057ad03c
 
// stale mongos receives "shard version not ok, the collection may have been dropped":
[js_test:test] 2017-04-24T10:52:22.577-0400 s15513| 2017-04-24T10:52:22.576-0400 D QUERY    [conn1] Received error status for query query: { _id: 6.0 } sort: {} projection: {} on attempt 1 of 10: SendStaleConfig: [test.foo] shard version not ok: this shard no longer contains chunks for test.foo, the collection may have been dropped ( ns : test.foo, received : 2|0||58fe11257b31e29c057ad03c, wanted : 0|0||58fe11257b31e29c057ad03c, send )
 
// stale mongos refreshes again, finds the same collection version, and then succeeds in doing the find
[js_test:test] 2017-04-24T10:52:22.577-0400 s15513| 2017-04-24T10:52:22.577-0400 I SHARDING [conn1] Refreshing chunks for collection test.foo based on version 2|0||58fe11257b31e29c057ad03c
[js_test:test] 2017-04-24T10:52:22.584-0400 s15513| 2017-04-24T10:52:22.584-0400 I SHARDING [CatalogCacheLoader-0] Refresh for collection test.foo took 7 ms and found version 2|0||58fe11257b31e29c057ad03c

What I don't understand is why the mongos doesn't seem to be retrying the find internally in the reporter's case (in my repro, note how mongos logs "on attempt 1 of 10: SendStaleConfig" and then retries).

That line is logged at level 1 by mongos; steffen and crashdgc@gmail.com, would you be able to send logs from a repro using verbosity level 3 for both mongos and the shards? (Log level 3 will allow us to additionally see every network request being sent out from mongos).

Comment by Steffen [ 24/Apr/17 ]

And tested with 3.4.4 -> still a BIG issue.

Comment by Steffen [ 19/Apr/17 ]

Also happening with mongodb version 3.4.3 nad php mongodb 1.2.8.

Comment by ANDREY SHATOKHIN [ 05/Apr/17 ]

1. we use default (primary) read preference.
2. Complete log here https://www.dropbox.com/s/7mq504n1f62dfrw/mongodb_logs.zip?dl=0

Comment by Kelsey Schubert [ 04/Apr/17 ]

Hi crashdgc@gmail.com,

We're continuing to continuing to investigate. Would you please answer the same questions as above?

  1. Would you please clarify which read preference you are using for your find commands?
  2. Would you please provide the complete mongod log files of a primary in the cluster and an affected mongos?

This will help us determine which systems may be affected.

Thank you,
Thomas

Comment by ANDREY SHATOKHIN [ 30/Mar/17 ]

we have same error on versions 3.4.2 and 3.4.3

Client error:

[database.comments] shard version not ok: this shard no longer contains chunks for database.comments, the collection may have been dropped ( ns : database.comments, received : 2|0||58dcc0d9ce84cfb999bbdace, wanted : 0|0||58dcc0d9ce84cfb999bbdace, send ) with code: 13388

From mongos.log

2017-03-30T08:28:24.067+0000 I SHARDING [conn42] autosplitted database.comments chunk: shard: rs1, lastmod: 1|0||58dcc0d9ce84cfb999bbdace, [{ post_id: MinKey }, { post_id: MaxKey }) into 3 parts (splitThreshold 921)
2017-03-30T08:28:24.067+0000 I SHARDING [conn42] ChunkManager loading chunks for database.comments sequenceNumber: 30 based on: 1|0||58dcc0d9ce84cfb999bbdace
2017-03-30T08:28:24.068+0000 I SHARDING [conn42] ChunkManager load took 0 ms and found version 1|3||58dcc0d9ce84cfb999bbdace
2017-03-30T08:28:24.172+0000 I SHARDING [conn42] ChunkManager loading chunks for database.comments sequenceNumber: 31 based on: 1|3||58dcc0d9ce84cfb999bbdace
2017-03-30T08:28:24.173+0000 I SHARDING [conn42] ChunkManager load took 0 ms and found version 2|1||58dcc0d9ce84cfb999bbdace

From shard-2/repl-1/mongod.log

2017-03-30T08:28:24.103+0000 I INDEX    [migrateThread] build index done.  scanned 0 total records. 0 secs
2017-03-30T08:28:24.104+0000 I SHARDING [migrateThread] Deleter starting delete for: database.comments from { post_id: MinKey } -> { post_id: ObjectId('58dcc143ffc154015839827e') }, with opId: 2624
2017-03-30T08:28:24.105+0000 I SHARDING [migrateThread] rangeDeleter deleted 0 documents for database.comments from { post_id: MinKey } -> { post_id: ObjectId('58dcc143ffc154015839827e') }
2017-03-30T08:28:24.145+0000 I SHARDING [migrateThread] Waiting for replication to catch up before entering critical section
2017-03-30T08:28:24.146+0000 I SHARDING [migrateThread] migrate commit succeeded flushing to secondaries for 'database.comments' { post_id: MinKey } -> { post_id: ObjectId('58dcc143ffc154015839827e') }
2017-03-30T08:28:24.156+0000 I SHARDING [migrateThread] migrate commit succeeded flushing to secondaries for 'database.comments' { post_id: MinKey } -> { post_id: ObjectId('58dcc143ffc154015839827e') }
2017-03-30T08:28:24.156+0000 I SHARDING [migrateThread] about to log metadata event into changelog: { _id: "e3a45e0f8486-2017-03-30T08:28:24.156+0000-58dcc1a808b7b342b963e741", server: "e3a45e0f8486", clientAddr: "", time: new Date(1490862504156), what: "moveChunk.to", ns: "database.comments", details: { min: { post_id: MinKey }, max: { post_id: ObjectId('58dcc143ffc154015839827e') }, step 1 of 6: 14, step 2 of 6: 39, step 3 of 6: 1, step 4 of 6: 0, step 5 of 6: 11, step 6 of 6: 0, note: "success" } }
2017-03-30T08:28:24.249+0000 I SHARDING [conn41] MetadataLoader loading chunks for database.comments based on: 1|3||58dcc0d9ce84cfb999bbdace
2017-03-30T08:28:24.250+0000 I SHARDING [conn41] Refreshing metadata for collection database.comments from collection version: 1|3||58dcc0d9ce84cfb999bbdace, shard version: 0|0||58dcc0d9ce84cfb999bbdace to collection version: 2|1||58dcc0d9ce84cfb999bbdace, shard version: 2|0||58dcc0d9ce84cfb999bbdace
2017-03-30T08:28:24.250+0000 I SHARDING [conn41] MetadataLoader took 1 ms and found version 2|1||58dcc0d9ce84cfb999bbdace

Comment by Steffen [ 22/Feb/17 ]

We started a chunk balance at
2017-02-22T11:03:38
for collection "dfp.lineItems" on router app-0.

sh.moveChunk("dfp.lineItems", { "o" : { MinKey : 1 }, "_id" : { MinKey : 1 } }, 'shard0001')

Php application showed Exceptions now on both app routers.

ReadPreference is PrimaryPreferred.

Primarys:
mongs-4 is sending
mongs-3 is receiving

Comment by Kelsey Schubert [ 21/Feb/17 ]

Hi steffen,

Thanks for reporting this issue, we're investigating and have a couple questions to help us better understand what is going on here.

  1. Would you please clarify which read preference you are using for your find commands?
  2. Would you please provide the complete mongod log files of a primary in the cluster and an affected mongos?

Thank you for your help,
Thomas

Comment by Steffen [ 16/Feb/17 ]

We did another test to show you, that it's not related to a collection just being sharded.

Setup: Our PHP applciation runs on 2 nodes (app-0 and app-1). Each with a mongo router.
Collection is sharded no errors since routers are up2date.
On app-1 we connect to the router and move the chunk of this collection via:

sh.moveChunk("data.items", { "o" : { MinKey : 1 }, "_id" : { MinKey : 1 } }, 'shard0002')

This is succesfull.
Now we call my php application (web page via php7-fpm) to use app-0 or app-1.
Result is, that app-1 has no issues but app-0, which didn't do the chunk move, shows again exception in PHP application.

[data.items] shard version not ok: this shard no longer contains chunks for data.items, the collection may have been dropped ( ns : data.items, received : 1|0||58a46d88be4b4925a7638e2f, wanted : 0|0||58a46d88be4b4925a7638e2f, send ) /path/to/code/vendor/composer/alcaeus/mongo-php-adapter/lib/Alcaeus/MongoDbAdapter/ExceptionConverter.php (83) Alcaeus\MongoDbAdapter\ExceptionConverter::toLegacy
 
Stacktrace:
[snip]
 
[23]
File:      /path/to/code/src/model/dfp/connectors/mdb/MdbLineItemConnector.php in line 68
Method:    rg\ODM\MongoDB\Cursor->toArray
 
[24]
File:      /path/to/code/vendor/composer/rg/mongodb-odm-light/lib/rg/ODM/MongoDB/Cursor.php in line 277
Method:    Doctrine\MongoDB\Cursor->toArray
Parameter: [true]
 
[25]
File:      /path/to/code/vendor/composer/rg/mongodb-odm-light/lib/Doctrine/MongoDB/Cursor.php in line 629
Method:    Doctrine\MongoDB\Cursor->retry
Parameter: [Closure, true]
 
[26]
File:      /path/to/code/vendor/composer/rg/mongodb-odm-light/lib/Doctrine/MongoDB/Cursor.php in line 666
Method:    Doctrine\MongoDB\Cursor->Doctrine\MongoDB\{closure}
 
[27]
File:      /path/to/code/vendor/composer/rg/mongodb-odm-light/lib/Doctrine/MongoDB/Cursor.php in line 628
Parameter: [rg\core\base\objectManagers\mongodb\LoggingCursor]
 
[28]
Method:    rg\core\base\objectManagers\mongodb\LoggingCursor->rewind
 
[29]
File:      /path/to/code/src/core/base/objectManagers/mongodb/LoggingCursor.php in line 253
Method:    Doctrine\MongoDB\Cursor->rewind
 
[30]
File:      /path/to/code/vendor/composer/rg/mongodb-odm-light/lib/Doctrine/MongoDB/Cursor.php in line 490
Method:    Doctrine\MongoDB\Cursor->retry
Parameter: [Closure, false]
 
[31]
File:      /path/to/code/vendor/composer/rg/mongodb-odm-light/lib/Doctrine/MongoDB/Cursor.php in line 666
Method:    Doctrine\MongoDB\Cursor->Doctrine\MongoDB\{closure}
 
[32]
File:      /path/to/code/vendor/composer/rg/mongodb-odm-light/lib/Doctrine/MongoDB/Cursor.php in line 489
Method:    Alcaeus\MongoDbAdapter\AbstractCursor->rewind
 
[33]
File:      /path/to/code/vendor/composer/alcaeus/mongo-php-adapter/lib/Alcaeus/MongoDbAdapter/AbstractCursor.php in line 190
Method:    Alcaeus\MongoDbAdapter\AbstractCursor->ensureIterator
 
[34]
File:      /path/to/code/vendor/composer/alcaeus/mongo-php-adapter/lib/Alcaeus/MongoDbAdapter/AbstractCursor.php in line 297
Method:    MongoCursor->ensureCursor
 
[35]
File:      /path/to/code/vendor/composer/alcaeus/mongo-php-adapter/lib/Mongo/MongoCursor.php in line 443
Method:    MongoCursor->doQuery
 
[36]
File:      /path/to/code/vendor/composer/alcaeus/mongo-php-adapter/lib/Mongo/MongoCursor.php in line 166
Method:    MongoDB\Collection->find
Parameter: [MongoDB\Model\BSONDocument: ['o' => MongoDB\Model\BSONDocument: ['$in' => ['0' => 123456, '1' => 275383959000, '2' => 114204279, '3' => 233433999, '4' => 233014719, '5' => 237809079, '6' => 247189479, '7' => 251772159, '8' => 260437839, '9' => 275383959, '10' => 285140199, [10more ...]]], '$comment' => 'cId 4a05305c7e3b17a7cccd37f0520d3722,vId 165...'], ['batchSize' => 0, 'modifiers' => [], 'projection' => [], 'readPreference' => MongoDB\Driver\ReadPreference, 'readConcern' => MongoDB\Driver\ReadConcern, 'typeMap' => ['array' => 'MongoDB\Model\BSONArray', 'document' => 'MongoDB\Model\BSONDocument', 'root' => 'MongoDB\Model\BSONDocument']]]
 
[37]
File:      /path/to/code/vendor/composer/mongodb/mongodb/src/Collection.php in line 525
Method:    MongoDB\Operation\Find->execute
Parameter: [MongoDB\Driver\Server: [MongoDB\Driver\Server Object
(
    [host] => localhost
    [port] => 27017
    [type] => 2
    [is_primary] => 
    [is_secondary] => 
    [is_arbiter] => 
    [is_hidden] => 
    [is_passive] => 
    [last_is_master] => Array
        (
            [ismaster] => 1
            [msg] => isdbgrid
            [maxBsonObjectSize] => 16777216
            [maxMessageSizeBytes] => 48000000
            [maxWriteBatchSize] => 1000
            [localTime] => MongoDB\BSON\UTCDateTime Object
                (
                    [milliseconds] => 1487178165007
                )
 
            [maxWireVersion] => 5
            [minWireVersion] => 0
            [ok] => 1
        )
 
    [round_trip_time] => 0
)
]]
 
[38]
File:      /path/to/code/vendor/php/mongodb/Find.php in line 206
Method:    MongoDB\Driver\Server->executeQuery
Parameter: ['data.items', MongoDB\Driver\Query, MongoDB\Driver\ReadPreference]

Generated at Thu Feb 08 04:16:54 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.