locking of commands and checking isMaster

[Zardosht Kasheff]

Hello all,

In Command::execCommand, the code that checks if a command can run on
the given machine seems to be:
bool canRunHere =
isMaster( dbname.c_str() ) ||
c->slaveOk() ||
( c->slaveOverrideOk() && ( queryOptions &
QueryOption_SlaveOk ) ) ||
fromRepl;

This bool is evaluated before any locking occurs for the command
(assuming locking is needed). ReplSetImpl::relinquish() protects the
transition of a machine from RS_PRIMARY to RS_SECONDARY with a global
write lock.

What is to stop the following from happening:
- a command foo executes canRunHere while the machine is still the primary
- canRunHere evaluates to true
- the machine then transitions from primary to secondary
- command foo then grabs its appropriate lock (read or write), and
proceeds to run the command on a secondary, even though it may not be
allowed to do so.

Is this problematic?

Btw, if so, then perhaps the evaluation of canRunHere can move to
inside the lock? It seems like a cheap call. Also, note that calls to
isMasterNs made by inserts, updates, and deletes are all done after a
lock is grabbed.

Thanks
-Zardosht

[Eric Milkie]

It might be problematic, but I can't think offhand of a command that could do damage by running on a recently-stepped-down former-primary node.  If any commands attempt to do normal reads or writes, they will be stopped later on anyway. 

However, you are correct that this is a small window of opportunity for commands to sneak by during a state transition.  We will work on moving the canRunHere check inside the lock.

-Eric

[Zardosht Kasheff]

Thanks Eric. What stops "normal reads or writes" later on? What stops
dropCollection, cloneDB, etc... from later executing if they hit this
race?

-Zardosht

> --
> You received this message because you are subscribed to the Google Groups
> "mongodb-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mongodb-dev...@googlegroups.com.
> To post to this group, send email to mongo...@googlegroups.com.
> Visit this group at http://groups.google.com/group/mongodb-dev?hl=en-US.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Eric Milkie]

I believe they will either hit the code in repl_reads_ok.h (if not god mode), or logOp() will fail when the op is attempted to be logged. Granted this is too late to prevent modification but it will notify that the event was not replicated.