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.
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.
Contains SBB objects and profile objects in the
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
Contains SBB objects and profile objects in the
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.
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
On startup this pool is always empty. It is populated with objects from the ready pool if and when they become stale.
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 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:
|Object pool statistics are available in the ObjectPools parameter set.
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:
getobjectpoolconfigcan be used to view an object pool configuration; and
configureobjectpoolscan 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:
useDefaults flag of an object pool configuration is deprecated and no longer has any function.