David,
All right, please enter the bug. :)
Anton Pak
On Tue, 11 Oct 2011 21:50:07 +0400, David McKinley <[email protected]>
wrote:
> 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
------------------------------------------------------------------------------
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
