Discussion:
Updates under high concurrency with MMAPv1 on MongoDB 3.0 not applying
(too old to reply)
Jon
2015-10-23 14:16:36 UTC
Permalink
Hi,

Based on the JIRA issue https://jira.mongodb.org/browse/SERVER-20829, and
the discussion I had in there, I wanted to ask about how to properly handle
updates by _id to ensure that updates always happen.

It appears that if two processes update the same document by _id, and one
causes a document move, it's possible that the other update will not apply.
In 2.6, this returns a RUNNER_DEAD error, but according to the issue, the
expected behavior is for the operation to "succeed" but to update 0
documents. I take this to mean that if you have a high concurrency
environment and have two processes, one doing

db.my_collection.update({_id: X}, {$set: {foo: bar}}

and another doing

db.my_collection.update({_id: X}, {$set: {baz: qux}}

that if they happen at roughly the same time and one causes a move, then
the other write will "silently fail". I say silently fail because the
operation succeeds but updates 0 documents, and if the application is not
checking the response to see if nModified == 1, then it seems like the
application would not know there is a failure.

Do you recommend in MongoDB 3.0 under MMAPv1 that we always check nModified
== 1 when doing an update? That seems heavy, but I may be misinterpreting
this.

To be clear, I'm not yet on MongoDB 3.0 but am trying to understand the
behavior when we get there. Right now we're on 2.6 and I have patched our
driver to retry write operations that fail with RUNNER_DEAD.
--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.

For other MongoDB technical support options, see: http://www.mongodb.org/about/support/.
---
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user+***@googlegroups.com.
To post to this group, send email to mongodb-***@googlegroups.com.
Visit this group at http://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/c544cdc2-f5c7-409b-a5a2-f928fea7cc4c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Chris De Bruyne
2015-10-24 13:44:43 UTC
Permalink
This is worrying.
Why would an update fail silently if the document got moved?
This does not make sense at all.
In this context I understand moved as in moved on disk due to document
growth.

I would really like some explanation about this from Mongo.

Kind regards
Chris
Post by Jon
Hi,
Based on the JIRA issue https://jira.mongodb.org/browse/SERVER-20829, and
the discussion I had in there, I wanted to ask about how to properly handle
updates by _id to ensure that updates always happen.
It appears that if two processes update the same document by _id, and one
causes a document move, it's possible that the other update will not apply.
In 2.6, this returns a RUNNER_DEAD error, but according to the issue, the
expected behavior is for the operation to "succeed" but to update 0
documents. I take this to mean that if you have a high concurrency
environment and have two processes, one doing
db.my_collection.update({_id: X}, {$set: {foo: bar}}
and another doing
db.my_collection.update({_id: X}, {$set: {baz: qux}}
that if they happen at roughly the same time and one causes a move, then
the other write will "silently fail". I say silently fail because the
operation succeeds but updates 0 documents, and if the application is not
checking the response to see if nModified == 1, then it seems like the
application would not know there is a failure.
Do you recommend in MongoDB 3.0 under MMAPv1 that we always check
nModified == 1 when doing an update? That seems heavy, but I may be
misinterpreting this.
To be clear, I'm not yet on MongoDB 3.0 but am trying to understand the
behavior when we get there. Right now we're on 2.6 and I have patched our
driver to retry write operations that fail with RUNNER_DEAD.
--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.

For other MongoDB technical support options, see: http://www.mongodb.org/about/support/.
---
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user+***@googlegroups.com.
To post to this group, send email to mongodb-***@googlegroups.com.
Visit this group at http://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/d389d505-522c-4264-a828-1bfc6a360162%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Asya Kamsky
2015-11-05 14:00:41 UTC
Permalink
Chris: you can see explanation of this in the docs (and in the ticket that Jon linked which also points to the docs).

This isn't going to happen just because a document moved, a very specific scenario has to be hit for this to happen as far as where in index scan the "second" update is in when it yields.

Jon,

Is the document that you are trying to update guaranteed to exist when you are doing this update?

If it's the case, then I believe you can safely add an upsert option to this update and then explicitly catch a duplicate _id value exception which is where this scenario would end up I'm pretty sure (second update will try to upsert if it does not find the document by _id which will cause an exception since the document does exist).

Asya
--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.

For other MongoDB technical support options, see: http://www.mongodb.org/about/support/.
---
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user+***@googlegroups.com.
To post to this group, send email to mongodb-***@googlegroups.com.
Visit this group at http://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/1ea6d00e-e425-4a42-96ab-3e247d00c170%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Jonathan Hyman
2015-11-05 14:36:08 UTC
Permalink
Yes, the document is guaranteed to exist. Are you suggesting that every
single update we make should be an upsert, though? We see this affecting
multiple collections at multiple different places in our application
(happening a few dozen times each day), so it seems heavy to me to make
this change everywhere and use a try/catch. In my opinion it seems like
something the database should handle because that the document moves seems
like an implementation detail/concurrency problem in mmap where I make the
updates by _id and one silently fails.

Sent from my mobile device
Post by Asya Kamsky
Chris: you can see explanation of this in the docs (and in the ticket
that Jon linked which also points to the docs).
Post by Asya Kamsky
This isn't going to happen just because a document moved, a very specific
scenario has to be hit for this to happen as far as where in index scan the
"second" update is in when it yields.
Post by Asya Kamsky
Jon,
Is the document that you are trying to update guaranteed to exist when
you are doing this update?
Post by Asya Kamsky
If it's the case, then I believe you can safely add an upsert option to
this update and then explicitly catch a duplicate _id value exception which
is where this scenario would end up I'm pretty sure (second update will try
to upsert if it does not find the document by _id which will cause an
exception since the document does exist).
Post by Asya Kamsky
Asya
--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.
http://www.mongodb.org/about/support/.
Post by Asya Kamsky
---
You received this message because you are subscribed to a topic in the
Google Groups "mongodb-user" group.
Post by Asya Kamsky
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/mongodb-user/FWpS1llOAnQ/unsubscribe.
Post by Asya Kamsky
To unsubscribe from this group and all its topics, send an email to
Visit this group at http://groups.google.com/group/mongodb-user.
To view this discussion on the web visit
https://groups.google.com/d/msgid/mongodb-user/1ea6d00e-e425-4a42-96ab-3e247d00c170%40googlegroups.com
.
Post by Asya Kamsky
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.

For other MongoDB technical support options, see: http://www.mongodb.org/about/support/.
---
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user+***@googlegroups.com.
To post to this group, send email to mongodb-***@googlegroups.com.
Visit this group at http://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/CAC7LtjGoANNWijOiRNDhLBfKLQUC%2BPg4Ee3EcGsk%3DwPxb2ubBw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Jon
2015-11-18 04:28:49 UTC
Permalink
Hi Asya, let me know your suggestion here.
Hi Asya, let me know your suggestion here.
--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.

For other MongoDB technical support options, see: http://www.mongodb.org/about/support/.
---
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user+***@googlegroups.com.
To post to this group, send email to mongodb-***@googlegroups.com.
Visit this group at http://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/d8d26d23-48e6-4b45-b3a2-595d85b93816%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Asya Kamsky
2015-11-18 04:59:59 UTC
Permalink
Your other option would be to upgrade to 3.0 and wired tiger which doesn't
have the same problem. But I was assuming that was not an option for you
yet, otherwise you probably would have already done that :)
Post by Jon
Hi Asya, let me know your suggestion here.
--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.
http://www.mongodb.org/about/support/.
---
You received this message because you are subscribed to the Google Groups
"mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an
<javascript:;>.
Visit this group at http://groups.google.com/group/mongodb-user.
To view this discussion on the web visit
https://groups.google.com/d/msgid/mongodb-user/97775490-dc73-4b4a-9645-f885d5708bcc%40googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.
--
Asya Kamsky
Lead Product Manager
MongoDB
Download MongoDB - mongodb.org/downloads
Free MongoDB Monitoring - cloud.mongodb.com
Free Online Education - university.mongodb.com
Get Involved - mongodb.org/community
We're Hiring! - https://www.mongodb.com/careers
--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.

For other MongoDB technical support options, see: http://www.mongodb.org/about/support/.
---
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user+***@googlegroups.com.
To post to this group, send email to mongodb-***@googlegroups.com.
Visit this group at http://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/CAOe6dJDv%3D%3D%2B-LeZRY3CkTcDNAA%2By4PJDKOXHcptPOsyAXg%3D5Cw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Jon
2015-11-18 05:11:06 UTC
Permalink
Yeah I'd like to upgrade to WT soon after getting to 3.0, but since we have
dozens of clusters, it will take me about 2 weeks just to upgrade all to
3.0, then many more days to do all the testing and slowly upgrade
everything to WT. My concern is that I'm going to be losing 20-30 writes
per day until I can get everything upgraded to WT after moving to 3.0, and
it may take a long time.
Post by Asya Kamsky
Your other option would be to upgrade to 3.0 and wired tiger which doesn't
have the same problem. But I was assuming that was not an option for you
yet, otherwise you probably would have already done that :)
Post by Jon
Hi Asya, let me know your suggestion here.
--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.
http://www.mongodb.org/about/support/.
---
You received this message because you are subscribed to the Google Groups
"mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/mongodb-user.
To view this discussion on the web visit
https://groups.google.com/d/msgid/mongodb-user/97775490-dc73-4b4a-9645-f885d5708bcc%40googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.
--
Asya Kamsky
Lead Product Manager
MongoDB
Download MongoDB - mongodb.org/downloads
Free MongoDB Monitoring - cloud.mongodb.com
Free Online Education - university.mongodb.com
Get Involved - mongodb.org/community
We're Hiring! - https://www.mongodb.com/careers
--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.

For other MongoDB technical support options, see: http://www.mongodb.org/about/support/.
---
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user+***@googlegroups.com.
To post to this group, send email to mongodb-***@googlegroups.com.
Visit this group at http://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/e97e6f82-eed4-4f70-9047-227f0abe6b32%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Asya Kamsky
2015-11-21 06:53:05 UTC
Permalink
I think your suboptimal options are code change to check for nMatched and
retry, code change to upsert and retry or upgrade and switch to WT. I
don't think anyone can judge better than you can which of these is least
disruptive to your system. :(

Asya
Post by Jon
Yeah I'd like to upgrade to WT soon after getting to 3.0, but since we
have dozens of clusters, it will take me about 2 weeks just to upgrade all
to 3.0, then many more days to do all the testing and slowly upgrade
everything to WT. My concern is that I'm going to be losing 20-30 writes
per day until I can get everything upgraded to WT after moving to 3.0, and
it may take a long time.
Post by Asya Kamsky
Your other option would be to upgrade to 3.0 and wired tiger which
doesn't have the same problem. But I was assuming that was not an option
for you yet, otherwise you probably would have already done that :)
Post by Jon
Hi Asya, let me know your suggestion here.
--
You received this message because you are subscribed to the Google
Groups "mongodb-user"
group.
http://www.mongodb.org/about/support/.
---
You received this message because you are subscribed to the Google
Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at http://groups.google.com/group/mongodb-user.
To view this discussion on the web visit
https://groups.google.com/d/msgid/mongodb-user/97775490-dc73-4b4a-9645-f885d5708bcc%40googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.
--
Asya Kamsky
Lead Product Manager
MongoDB
Download MongoDB - mongodb.org/downloads
Free MongoDB Monitoring - cloud.mongodb.com
Free Online Education - university.mongodb.com
Get Involved - mongodb.org/community
We're Hiring! - https://www.mongodb.com/careers
--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.
http://www.mongodb.org/about/support/.
---
You received this message because you are subscribed to the Google Groups
"mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/mongodb-user.
To view this discussion on the web visit
https://groups.google.com/d/msgid/mongodb-user/e97e6f82-eed4-4f70-9047-227f0abe6b32%40googlegroups.com
<https://groups.google.com/d/msgid/mongodb-user/e97e6f82-eed4-4f70-9047-227f0abe6b32%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
Asya Kamsky
Lead Product Manager
MongoDB
Download MongoDB - mongodb.org/downloads
Free MongoDB Monitoring - cloud.mongodb.com
Free Online Education - university.mongodb.com
Get Involved - mongodb.org/community
We're Hiring! - https://www.mongodb.com/careers
--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.

For other MongoDB technical support options, see: http://www.mongodb.org/about/support/.
---
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user+***@googlegroups.com.
To post to this group, send email to mongodb-***@googlegroups.com.
Visit this group at http://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/CAOe6dJDdLMPPbSC9P1_9Cb6XD9VDrB_4mP1%2Bqf8R0cHpA2BGqA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Jon
2015-11-21 11:03:37 UTC
Permalink
Given what we've discussed, do you think this behavior is a bug worth
filing in JIRA for you all to fix in some upcoming version of 3.x? It seems
like this is working as expected in 3.0, but it seems you now also realize
how this is not good behavior.
Post by Asya Kamsky
I think your suboptimal options are code change to check for nMatched and
retry, code change to upsert and retry or upgrade and switch to WT. I
don't think anyone can judge better than you can which of these is least
disruptive to your system. :(
Asya
Post by Jon
Yeah I'd like to upgrade to WT soon after getting to 3.0, but since we
have dozens of clusters, it will take me about 2 weeks just to upgrade all
to 3.0, then many more days to do all the testing and slowly upgrade
everything to WT. My concern is that I'm going to be losing 20-30 writes
per day until I can get everything upgraded to WT after moving to 3.0, and
it may take a long time.
Post by Asya Kamsky
Your other option would be to upgrade to 3.0 and wired tiger which
doesn't have the same problem. But I was assuming that was not an option
for you yet, otherwise you probably would have already done that :)
Post by Jon
Hi Asya, let me know your suggestion here.
--
You received this message because you are subscribed to the Google
Groups "mongodb-user"
group.
http://www.mongodb.org/about/support/.
---
You received this message because you are subscribed to the Google
Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at http://groups.google.com/group/mongodb-user.
To view this discussion on the web visit
https://groups.google.com/d/msgid/mongodb-user/97775490-dc73-4b4a-9645-f885d5708bcc%40googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.
--
Asya Kamsky
Lead Product Manager
MongoDB
Download MongoDB - mongodb.org/downloads
Free MongoDB Monitoring - cloud.mongodb.com
Free Online Education - university.mongodb.com
Get Involved - mongodb.org/community
We're Hiring! - https://www.mongodb.com/careers
--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.
http://www.mongodb.org/about/support/.
---
You received this message because you are subscribed to the Google Groups
"mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an
<javascript:>.
Visit this group at http://groups.google.com/group/mongodb-user.
To view this discussion on the web visit
https://groups.google.com/d/msgid/mongodb-user/e97e6f82-eed4-4f70-9047-227f0abe6b32%40googlegroups.com
<https://groups.google.com/d/msgid/mongodb-user/e97e6f82-eed4-4f70-9047-227f0abe6b32%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
Asya Kamsky
Lead Product Manager
MongoDB
Download MongoDB - mongodb.org/downloads
Free MongoDB Monitoring - cloud.mongodb.com
Free Online Education - university.mongodb.com
Get Involved - mongodb.org/community
We're Hiring! - https://www.mongodb.com/careers
--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.

For other MongoDB technical support options, see: http://www.mongodb.org/about/support/.
---
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user+***@googlegroups.com.
To post to this group, send email to mongodb-***@googlegroups.com.
Visit this group at http://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/c9d34e1c-494b-4b11-a9ef-a3ca76ac0359%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Asya Kamsky
2015-11-22 08:16:45 UTC
Permalink
We've realized this is suboptimal behavior for a while. It's a non-trivial
problem to fix with MMap - we would have to get rid of yielding or somehow
completely change how document moves work - it's really unlikely given that
mmap will likely be used by people in more heavy read load or low write
contention scenarios since WiredTiger is better for the other scenarios.

Asya
Post by Jon
Given what we've discussed, do you think this behavior is a bug worth
filing in JIRA for you all to fix in some upcoming version of 3.x? It seems
like this is working as expected in 3.0, but it seems you now also realize
how this is not good behavior.
Post by Asya Kamsky
I think your suboptimal options are code change to check for nMatched and
retry, code change to upsert and retry or upgrade and switch to WT. I
don't think anyone can judge better than you can which of these is least
disruptive to your system. :(
Asya
Post by Jon
Yeah I'd like to upgrade to WT soon after getting to 3.0, but since we
have dozens of clusters, it will take me about 2 weeks just to upgrade all
to 3.0, then many more days to do all the testing and slowly upgrade
everything to WT. My concern is that I'm going to be losing 20-30 writes
per day until I can get everything upgraded to WT after moving to 3.0, and
it may take a long time.
Post by Asya Kamsky
Your other option would be to upgrade to 3.0 and wired tiger which
doesn't have the same problem. But I was assuming that was not an option
for you yet, otherwise you probably would have already done that :)
Post by Jon
Hi Asya, let me know your suggestion here.
--
You received this message because you are subscribed to the Google
Groups "mongodb-user"
group.
http://www.mongodb.org/about/support/.
---
You received this message because you are subscribed to the Google
Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at http://groups.google.com/group/mongodb-user.
To view this discussion on the web visit
https://groups.google.com/d/msgid/mongodb-user/97775490-dc73-4b4a-9645-f885d5708bcc%40googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.
--
Asya Kamsky
Lead Product Manager
MongoDB
Download MongoDB - mongodb.org/downloads
Free MongoDB Monitoring - cloud.mongodb.com
Free Online Education - university.mongodb.com
Get Involved - mongodb.org/community
We're Hiring! - https://www.mongodb.com/careers
--
You received this message because you are subscribed to the Google
Groups "mongodb-user"
group.
http://www.mongodb.org/about/support/.
---
You received this message because you are subscribed to the Google
Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at http://groups.google.com/group/mongodb-user.
To view this discussion on the web visit
https://groups.google.com/d/msgid/mongodb-user/e97e6f82-eed4-4f70-9047-227f0abe6b32%40googlegroups.com
<https://groups.google.com/d/msgid/mongodb-user/e97e6f82-eed4-4f70-9047-227f0abe6b32%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
Asya Kamsky
Lead Product Manager
MongoDB
Download MongoDB - mongodb.org/downloads
Free MongoDB Monitoring - cloud.mongodb.com
Free Online Education - university.mongodb.com
Get Involved - mongodb.org/community
We're Hiring! - https://www.mongodb.com/careers
--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.
http://www.mongodb.org/about/support/.
---
You received this message because you are subscribed to the Google Groups
"mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an
.
Visit this group at http://groups.google.com/group/mongodb-user.
To view this discussion on the web visit
https://groups.google.com/d/msgid/mongodb-user/c9d34e1c-494b-4b11-a9ef-a3ca76ac0359%40googlegroups.com
<https://groups.google.com/d/msgid/mongodb-user/c9d34e1c-494b-4b11-a9ef-a3ca76ac0359%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
Asya Kamsky
Lead Product Manager
MongoDB
Download MongoDB - mongodb.org/downloads
Free MongoDB Monitoring - cloud.mongodb.com
Free Online Education - university.mongodb.com
Get Involved - mongodb.org/community
We're Hiring! - https://www.mongodb.com/careers
--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.

For other MongoDB technical support options, see: http://www.mongodb.org/about/support/.
---
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user+***@googlegroups.com.
To post to this group, send email to mongodb-***@googlegroups.com.
Visit this group at http://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/CAOe6dJAwrdarOUdEXZhfXYSTts2G9-L_h%3DTmqDB%3Ds_vB4N4g-A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Jon
2015-10-29 12:01:00 UTC
Permalink
Hi, is anyone from MongoDB able to answer this question? We run dozens of
clusters, and on 2.6 we're getting a RUNNER_DEAD error probably 20-30 times
per day which we retry. I'd like to know what we should do on 3.0 so we can
plan our upgrade path.
Post by Jon
Hi,
Based on the JIRA issue https://jira.mongodb.org/browse/SERVER-20829, and
the discussion I had in there, I wanted to ask about how to properly handle
updates by _id to ensure that updates always happen.
It appears that if two processes update the same document by _id, and one
causes a document move, it's possible that the other update will not apply.
In 2.6, this returns a RUNNER_DEAD error, but according to the issue, the
expected behavior is for the operation to "succeed" but to update 0
documents. I take this to mean that if you have a high concurrency
environment and have two processes, one doing
db.my_collection.update({_id: X}, {$set: {foo: bar}}
and another doing
db.my_collection.update({_id: X}, {$set: {baz: qux}}
that if they happen at roughly the same time and one causes a move, then
the other write will "silently fail". I say silently fail because the
operation succeeds but updates 0 documents, and if the application is not
checking the response to see if nModified == 1, then it seems like the
application would not know there is a failure.
Do you recommend in MongoDB 3.0 under MMAPv1 that we always check
nModified == 1 when doing an update? That seems heavy, but I may be
misinterpreting this.
To be clear, I'm not yet on MongoDB 3.0 but am trying to understand the
behavior when we get there. Right now we're on 2.6 and I have patched our
driver to retry write operations that fail with RUNNER_DEAD.
--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.

For other MongoDB technical support options, see: http://www.mongodb.org/about/support/.
---
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user+***@googlegroups.com.
To post to this group, send email to mongodb-***@googlegroups.com.
Visit this group at http://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/c894601b-fca2-4f1d-8aab-54700d8f8ffa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Jon
2015-11-02 14:47:19 UTC
Permalink
Hi all, wanted to ping on this again.
Post by Jon
Hi, is anyone from MongoDB able to answer this question? We run dozens of
clusters, and on 2.6 we're getting a RUNNER_DEAD error probably 20-30 times
per day which we retry. I'd like to know what we should do on 3.0 so we can
plan our upgrade path.
Post by Jon
Hi,
Based on the JIRA issue https://jira.mongodb.org/browse/SERVER-20829,
and the discussion I had in there, I wanted to ask about how to properly
handle updates by _id to ensure that updates always happen.
It appears that if two processes update the same document by _id, and one
causes a document move, it's possible that the other update will not apply.
In 2.6, this returns a RUNNER_DEAD error, but according to the issue, the
expected behavior is for the operation to "succeed" but to update 0
documents. I take this to mean that if you have a high concurrency
environment and have two processes, one doing
db.my_collection.update({_id: X}, {$set: {foo: bar}}
and another doing
db.my_collection.update({_id: X}, {$set: {baz: qux}}
that if they happen at roughly the same time and one causes a move, then
the other write will "silently fail". I say silently fail because the
operation succeeds but updates 0 documents, and if the application is not
checking the response to see if nModified == 1, then it seems like the
application would not know there is a failure.
Do you recommend in MongoDB 3.0 under MMAPv1 that we always check
nModified == 1 when doing an update? That seems heavy, but I may be
misinterpreting this.
To be clear, I'm not yet on MongoDB 3.0 but am trying to understand the
behavior when we get there. Right now we're on 2.6 and I have patched our
driver to retry write operations that fail with RUNNER_DEAD.
--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.

For other MongoDB technical support options, see: http://www.mongodb.org/about/support/.
---
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user+***@googlegroups.com.
To post to this group, send email to mongodb-***@googlegroups.com.
Visit this group at http://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/cb8d403e-fda2-4df5-89b8-f22dc63f243a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Continue reading on narkive:
Loading...