State Variables

The Monitoring relies on the notion of state variables (inspired from the control theory). Their values are keepts in circular list, providing records of past events.

A state variable are attached to the mediation chains and precisely to mediators and adapters. Their values are called measures and are timestamped at source level (when the measure is realized).

Alarm and warning can be defined on state variables. When an measure is under low threshold or upper high threshold and warning is fired by the Cilia Framework. When a measure is under very low and upper very high threshold an alarm is fired.

List of state variables name defined by the Cilia Framework :

Phase Collect

• scheduler.count: counts the number of incomming messages in the scheduler.
• scheduler.data: stores the complete message Data incomming in the scheduler.

Phase Process

• process.entry.count : counts the number of incomming messages in the processor.
• process.entry.data : stores the complete message Data incomming in the processor.
• process.exit.count : counts the number of outgoing messages the processor.
• process.exit.data : stores the complete message Data outcome from the processor.
• process.msg.treated: counts the number of messages executed by the processor.
• processing.delay : processing execution time.

Phase dispatch

• dispatch.count: counts the number of outgoing messages the dispacher.
• dispatch.data : stores the complete message Data incomming in the dispatcher.
• dispatch.msg.treated :counts the number of messages executed by the dispatcher.
• message.history :

Link

• transmission.delay : time between disptcher and scheduler (between mediators-adapters)

Events fired from POJOs - scheduler/processor/dispatcher

• fire.event : stores events fired by the user code (scheduler/processor/dispatcher)
• fire.event.count : counts the number of events fired by the mediator or adapter.

Events from the dependency manager

• service.arrival : the mediator-adapter service dependency has injected a new service reference
• service.departure: the mediator or adapter service dependency has removed the service reference used
• service.arrival.count: counts the number of service.arrival
• service.departure.count: counts the number of service.departure

Audits , variables accessed in read/write in POJOs -scheduler/processor/dispatcher

• field.set : variable Java accessed in write, the new value is stored.
• field.set.count :counts the number of read access.
• field.get :variable Java accessed in read, the value is stored.
• field.get.count :counts the number of write access.

State variables compute a measure stored in a circular list. By adding a condition storage, a data flow control is realized and configurable either by XML or APIs. The data flow control , accelerates or reduces the number of measures stored by unit of mediator/adaptor execution time.

Data flow control is exprimed by using a LDAP filter and is applied on the measure and/or the timestamp.

State variables have two states enable and disable and can be set individually either by APIs or XML. State enable , measures are recorded in the circular list; state disable, measures are not computed.

Knowledge of mediation chains @runtime

TO DO : events configuration TO DO : node description , topology access and node retreival TO DO : measures stored by state variable retreival

State variables configuration

State variables are attached to mediators and adapters. All state variables can be configured by the Cilia DSL, API and REST API ( see REST API )

Cilia DSL

Tag state-variable

Tag state-variable/setup

Extract of the Cilia DSL :

<chain id="chainId" type="chainType" xmlns:ns="http://adele.imag.fr/cilia/compendium/schema" xmlns="http://adele.imag.fr/cilia/core/schema">
    <mediators>
      <mediator-instance id="mediatorId" type="MyMediatorType">
         <monitoring>
         <!--  The state variable process.entry.count is enabled -->
         <ns:state-variable enable="true" id="process.entry.count">
           <!-- 
                process.entry.count configuration :
                20 records max in the list, 
                the time between two store in the list must be greater than 1000 ms and
                the difference between two measures must be greater than 2 
            -->                 
           <ns:setup queue="20" control-flow="(&amp;((time.elapsed &gt; 1000)(delta.absolute &gt; 2)))" />
    </ns:state-variable>
         </monitoring>
      </mediator-instance>
    </mediators>
</chain>

API : ApplicationRuntime

The ApplicationRuntime provides API to access to the Knowledge and State Variables (configurations and measures). ApplicationRuntime is accessible by the OSGi service CiliaContext.

The CiliaContext is a service offered by the Cilia Framework, it is the chain container and the main mechanism to perform modifications at run-time. All the advanced features, such as the REST API uses the CiliaContext and the builder pattern in background. To use the CiliaContext we must first import the class

import fr.liglab.adele.cilia.CiliaContext;
...

Next we need to obtain the service, we recommend using the dependency handler of iPOJO:

import org.apache.felix.ipojo.annotations.Requires;
import fr.liglab.adele.cilia.CiliaContext;
...

@Requires
CiliaContext ccontext;

But also, it is possible to obtain it using the BundleContext.

//To retreive the ApplicationRuntime 
ApplicationRuntime applicationruntime = ccontext.getApplicationRuntime();

The object ApplicationRuntime retreived it is now possible to configure and enable/disable state variables per adapters/mediators.

//To retreive the ApplicationRuntime 
ApplicationRuntime applicationruntime = ccontext.getApplicationRuntime();

REST : API

For the REST methods to manipulate CILIA architectures see REST API To access the following methods go to root path: HTTP_SERVER:PORT/cilia/runtime/ and the needed command PATH. In the following table, the root path will be replaced by @

Knowledge @runtime

to explain properties provided by services and meaning.