4.6 KiB
Command Dispatch
Command dispatch refers to the general process by which client requests are taken from the network, parsed, sanitized, then finally run on databases.
Service Entry Points
Service entry points fulfill the transition from the
transport layer into command implementations. For each incoming connection
from a client (in the form of a session object), a new dedicated
thread is spawned then detached, and is also assigned a new [session workflow]
session_workflow_h, responsible for maintaining the workflow of a
single client connection during its lifetime. Central to the entry point is the
handleRequest() function, which manages the server-side logic of processing
requests and returns a response message indicating the result of the
corresponding request message. This function is currently implemented by several
subclasses of the parent ServiceEntryPoint in order to account for the
differences in processing requests between the shard and router roles -- these
distinctions are reflected in the ServiceEntryPointRouterRole and
ServiceEntryPointShardRole subclasses (see here
and [here][service_entry_point_shard_role.h]).
Strategy
One area in which the mongos entry point differs from its mongod counterpart
is in its usage of the Strategy class. Strategy operates as a
legacy interface for processing client read, write, and command requests; there
is a near 1-to-1 mapping between its constituent functions and request types
(e.g. writeOp() for handling write operation requests, getMore() for a
getMore request, etc.). These functions comprise the backbone of the mongos
entry point's handleRequest() -- that is to say, when a valid request is
received, it is sieved and ultimately passed along to the appropriate Strategy
class member function. The significance of using the Strategy class specifically
with the mongos entry point is that it facilitates query routing to
shards in addition to running queries against targeted
databases (see s/transaction_router.h for finer
details).
Commands
The Command class serves as a means of cataloging a server command
as well as ascribing various attributes and behaviors to commands via the type
system, that will likely be used during the lifespan
of a particular server. Construction of a Command should only occur during
server startup. When a new Command is constructed, that Command is stored in a
global CommandRegistry object for future reference. There are two kinds of
Command subclasses: BasicCommand and TypedCommand.
A major distinction between the two is in their implementation of the parse()
member function. parse() takes in a request and returns a handle to a single
invocation of a particular Command (represented by a CommandInvocation), that
can then be used to run the Command. The BasicCommand::parse() is a naive
implementation that merely forwards incoming requests to the Invocation and
makes sure that the Command does not support document sequences. The
implementation of TypedCommand::parse(), on the other hand, varies depending
on the Request type parameter the Command takes in. Since the TypedCommand
accepts requests generated by IDL, the parsing function associated with a usable
Request type must allow it to be parsed as an IDL command. In handling requests,
both the mongos and mongod entry points interact with the Command subclasses
through the CommandHelpers struct in order to parse requests and ultimately
run them as Commands.
See Also
For details on transport internals, including ingress networking, see this document.