Problem:
- Product Name: VisiBroker
- Product Version: 4.x and above
- Product Component: ServantManager
- Platform: All
How to manage the number of CORBA objects in memory not running out of control is a common question posted to CORBA designer. In practice, there is only a part of those objects need to be active in the server at any one time. However, how to determine the right moment to release particular objects from memory is not a easy problem to resolve.
Resolution:
The evictor pattern is designed to help manage the number of CORBA objects created and activated at any one time.
Firstly, the server monitors the number of objects that are active. If the maximum limit is exceeded, it will kick off to an "evictor" to clean out the excess CORBA objects by deactivating the servant objects and release them from memory.
To implement this, a list of active servant objects is maintained. FIFO is commonly implemented as a nature of a queue. When the queue reaches its maximum, the object at the front should be removed. However the data structure can be implemented in another ways depends on each particular requirement.
Secondly, the implementation must be able to reactivate the object when needed. In CORBA programming, it can be easily implemented using ServantManager (i.e. ServantActivator or ServantLocator). Every time a new object is to be activated (with ServantManager), there should be a check to make sure that the list doesn’t exceed its limit. If the list is at its maximum, the eviction must be invoked.
The implementation is done at incarnate(...) method for ServantActivator or at pre-invoke(...) method for ServantLocator accordingly.
With the help of ServantManager, some efficient strategies can be considered for eviction such as:
To evict servant which stays for longest time
To evict the least recently used servant
To evict servant which was not invoked after a predefined period
References: http://www.lenholgate.com/blog/2001/03/corba---the-evictor-pattern.html
Firstly, the server monitors the number of objects that are active. If the maximum limit is exceeded, it will kick off to an "evictor" to clean out the excess CORBA objects by deactivating the servant objects and release them from memory.
To implement this, a list of active servant objects is maintained. FIFO is commonly implemented as a nature of a queue. When the queue reaches its maximum, the object at the front should be removed. However the data structure can be implemented in another ways depends on each particular requirement.
Secondly, the implementation must be able to reactivate the object when needed. In CORBA programming, it can be easily implemented using ServantManager (i.e. ServantActivator or ServantLocator). Every time a new object is to be activated (with ServantManager), there should be a check to make sure that the list doesn’t exceed its limit. If the list is at its maximum, the eviction must be invoked.
The implementation is done at incarnate(...) method for ServantActivator or at pre-invoke(...) method for ServantLocator accordingly.
With the help of ServantManager, some efficient strategies can be considered for eviction such as:
To evict servant which stays for longest time
To evict the least recently used servant
To evict servant which was not invoked after a predefined period
References: http://www.lenholgate.com/blog/2001/03/corba---the-evictor-pattern.html
Incident: #2465355
#ServantActivator
#ServantLocator
#Performance
#Evictor
#ServantManager
#Security
#VisiBroker
