How does Rhino use object pools, and why configure them? The Rhino SLEE uses groups of object pools to sequence access to SBBs and profile tables. Throughout the lifecycle of an object, it may move from one pool to another. Although the defaults are generally suitable, you can configure an object pool's size and depth to increase a service's performance.
Object pools cannot be configured with the rhino-console. Instead use the following MBeans and MBean operations.
MBeans for configuring object pools
The following MBeans provide the MBean operations for configuring object pools. (Each is linked to its related javadoc.)
Use the following MBean operations to configure object pools, defined on the ObjectPoolMBean interface. (Each operation in the table below is linked to its related javadoc. See also the table of related MBeans.)
To get and set the initial size of the object pool for objects in the pooled pool:
public int getInitialPooledPoolSize() throws ManagementException;
public void setInitialPooledPoolSize(int initialPooledSize) throws ManagementException;
Only SBB object pools use initial object pool population. Processing an event requires an SBB object from a pool of objects in the correct state.
If the pool is empty, the SLEE must create and initialise a new SBB object. This may take time, particularly if the setSbbContext() method on the object performs a lengthy initialisation. To reduce the impact of SBB object initialisation, the pool may be pre-populated with initialised SBB objects, either at service activation or at SLEE startup time. By default, the Rhino SLEE pre-populates each service's pool with 50 initialised SBB objects. You can adjust the value here.
Attributes to change only if instructed by OpenCloud The following operations should only be performed under the guidance of an OpenCloud engineer. Unless instructed otherwise, system administrators should alter only the initial pooled pool size attribute (above).