bw logo

Chapter 18. Controlled Startup and Shutdown

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.

18.1. Controlled Shutdown

The process of controlled shutdown is described in the list below:

  1. USR1 signal is received by LoginApp processes.

  2. The LoginApp processes shut down immediately.

  3. The CellAppMgr receives a message to schedule the shutdown (in game time).

  4. The CellAppMgr sends a message to the other processes informing them when the shutdown is scheduled for.

  5. 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.

  6. The callback onAppShuttingDown on the BaseApp personality script is invoked.

  7. Once these callbacks have been executed, calls to method BigWorld.isShuttingDown will return True.

  8. 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.

  9. Shutdown game time is reached.

  10. 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.

  11. 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.

  12. 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.

  13. All server process shut down.

18.2. Controlled Startup

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.