urn:schemas-cosylab-com:Container:1.0
element Container

Properties

This component is not nillable.

Model

<Container
  DALtype = xs:string : DAL
  ImplLang = xs:string
  ManagerRetry = xs:int : 10
  PingInterval = xs:int
  Recovery = xs:boolean : true
  ServerThreads = xs:int : 5
  Timeout = xs:double : 30
  UseIFR = xs:boolean : true>
(Autoload, DeployInfo?, LoggingConfig )
</Container>

DALtype

ACS provides a plugin mechanism to use different implementations of configuration database. This attribute allows to specify the name of the desired implementation. All applications and systems using the standard ACS CDB do not have to change the attribute. Special systems with the need of integrating a different configuration database might use this feature. Currently not mapped to the TMCDB.

Type:

xs:string

Default:

DAL

Use:

optional

Form:

unqualified

ImplLang

The programming language the container is implemented in.

Type:

based on
with :

Use:

required

Form:

unqualified

ManagerRetry

How many times the Container shall try to contact the Manager upon startup before bailing out. 0 means forever. In a stable system, the Manager is normally already available when Containers are started up. Specific needs might trigger the necessity to trim this parameter.

Type:

xs:int

Default:

10

Use:

optional

Form:

unqualified

PingInterval

The Manager pings periodically all containers to check if they are healthy. The time interval in seconds for this heartbeat check can be specified here, to override Manager#ContainerPingInterval which is the default for all containers.

Type:

xs:int

Use:

optional

Form:

unqualified

Recovery

If true, all components will be automatically reloaded when the container gets restarted after a crash. About changes of the default value see http://jira.alma.cl/browse/COMP-3277. Notice that component recovery can have unexpected side effects for stateful components. In the future, ACS should distinguish and support stateless or state-managed components, so that a value "true" will only cause reloading those components of which the container knows that they are safe to restart. Some components may prefer to not be reloaded automatically after a container restart, but rather let the user go through an explicit restart procedure. Another reason to disable automatic component reloading would be a container crash caused during the activation of a (C++) component.

Type:

xs:boolean

Default:

true

Use:

optional

Form:

unqualified

ServerThreads

This is the number of threads allocate to the CORBA infrastructure for the handling of concurrent invocations. This value is normally sufficient, but it myght necessary to increase it for Containers with very many Components or when methods of Components take long time and build up complex chains of invocations. A typical manifestation of an insufficient number of threads is the deadlock followed by timeouts of actions in the Container.

Type:

xs:int

Default:

5

Use:

optional

Form:

unqualified

Timeout

Timeout in seconds for remote (CORBA) calls originating from this container or any of its components. This timeout will be implemented in this container, which means on the client side of the CORBA call. Timeouts ensure protection from deadlock. Notice that some ACS QoS features can be used to trim specific calls, support for which varies among the different container/ORB types. Maps to Container.CallTimeout in the TMCDB.

Type:

xs:double

Default:

30

Use:

optional

Form:

unqualified

UseIFR

At least the C++ container accesses the Interface Repository to retrieve information about the interfaces implemented by Components. In some very special situations, for example during debugging, it might be useful to disable the usage of the Interface Repository. Currently not mapped to the TMCDB!

Type:

xs:boolean

Default:

true

Use:

optional

Form:

unqualified

Source

<xs:element name="Container" type="Container"/>