The Rhino SLEE uses groups of object pools to manage the Java objects representing SBBs and profile tables.

Throughout the lifecycle of an object, it may move from one pool to another. Although the defaults are generally suitable, each object pool’s maximum size can be configured if needed.

Pools

There are several types of object pools, however Metaswitch recommends that only the initial pooled pool sizes be changed by system administrators. The other pool sizes are best set during performance testing and only after the maximum workload without tuning has been determined. When tuning the pool sizes consideration should be given to the maximum load nodes are expected to process and the memory consumed by the pools.

The JAIN SLEE specification describes the purpose of the object pools with respect to SBBs:

The SLEE creates and manages a pool of SBB objects. At runtime, the SLEE may assign zero or more SBB objects to represent an SBB entity. When an SBB object is assigned to represent an SBB entity, the SBB object is in the Ready state (see Section 6.3). It can receive and fire events, receive synchronous method invocations, and access and update the persistent state of the SBB entity. Another viewpoint is that the SBB object caches a copy of the persistent data of the SBB entity to provide transactional semantics.

Rhino has five types of object pool. Each is managed per-service or per-profile table, if a service or profile table does not have a pool configuration it inherits the default configuration for its type.

SBB object and profile object pools 
 Pooled pool

Contains SBB objects and profile objects in the Pooled state. This means that the object context has been initialised but no SBB entity or profile is associated with the object.

If the pool is empty, the SLEE must create and initialise a new object the next time it needs one. This may take time, particularly if the setSbbContext() or setProfileContext() method on the object performs a lengthy initialisation. To reduce the impact of object initialisation, the pool may be pre-populated with initialised objects, either at service activation/profile table creation or at SLEE startup time. By default, the Rhino SLEE pre-populates this pool with 50 initialised objects for services and zero for profile tables. This initial pool size can be configured with the initialPooledPoolSize configuration attribute.

 
 Ready pool

Contains SBB objects and profile objects in the Ready state. Ready means that the object is associated with the most recent version of an SBB entity or profile. For SBB objects this means that the object is ready to receive and process events.

On startup this pool is always empty. It is populated only with objects from the stale pool or pooled pool, or objects created on demand if the pooled pool was empty.

 
 Stale pool

Contains SBB objects and profile objects that are associated with an SBB entity or profile that has been modified in another transaction. This pool exists as a partner for the ready pool to avoid unnecessary calls to sbbActivate() and sbbPassivate, or profileActivate() and profilePassivate(). Objects in the stale pool are associated with out-of-date state and must be resynchronised with their persistent state before they can be used.

On startup this pool is always empty. It is populated with objects from the ready pool if and when they become stale.
CMP field object pools 
Persistent state pool

A persistent state object holds the MemDB representation of CMP and CMR field data for an SBB entity or profile.

A new persistent state object is required for every transaction in which CMP or CMR field data is updated. The purpose of the persistent state pool is to reduce the GC impact caused by the cycling of these objects as SBB entities and profiles are created, updated, and removed.

 
State pool

State objects provide the interface between SBB entities and profiles and the persistent state objects holding their CMP and CMR field data. State objects are associated with an SBB object or profile object when the object is associated with an SBB entity or profile.

The state pool should be configured to be at least the size of the ready pool. The maximum amount of state objects in use at any one time, and thus the maximum recommended state pool size, is limited to the sum of:

  • the size of the ready pool;

  • the size of the stale pool; and

  • the number of event processing threads.
Tip Object pool statistics are available in the ObjectPools parameter set.

Configuring Object Pools

The configuration of object pools is structured as follows:

  • A global defaults object pool configuration contains the set of base defaults.

  • A service defaults object pool configuration contains the default configuration for services. When a service is deployed, its initial object pool configuration is copied from the service defaults configuration.

    If, for some reason, the service defaults configuration is missing when it is required, it will be recreated based on the global defaults configuration.

  • A profile table defaults object pool configuration contains the default configuration for profile tables. When a profile table is created, its initial object pool configuration is copied from the profile table defaults configuration.

    If, for some reason, the profile table defaults configuration is missing when it is required, it will be recreated based on the global defaults configuration.

  • When a new namespace is created, each of the default object pool configurations for that namespace are initialised as a copy of the corresponding configurations from the default namespace.

Object pools can be configured, for example, with rhino-console using the following commands:

  • getobjectpoolconfig can be used to view an object pool configuration; and

  • configureobjectpools can be used to change the sizes of the object pools in a configuration.

Please see the online help in rhino-console for more information on using these commands.

Alternatively, MBeans operations can be used to configure object pools. Please see:

Note The useDefaults flag of an object pool configuration is deprecated and no longer has any function.
Previous page Next page
Rhino Version 3.1