The Runtime Image
The Fabric3 Server runtime image is organized in the following way:
/bin |
|
|
|
| Startup modules |
|
/lib |
|
|
|
| Modules required to start the runtime host |
|
/boot |
|
|
|
| Modules required for the runtime bootstrap and primordial system services |
|
/host |
|
|
|
| Libraries shared between the runtime and application (e.g. web services annotations) |
|
/extensions |
|
|
|
| Extension modules that are able to be loaded by all runtime instances |
|
/runtimes |
|
|
|
| Specific runtime instance configuration is hosted by default under this directory |
|
| <runtime-name> |
|
|
| top level directory for a runtime configuration |
|
|
| /config |
|
| Contains systemConfig.xml for configuring the runtime and extensions |
|
|
| /deploy |
|
| File system deploy directory for the controller and single-VM runtimes |
|
|
| /repository |
|
|
|
|
|
|
| /runtime |
| Extensions only loaded for the runtime image |
|
|
|
| /user |
| User contributions (only populated on the controller and single-VM runtimes) |
|
|
| /data |
|
| Persistent data directory for a runtime instance (e.g. transaction log) |
|
|
| /tmp |
|
| Temporary data and artifact cache for a runtime instance |
|
Runtime Startup
If the default runtime startup command is used:
java -jar server.jar
a single-VM instance will be created using the configuration specified in runtimes/vm. Alternative configurations can be used by specifying the runtime name as shown below. The runtime name will map to a configuration contained under the {{runtimes} directory:
java -jar server.jar controller -- launches a runtime using the configuration under {{runtimes/controller}}
java -jar server.jar participant -- launches a runtime using the configuration under {{runtimes/participant}}
java -jar server.jar foo -- launches a custom runtime using the configuration under {{runtimes/foo image}}
Note it is possible to run multiple runtime instances from a single disk image. In this case, the image will contain multiple configurations under the runtimes directory. Each instance can then be started by specifying the runtime name, for example:
java -jar server.jar foo java - jar server.jar foo2
Clean Startup
To start the runtime in clean mode, use the clean command:
java -jar server.jar clean
Note starting the runtime in clean mode will delete information stored in the data directory, including transaction recovery logs.
Runtime Cloning
For high-density clustered topologies such as cloud environments, Fabric3 provides the ability to clone runtimes. This allows new instances to be spawned from a configuration template using a single command without the need for manual setup. The following command clones a runtime image and launches the cloned instance:
java -jar server.jar clone:template runtime2
Configuring the Domain Name
If more than one domain is run on the same physical network, it is necessary to create unique domain names. The domain name is configured using the domain attribute of the <runtime> element:
<config> <runtime domain="mydomain"/> </config>
The domain name must be a valid URI host and not contain characters such as ":" or "/". The default domain name is domain.
Configuring the Runtime Mode
The runtime mode is configured using the mode attribute of the <runtime> element:
<config> <runtime mode="controller"/> </config>
Valid values are: vm; participant; and controller. For more information on the runtime mode setting, see The Domain.
Enabling Pass-By-Value Semantics
By default, Fabric3 is configured to use pass-by-reference semantics when invoking remotable services collocated with their clients. This avoids the overhead of parameter copying. In some cases, this may not be desirable, for example, if a service directly modifies parameter data that should not be visible to clients. To avoid this, the runtime can be configured to follow SCA by-value semantics by setting the @enableByValue attribute to true on the SCA setting in serviceConfig.xml:
<sca enableByValue="true"/>
Add Comment