[SERVER-15559] Fatal Exception: Deeply nested $cond drops mongod process Created: 08/Oct/14 Updated: 06/Dec/22 Resolved: 28/Mar/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Aggregation Framework, Security, Stability |
| Affects Version/s: | 2.6.4 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Critical - P2 |
| Reporter: | Mark Shaw | Assignee: | Backlog - Query Team (Inactive) |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Query
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Operating System: | ALL | ||||||||||||
| Steps To Reproduce: | Startup: Default parameters (nothing special) The query: A large aggregate query @ 76K on disk. The nature of the query is that I am sending up a very deeply nested $cond statement to offset mongos lack of a relation join construct. |
||||||||||||
| Participants: | |||||||||||||
| Description |
|
Not sure if this is the cause but I can easily reproduce an error that ultimate terminates the mongos process. The Log is below, not sure if it helps as it doesn't appear to dump much information.
|
| Comments |
| Comment by Kyle Suarez [ 28/Mar/17 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I'm closing this as a duplicate of | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Asya Kamsky [ 08/Oct/14 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
mark.shaw@point72.com I didn't see you ask about this type of structure on Google Groups but you can avoid the super-long embedded structure by using some of the new 2.6 operators like $let and $map. You can see an example on Stackoverflow how to create a lookup based on an array of key value pairs - I tested it just now on 500+ array of key/value pairs and it works just fine. FYI, the test I ran had an array of multipliers in format:
And I used the pipeline that's derived from yours:
This will work to give you the same result without triggering the deeply nested object which is clearly not being caught by the server correctly which is what this ticket will track. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Thomas Rueckstiess [ 08/Oct/14 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hi Mark, Looking at the $project pipeline stage you provided in the mongo.txt file, it seems that your nesting level is at least 518 levels deep (counting the consecutive closing braces at the end of the stage). MongoDB supports nested BSON documents only to a depth of 100 levels, as documented on our MongoDB Limits page. So while this query is not supported, we can use this ticket to track improvements to MongoDB's behavior (i.e. not shutting down) when encountering such an invalid document. With regular queries, we do enforce the nesting limit and return an error (the limit there was recently increased from 20 to 100, see Thanks, | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Mark Shaw [ 08/Oct/14 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
You bet. Attached is the query that I'm sending up. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by J Rassi [ 08/Oct/14 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Could you post the complete aggregation operation that your application is sending which triggers this exception? |