rocksfrow
commented
10 years ago @nicktacular I am having trouble reproducing the MongoCursorException in this event. Is there any chance you have any recollection of the exception that was being caught in this scenario? Was it a write concern exception, or a MongoCursorException only?
I am thinking we should use something like this to properly catch the write concern "waiting for replication timed out" while still continuing on the exception you originally ran into.
try {
$res = $this->locks->save($lock, $this->getConfig('write_options'));
} catch (MongoWriteConcernException $e){
//catch write concern exception before general cursor exception
die($e->getMessage());
} catch (MongoCursorException $e) {
//may occur if there's a race to acquire a lock
continue;
}I just don't know the original exception you were handling and whether or not it's coming through as a writeconcern exception or not.
I could also check the exception code instead.
After adding write concern support, I found a problem with the current way the exceptions are being handled in lock().
RE: "may occur if there's a race to acquire a lock"
When using a write concern value that's too high, the wTimeoutMS value is essentially ignored with this behavior.
ex) I have two nodes, so w=2 works perfect. I decreased the wTimeoutMS to 5s, so when setting w=3 I should expect to get an exception... BUT, you are catching that exception and continuing to the next iteration. Because of this, instead of wTimeoutMS stopping script execution, it keeps running until either $config['locktimeout'] is exhausted, because it thinks it's simply retrying the lock.
I will investigate the exception scenarios and see if I can add some logic to differentiate between these two scenarios, so the script properly throws an exception when wTimeoutMS is exhausted.