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 ????'s chapter ????.
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
onCellAppShuttingDownon 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
onBaseAppShuttingDownon the BaseApp personality script is invoked. -
Once these callbacks have been executed, calls to method
BigWorld.isShuttingDownwill 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.xmlby using the configuration option<shuttingDownDelay>. For more details on this option, see the document Server Operations Guide's section Software Configuration with bw.xml → General configuration options. -
Shutdown game time is reached.
-
Game stops running, but the processes not.
This means that the game time is no longer incremented, and no game object is ticked.
-
When ready to shut down, CellAppMgr writes the spaces, their data, and the game time 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
onBaseAppShutDownwith an argument of 0 before disconnecting the clients.For each disconnected client, the proxy's callback
onClientDeathis invoked. -
Invokes the callback
onBaseAppShutDownwith an argument of 1, before writing to the database each entity with a database entry. -
Invokes the callback
onBaseAppShutDownwith 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>[18]. Once ready, the DBMgr loads the spaces and their data back
into the system.
Entities stored from a previous session are then loaded into the
system by creating the base entities. The script function
BigWorld.hasStarted will
return False during this stage. This can be handy for
implementing different behaviour in the method
__init__ of restored 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 callbacks
onBaseAppReady and
onCellAppReady from the personality script are
called on the BaseApps and CellApps, respectively.
The game recovery function can be disabled by setting the
<dbMgr/clearRecoveryData>[19] configuration option to true. When game
recovery is disabled, the game is restarted with a single default space
with no entities. For information on how to re-populate the game, see
Initialisation: Personality script, eload, and runscript.