Application Recycling and Programmatic Recycling
Recycling is one of the most important features in COM+ services for an application. Application recycling considerably enhances the complete solidity of applications. Memory leaks, reliance on third-party code, and no scalable resource usage can disintegrate the implementation of the majority applications over time. To resolve such problems COM+ application recycling allows the shutting down and restarting of processes associated with applications.
You can configure recycling from the new Pooling & Recycling tab on the application's properties page. Only a server application can obtain Recycling services, library applications cannot be configured to use recycling because they do not own their hosting process.
Application recycling can compensate for code defects. Memory leakage is one of the most common of those code defects. Some software may not have sufficient quality assurance and even released software may have memory leakage problem. Even a very small memory leak can cause major problems and that may affect the whole project at the long run.
We can explain memory leaks with an example from a real life, for instance, if large-scale software with an "insignificant" memory leak of only 10 bytes per method call, processes in excess of 25 method calls per second, will leak 25MB of memory in one day. The process that hosts application will spend this sum of memory and seriously increase the performance and availability due to program faults that cannot be predicted beforehand and major memory problems. In previous version, for this type of problem, developers were only be able to use a technique which they terminated the hosting process and restarted it manually. Fortunately, XP brings automatic recycling with COM+ 1.5. When you need to do this just go to the Pooling & Recycling tab and configure automatic recycling.
You can direct COM+ to shut down your application after a predetermined amount of time by specifying the Lifetime Limit value to deal with defects in handling other kinds of resources. For memory, limit default value is zero like lifetime limit, call limit or activation limit. If you realize that you have made a mistake after you have done some changes, just click on the restore default button and that will bring you the default values back. On the application Advanced tab, note that the lifetime limit semantics are different from the idle time management option.
The Server Process Shutdown value on the “Advanced” tab specifies the length of idle time after which the application should be shut down. The lifetime value indicates the number of minutes before application shutdown, that shows how long will the process will be alive therefore you can decide the time limit for keeping the processor alive.
There are two more recycling triggers that COM+ provides. Firstly, COM+ can
recycle your application following a given number of method calls into your
application when you indicate such a limit in the Call Limit edit box. The number
of calls is specified as the shared number of calls made on all the objects
in the application. The default value is set to zero. As you recall default,
value is set to zero. Secondly, you may need application recycling after a specific
number of activations. Activations are specified as the sum of objects that
COM+ 1.5 generated in that application. You identify activation limit in the
Activation Limit edit box please do not forget the default value is set to zero.
Once you triggered the recycling, COM+ 1.5 directs a new activation request
to a new host process, and waits for accessible client computers to release
their references to objects in the recycled process. In the Expiration Timeout
edit box, you can give the time COM+ 1.5 should wait. Following that expiration
timeout, COM+ 1.5 stops the application. If there are, still client computers
holding live references COM will not care about it. As you will se in box, default
expiration timeout is 15 minutes at this point.
Conclusively, you should keep in mind that for a COM+ application configured as system, service recycling is not available, and you cannot recycle a paused application. On the other hand, you can configure the recycling parameters programmatically with the COM+ 1.5 Catalog. To configure memory and time-bound recycling, use the RecycleMemoryLimit and RecycleLifetimeLimit named properties of the application's Catalog object. If you want to configure the expiration timeout, you need to use the RecycleExpirationTimeout named property. Here is an example to programmatically method.
//usage: "FirstApp" will be recycled after 250
object activations
//hres = SetRecycleByActivations("FirstApp",250);
HRESULT SetRecycleByActivations(LPCSTR lpcszAppName,DWORD dwActivations)
{
//Verify app name is valid
if(_bstr_t(lpcszAppName) == _bstr_t(""))
{
return E_INVALIDARG;
}
HRESULT hres = S_OK;
ICOMAdminCatalog2* pCatalog = NULL;
hres = ::CoCreateInstance(CLSID_COMAdminCatalog, NULL,CLSCTX_SERVER,
IID_ICOMAdminCatalog2,(void**)&pCatalog);
ICatalogObject* pApplication = NULL;
ICatalogCollection* pApplicationCollection = NULL;
long nCountofApp = 0;
int index = 0;//Index of Application
//Get the application collection
hres = pCatalog->GetCollection(_bstr_t("Applications"),
(IDispatch**)&pApplicationCollection);
pCatalog->Release();
hres = pApplicationCollection->Populate();
hres = pApplicationCollection->get_Count(&nCountofApp);
hres = COMADMIN_E_OBJECT_DOES_NOT_EXIST;
for(index=0; index<nCountofApp; index++)
{
//Get the current application
hres = pApplicationCollection->get_Item
(index,(IDispatch**)&pApplication);
_variant_t varName;
pApplication->get_Name(&varName);
_bstr_t bstrName(varName);
if(bstrName == _bstr_t(lpcszAppName))
{
long ret = 0;
_variant_t varActivationLimit((long)dwActivations);
hres = pApplication->put_Value(_bstr_t("RecycleActivationLimit"),
varActivationLimit);
hres = pApplicationCollection->SaveChanges(&ret);
}
pApplication->Release();
}
pApplicationCollection->Release();
return hres;
}
When you need to configure the call or activation limits programmatically, set the RecycleCallLimit or RecycleActivationLimit properties. The code provides the SetRecycleByActivations helper function, which sets a limit of activations for recycling a specified application.
Application Pooling
Application pooling is another important new ‘application lifecycle service’
option, which COM+ 1.5 provides. It is configurable from the new Pooling &
Recycling tab on the application's properties page same as recycling. Pooling
services are presented only for a server application. Library applications do
not own their hosting process therefore; you cannot configure them to use pooling.
Library applications have, in effect, the pooling parameters of whichever server
application happens to load them.
This feature allocates you to configure the several of replacement processes
presented to host your application's components. With previous version of COM+,
all instances of components from a server application constantly allocate the
unchanged hosting process. Even though this is also the standard COM default,
usual COM local server developers as well had the option of assigning one process
for each object. COM+ 1.5 gives you accurate manipulation powers over the number
of processes are launched by configuring a process pool. The Pool size edit
box is used to configure the pool size in. The default pool size is 1. Just
like in COM+ 1.0, a single process hosts all instances of components from the
application. However, if you set it to a value greater than 1, for each new
instance COM+ 1.5 generates a process until it reaches the pool size. At that,
point COM+ starts multiplexing new instances to the existing processes in a
round-robin fashion. The maximum configurable pool size is 999,999 and this
is sufficient for all functional purposes.
Application pooling is very helpful as a fault solving technique. If one process
has to shut down because of a fault or exception, the other processes and their
clients will not have a problem. Application pooling also gives you same-computer
load balancing. You do not have to use a separate load balancing service and
multiple computers to allocate different instances to different processes by
COM+ 1.5.
Comments