Detecting Background Index Creation Errors

[Temujin_12]

I'm trying to write an API for index management which ties into
MongoDB. Here's my general workflow:

1) Create - use db.coll.ensureIndex({...}, {background:true, ...})
2) Poll - use db.currentOP() to get in-progress index jobs
3) Retrieve - get completed index via db.system.indexes.find({"name" :
"..."})

I'd like to provide feedback (other than the index not existing) about
the success/failure of the index creation process.

The problem I have is how to handle the case where the background
index creation fails (for whatever reason) in #2. It won't show in
currentOP() anymore and also won't appear in db.system.indexes. So the
failure case looks the same as an index that was never attempted to be
created in the first place.

Is there somewhere index creation failure is accessible to MongoDB
clients (for backgrounded index commands)? I know the index failure is
logged in the MongoDB log, but I need to be able to get that
information using a MongoDB driver.

Thanks.

[Scott Hernandez]

You can now using the getLog command :
http://www.mongodb.org/display/DOCS/getLog+Command

>
> Thanks.
>
> --
> You received this message because you are subscribed to the Google Groups "mongodb-user" group.
> To post to this group, send email to mongod...@googlegroups.com.
> To unsubscribe from this group, send email to mongodb-user...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/mongodb-user?hl=en.
>
>

[Temujin_12]

Hmm, that seems promising.

The documentation is a bit lacking on details for that command.

How far back does it go (I imagine not indefinitely)?
Is there a limit to the size of the log array (again, assuming not
unbounded)?

Trying to figure out what polling interval makes sense to make sure I
can catch an index error. For a sufficiently high-trafficked cluster,
the index creation error may just zip right on by w/o an aggressive
polling interval (which I'd like to avoid).


On Nov 2, 12:39 pm, Scott Hernandez <scotthernan...@gmail.com> wrote:

[Scott Hernandez]

Yes, you will need to poll frequently, but you can probably filter as
well. It is a light weight operation since it just reads the log
messages out of memory. I think the last 1000 messages are kept in
memory, but I'd have to look at the code to be sure.