[SERVER-14933] Failed to insert into capped collection when collection contains invalid 2d data Created: 18/Aug/14  Updated: 11/Jul/16  Resolved: 04/Nov/14

Status: Closed
Project: Core Server
Component/s: Geo, Index Maintenance
Affects Version/s: 2.6.3
Fix Version/s: 2.7.8

Type: Bug Priority: Major - P3
Reporter: Jianfa Tang (Inactive) Assignee: Mathias Stearn
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-13951 uncommited UnitOfWork needs to rollback Closed
Tested
Operating System: ALL
Steps To Reproduce:

> db.createCollection('a', {capped:true, max:2, size:2})
> db.a.ensureIndex({loc:'2d'})
> db.a.insert({ loc: [118333203, 40299390] })
> db.a.insert({loc: [ 118,42] })
> db.a.insert({loc: [ 118,42] })

Expected: document #3 to be inserted, #1 to be removed
Actual: "unindex failed" error.
Step 3 will fail on the index creation:

Assertion: 12583:unexpected index insertion failure on capped collection

However the document is inserted nevertheless. By the time when Mongo tries to remove the index for document #1, we get the "unindex failed" error.

The desired behavior is Mongo should fail the document insertion if there is an error creating the 2d index. This would be consistent with the new behavior in 2.6 with regard to the long index key handling

Participants:

 Description   

With a capped collection that stores taxi driver's location data. They have a 2d index in addition to the _id index on that collection. What they noticed is that once the collection is full, they are not able to inserting new document because of following error:

unindex failed (key too big?) order.order_endloc.$id key: { : ObjectId('53e3a3cb0cf25dc1e46cc2a2') } _id: ObjectId('53e3a3cb0cf25dc1e46cc2a2')

They were not able to reproduce this in test environment so had to use the workaround of dropping the collection when it's full and start over.

I spent some time with them today and was able to figure out the root cause to be some invalid location data. See repro steps for details.



 Comments   
Comment by Mathias Stearn [ 04/Nov/14 ]

I think this was automatically fixed by automatic rollback introduced by SERVER-13951. We no longer use the custom rollback for capped collections that triggered this failure.

Comment by Greg Studer [ 26/Sep/14 ]

Issue is not really geo-specific, but occurs because rollback on capped collections works differently than in ordinary collections.

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