Starting and Stopping Crossbar.io¶
When Crossbar.io forms part of your application, there are four approaches of starting Crossbar.io:
Start Crossbar.io from a startup script
Start Crossbar.io from within your application
Start you application from Crossbar.io
Start Crossbar.io externally
Starting Crossbar.io from a startup script¶
You can create a startup script for your application that first start a Crossbar.io node and then starts everything else needed for your application (like WAMP application components or other parts of your app).
Starting Crossbar.io from within your application¶
To start a Crossbar.io node from within your application, simply run the Crossbar.io executable using the usual language specific facilities.
E.g in Python, you can start Crossbar.io
import subprocess
p = subprocess.Popen(["/home/oberstet/python278/bin/crossbar",
"start", "--cbdir", "/home/oberstet/node1/.crossbar"])
Note that you need to specifiy fully qualified paths here.
To stop Crossbar.io
p.terminate()
p.wait()
Starting you application from Crossbar.io¶
Crossbar.io is able to start, monitor and host application components. Please see the respective documentation about container and guest workers.
Starting Crossbar.io externally¶
You can have Crossbar.io be started from OS level startup facilities (like Linux rc.d scripts or systemd). You actual application might also be started by the same facility and then depend on the Crossbar.io service having started already earlier.
Startup and Shutdown Behavior¶
When running from a configuration file (as opposed to connecting to a management uplink), Crossbar will start all components (whether in their own Container or running inside a Router) exactly once. When such a component shuts down or disconnects, it is gone. Individual components can exit cleanly, or with errors. When all components in a container shut down, the container itself shuts down (with error, if any component errored). A “worker” refers to any container or router process.
This table summarizes the cases:
container type |
component exit status |
crossbar behavior |
---|---|---|
container |
clean |
if last, shutdown container cleanly |
container |
fail |
if last, shutdown container with error |
router |
clean |
nothing |
router |
fail |
shutdown router with error |
The behavior of the crossbar process iteself is dependent upon
configuration options. The default is shutdown_on_worker_exit
.
shutdown_on_worker_exit
: if any worker exits, crossbar itself will shutdownshutdown_on_worker_exit_with_error
: if any worker exits with an error, crossbar itself will shutdownshutdown_on_last_worker_exit
: when all workers exit, crossbar itself will shutdownshutdown_on_shutdown_requested
: only exit if requested to via the management API
In the configuration, this option is specified inside the
controller
, like this:
"controller": {
"options": {
"shutdown": "shutdown_on_worker_exit_with_error"
}
}