5. GDA Start-up

5.1. Overview

An overview of the GDA start-up is given below. Additional information can be found on the Diamond Confluence Page.

Note The startup process of GDA was overhauled in the 9.33 release and this page describes the new process. Details of the previous system can be found in the history of this page.

GDA uses an OSGi Configuration Service wrapping several configuration sources to abstract the details of specific beamline configuration away from the main application.

The GDA server can be started by running the built product directly passing any required configuration, eg

$ ./gda-server --gda-config /path/to/ixx-config

In practice, the server should usually be started using the gda command. This is a tool that interacts with an instance of the amygdala daemon running on the server machine and handles default options and configuration as well as starting and stopping the server process in the background. This ensures that the user workspace and eclipse data directories are set in the correct location and stdout/stderr logs are written to consistent directories.

For full details of how these tools are used, see the relevant docs but the most common commands to start the server and client would be

$ gda server restart

and

$ gda client

There is help available from the command and autocompletion scripts to help usability. Run gda --help for more details.

The gda command is available on Diamond machines via the module system

$ module load gda

There is also a module called gda_launcher which should generally be used in scripts/menus/launchers etc as it links only to stable releases and is only updated during shutdowns when any changes can be tested thoroughly.

From outside Diamond, the executables are available (along with the source and changelogs) from the amygdala repository.

5.2. GDA Server start-up sequence

The entry point for the server is GDAServerApplication. This is created by the eclipse framework and its start method is called.

5.2.1. Configuration Gathering

The OSGi framework used by GDA creates an instance of BeamlineConfigurationService.

This gathers configuration from several sources.

  • The command line arguments passed to the gda-server command

  • Any environment variables set

  • The config.toml file in the root of the config directory (determined from one of the previous sources or the current working directory if not specified).

  • Any plugins that contribute instances of CoreConfigurationSource via OSGi services. These sources are intended to provide core configuration that is not beamline or instance specific.

This process runs at startup before the GDAServerApplication instance is created. This means that any logging from the loading process will be written to stdout as the logging will not have been configured at that point.

The combined configuration is then used throughout the lifecycle of the application.

The combined configuration sources provide several types of configuration

  • Properties files: These are files containing key=value pairs to be made available via LocalProperties in GDA. The values can use ${property.interpolation} to refer to other properties.

  • Logging customisation: Any additional logback configuration files that should be included. These should use the included top level element rather than configuration.

  • Spring XMl files: These files define any beans that should be created to initialise the application. All beans are created in the same context and are free to reference beans defined in files from any other source, including the core plugin sources.

  • Spring profiles: These are the profiles to enable when creating the spring application context and control which beans are created from the included spring xml files.

  • Properties: These are key/values pairs provided directly by the configuration source rather than files. For instance passing --gda-custom-property helloWorld on the command line will set gda.custom.property to "helloWorld" on the CLI configuration source. These properties are combined with those read from the properties files above and are accessible via LocalProperties.

5.2.2. Logging Configuration

This is done as early as possible to ensure that as much of the process is observable as possible. All the logging configuration files are combined (in LogbackUtils.java) and are monitored so that changes to the files while the application is running cause the logging to be reconfigured.

5.2.3. Spring Context Creation

The spring xml files and profiles provided by the configuration are used (via an ObjectFactoryCommand) to create a spring application context and register any beans created with the Finder. This process also writes the gdaserver.py script that makes the current bean configuration available to the Jython interpreter.

5.2.4. Status Port

The GDA server opens a status port when its initialisation process is complete so that external processes can know when the client can be started or when the server has been shutdown. This port is opened once the spring context has been created and the server is considered running.

5.2.5. Wait For Shutdown

The top level application then idles until it is shutdown. Clients interact via the various beans created in the spring context.