Menu
▾
▴
#1510 Common Provider invokes Init and CleanUp more than once
Common Provider invokes Init and CleanUp more than once:
If a provider is registered for more than one class then Init and CleanUp functions are invoked more than once for the first request of each class.
Init and CleanUp functions doesn't get any parameter related to the ClassName, so invoking of those functions for each registered class is not necessary.
If this is by design, then atleast we can block two parallel request for class1 and class2 results in running the Init functions parallely which results in confusion.
For e.g.;
if ProviderA is a single provider in a library (let say libb.so) with ProviderA_Init() as initialize function. This provider is registered for the class CIM_X and CIM_Y then,
EI request for class CIM_X is invoking ProviderA_Init() and after EI request for class CIM_Y is also invoking the ProviderA_Init() function which initializes the same. I think this is not necessary in this case.
ProviderRegister has :
[CIM_X]
provider: ProviderA
location: b
type: instance
namespace: root/cimv2
[CIM_Y]
provider: ProviderA
location: b
type: instance
namespace: root/cimv2
Note : Tested in sblim-sfcb-1.2.5
I have concerns about the scalability of this fix. Since the fix has it in one loop of all providers, and then within that, looping through all providers again. I think there might be a more efficient way to go about this.
Earlier i had tried a brute force approach for unloading the providers, i have updated the patch with more efficient approach. any suggestions on a workaround if this fix is not ok?
Patch is OK. I can't think of a more efficient way to do it.
There are some additional issues with this bug that Sean is looking at.
What is the change in processProviderInvocationRequestsThread intended to do? As it stands, a NULL pointer can be assigned in some circumstances, especially under load.
Final patch
committed to HEAD
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 60 days (the time period specified by
the administrator of this Tracker).