XP, Component Services and .NET

Recycling & Pooling

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.

You might also like...

Comments

About the author

John Godel United States

John H. GODEL has an experience more than 22 years in the area of software development. He is a software engineer and architect. His interests include object-oriented and distributed computin...

Interested in writing for us? Find out more.

Contribute

Why not write for us? Or you could submit an event or a user group in your area. Alternatively just tell us what you think!

Our tools

We've got automatic conversion tools to convert C# to VB.NET, VB.NET to C#. Also you can compress javascript and compress css and generate sql connection strings.

“Perl - The only language that looks the same before and after RSA encryption.” - Keith Bostic