Table of Contents
There may be times when the server needs to be shut down and later restarted in a similar state. This chapter describes the script-related details of this scenario.
For more details, see the document Server Operations Guide's chapter Controlled Startup and Shutdown.
The process of controlled shutdown is described in the list below:
-
USR1 signal is received by LoginApp processes.
-
The LoginApp processes shut down immediately.
-
The CellAppMgr receives a message to schedule the shutdown (in game time).
-
The CellAppMgr sends a message to the other processes informing them when the shutdown is scheduled for.
-
The callback
onAppShuttingDown
on the CellApp personality script is invoked.The personality scripts on this step and the next should perform the appropriate finishing tasks, like ending long running tasks such as combats or trades, informing the players, and stopping new long running tasks from starting.
-
The callback
onAppShuttingDown
on the BaseApp personality script is invoked. -
Once these callbacks have been executed, calls to method
BigWorld
.isShuttingDown
will return True. -
The other server processes (CellApps, BaseAppMgr, BaseApps, Backup BaseApps, DBMgr, Reviver) do not stop immediately, instead performing any finishing tasks.
This delay can be specified in the file
res/server/bw.xml
by using the configuration option<shuttingDownDelay>
. For more details on this option, see the document Server Operations Guide. -
Shutdown game time is reached.
-
Game stops running, but the processes do not shut down.
This means that the game time is no longer incremented, and no game object is ticked.
-
When ready to shut down, CellAppMgr writes the game time to the database. If configured for archiving[33], the CellAppMgr also writes space data to the database.
-
This step takes place in parallel with step 11.
Each BaseApp performs the following steps:
-
Receives a message to disconnect any connected clients.
-
Invokes the callback
onAppShutDown
with an argument of 0 before disconnecting the clients.For each disconnected client, the proxy's callback
onClientDeath
is invoked. -
Invokes the callback
onAppShutDown
with an argument of 1, before writing to the database each entity with a database entry. -
Invokes the callback
onAppShutDown
with an argument of 2.
-
-
All server process shut down.
When starting up, the DBMgr initially waits until all components are
ready. A minimum number of BaseApp and CellApp processes can be specified
in bw.xml
via the options
<desiredBaseApps>
and
<desiredCellApps>
[34]. Once ready, the DBMgr loads space data back
into the system if it was archived[35] by the CellAppMgr.
Auto-loaded entities are then loaded into the system by creating the base entities.
It is up to the script to create the cell entity, if desired.
Creating a cell entity during startup is often different from doing so
during other times. Usually the method
Base
.createCellEntity
is
called with a cell entity mailbox to indicate the entity's space. But
during startup, the entity's space ID is restored and set in the
Base
.cellData
map. The base
entity script may use this by calling the method
Base
.createCellEntity
with
no arguments.
Once the server is ready to start running, the
onAppReady
callback from the personality script
is called on the BaseApps and CellApps.
[33] For details, see the document Server Operations Guide's section Server Configuration with bw.xml → CellAppMgr Configuration Options.
[34] For details, see the document Server Operations Guide's section Server Configuration with bw.xml → General Configuration Options.
[35] For details, see the document Server Operations Guide's section Server Configuration with bw.xml → CellAppMgr Configuration Options.