csa101 question

Submitted by coredump on Mon, 2006-05-29 18:19.
::
I am looking at the csa101 code.. What's the difference between the csa101Comp_appStateChange() and clAmsCSISetCallback() functions? Both just modify the 'running' variable. Also, why doesn't the clAmsCSIRmvCallback() modify the 'running' variable? And I am not sure I follow the sequence in which various functions (callbacks, I guess) are called or the thread sequence. Can someone explain that?
‹ csa114 problem
csa101 question
Submitted by rbbeatie on Wed, 2006-05-31 11:58.

Great question!

The difference is twofold: First, the csa101Comp_appStateChange function is based on legacy control methods while the clAmsCSISetCallback function is to support the superior Service Availability Forum standard method as implemented by sisp_amf.

Second, the two are different in where the calls come from. The clAmsCSISetCallback function is invoked in response to requests from ams (part of sisp_amf). When you change the service unit's lock state from "unlock" to "lockassignment" for example, the clAmsCSISetCallback function is invoked. When you use the debug CLI and use the EOStateSet command to change the execution object's state to SUSPEND or RESUME, the csa101Comp_appStateChange function is called.

So, in the case of the csa101 application, the two functions are used to do the same thing (set the "running" variable) but they are called from different paths.

Also, the legacy method will be deprecated and eventually eliminated so we don't recommend using it.

Thanks rbbeatie. I am still
Submitted by coredump on Sat, 2006-06-03 11:33.

Thanks rbbeatie.

I am still confused though about the intent of the calls. You say one is legacy and the other is new. Is the legacy call just for debugging or does the infrastructure use it operationally?

Also, as a developer, how do I know which callbacks my application should expect and which it can ignore? If my application were to set the state change callback as NULL, will there be a default action taken?

And finally, how does task threading work for these callbacks? Suppose my application is in the middle of processing one callback and another one comes in, (the same callback or any other) what happens? Is it queued up, is it invoked in another thread and is there a way for the application developer to control it?

Thanks.

Thanks rbbeatie. I am still
Submitted by rbbeatie on Tue, 2006-06-06 14:28.

Hi again Coredump,

What I've been able to find out so far is that what control you have is that you get to specify the number of threads that are created for handling callbacks. This is the "number of EO threads needed" value in the clEoConfig structure.

I haven't been able to find a way to queue the calls. It seems that they are simply sent and if not responded to within the timeout are considered to have failed. Keep in mind that one of the callbacks you specify is the healthcheck callback. If that function does not return in a timely fashion and you run out of threads to handle additional incoming calls, your process will be deemed to have failed the healthcheck and will be killed.

Thanks rbbeatie. I am still
Submitted by rbbeatie on Mon, 2006-06-05 12:17.

Hi coredump,

I am told that it is no longer used "operationally". In addition, the only place in the source that I've been able to find that calls that callback is in response to requests from the debug cli. So, it's not so much that it's used for debugging as that the debug cli is still providing an interface to the legacy calls.

If you set the value to null in the clEoConfig structure, the cpm code just skips the callout, so the behavior is the same as if you had just provided a pointer to an empty function that just returns CL_OK.

As for how to know which functions to specify and which to define, the easiest way is to look at the sample applications and see what they provide. Which raises the point that it looks as if we should have eliminated the state change functions before we released the eval kit. Good catch!

As for your threading questions I'm going to have to do some research and ask some wiser heads before I respond. I'll try to have a more definitive answer for you tomorrow.

Thanks rbbeatie. I am still
Submitted by coredump on Thu, 2006-06-08 19:39.

On the threading question, suppose I tell the middleware to create 4 threads for an application, I guess it could invoke the callbacks in the context of any of the 4 threads. Can I also use these threads for my application's work or is it best to keep my application's worker threads separate by creating them explicitly after the application has started?

I guess there is no single solution that would be applicable for all applications but are there any recommended strategies for organizing work across multiple threads, such there are always threads to respond to the infrastructure callbacks but unnecessary threads are not created.

Thanks rbbeatie. I am still
Submitted by coredump on Thu, 2006-06-08 19:29.

What's cpm?

Thanks rbbeatie. I am still
Submitted by honglu on Thu, 2006-06-08 19:45.

CPM stands component manager which is the first openclovis component process starts up. CPM in turns starts other openclovis component processes. since each component process is implemented using EO (execution Object). CPM interaces with components in the system via their EO interfaces for booting, lifecycle, heartbeat and shutdown management.

Thanks rbbeatie. I am still
Submitted by coredump on Fri, 2006-06-09 14:37.

I am looking at the binaries provided with the eval kit and there is nothing called cpm ??

Thanks rbbeatie. I am still
Submitted by honglu on Mon, 2006-06-12 11:11.

In the current evaluation kit, the cpm is part of amf. AMF implements the SAF AMF functionality. And the binary name is sisp_amf.