Hi Anton,
I guess I have some more to say about the OpenHPI use of saHpiDiscover().
You wrote,
>
> From my point of view the code:
>
> -------------------
> saHpiSessionOpen();
> saHpiDiscover();
> ...
> -------------------
>
> is better than
>
> -------------------
> do {
> rv = saHpiSessionOpen();
> while ( rv != SA_OK );
> ...
> -------------------
>
But, that's not the choice! If the HPI daemon is not yet started, the call to
saHpiSessionOpen() will fail, so you will still need to have a retry built-in
for that case. Once the daemon has started, and gets part-way through
initialization, it then returns SA_OK, but you still don't have a usable
session - because the data reflecting the pre-existing state of the system is
not yet initialized in the domain. So, for the "benefit" of exiting your retry
loop early, you have to include a second call to wait for the rest of the
initialization to complete. There is no up side to that for the user.
But, the much bigger problem with this is the potential performance issue.
Although, it may be that OpenHPI does not implement saHpiDiscover() as it was
intended to be used, other implementations might. And, if it is a plug-in
issue in OpenHPI, maybe the behavior even differs between plug-ins. If it *is*
implemented correctly, it is very likely an expensive operation whenever it is
called. For the record, the intended purpose for this call is to force the HPI
implementation to make sure the domain tables (RPT, DRT, and potentially DAT,
although it is not mentioned in the specification with regard to saHpiDiscover)
have the latest data available from the platform before returning. Thus, if
the HPI implementation has a polling mechanism of some sort, it should force a
poll cycle before it returns.
Why would a user want to control the HPI implementation's polling? Not for any
very good reason, in my opinion, but the argument was that if the user
application makes some call that initiates a state change, and then is going to
do a query of the cached data, as in the RPT, that application may want to make
sure that the updated state from their previous operation is returned. There
is always going to be some latency between a state change happening, and it
getting reflected in the domain tables, so if the user is expecting to see a
state change, it may be important to control this latency.
On the other hand, unless there is some state change that the user is
specifically expecting to see, there is no good reason to care whether the
state returned on a particular query is one poll-cycle behind or not. Thus,
requiring the user to make a call to saHpiDiscover() every time they open a
session, and incur a potentially significant delay on each startup of their
application, is really not very nice.
It is especially unpleasant for HPI user applications that are short-lived.
For example, I wrote a web-based HPI viewer a few years ago that operated by
running individual HPI user programs that read specific pieces of data for the
web page. Displaying a web page might entail running a dozen or more of these
applets, each of which would open a session, read a little bit of data, then
terminate. Other script-based management agents have similar designs. But, if
each one of those applets need to call saHpiDiscover(), which might block for a
few seconds while it waits for a poll cycle to complete, then the performance
quickly becomes unacceptable.
So, bottom line, I think that using saHpiDiscover() this way as a workaround
for a bug in the implementation is OK, but the daemon really ought to be fixed
to work correctly during initialization. Either delay accepting sessions until
the domain tables are populated, or make the functions that query these tables
smart enough to know when the tables are not yet initialized, so that the
correct data can be fetched just-in-time if the user requests it. My guess is
that delaying accepting sessions is the easier option.
Regards,
David
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Openhpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openhpi-devel
