Re: [Openhpi-devel] Propose moving OpenHPI library to a service oriented model.

[David J. <dju...@us...>]

Kanngieser Thomas-atk027c wrote:

>Hello David,
>
>
>very interesting paper. Here are my comments:
>
>- openhpid (Server) and openhpi client library (Client)
>  are already part of OpenHPI
>- what is the problem with threads ?
>  Non Threaded Applications will not see any effect
>  and Threaded Application are aware of that.
>- a HPI Library must be reentrant. This is a
>  requirement of the HPI-B Specification.=20
>  HPI calls from multiple thread must handled properly.
>  There is no statement about non threaded application.
>
Unfortunately in the area of the core infrastructure functionality it=20
has influenced many of our design choices
( the desire for the library to function in the absence of helper threads=
.)

At other times this has been ignored.   The result has been a solution=20
that can be viewed as not optimal in some respects.=20
I say all this in reference to functionality such as event gathering=20
from plugins and API's such as saHpiEventGet().

It is true that the library is fully reentrant.  It is well designed and=20
robust.  I am only refering to the decision to create helper-threads
with repsect to core library functionality.

The proposal to go to a client-server model is to free us to make the=20
best design choices in the future.   We can optimize for speed and
performance using all the real-time features that are available.

See mailing discussion [Discovery-Time] for a canidate for benefiting=20
from this change.

>  Because the HPI Library has no information if the HPI Application
>  uses threads the HPI Library must be linked to at least any
>  thread library (like POSIX Thread Library).
>  Is there any requirement to support a HPI Library which is not linked
>  to a POSIX Thread Library ? If yes why ?
>- we have the openhpi client library, the openhpi library (with plugins)
>  and we have the openhpi daemon.
>
In describing the daemon I would say we have a daemon that utilizes the=20
OpenHPI library and
plugin subsystem that we have developed.   And it is this configuration=20
I propose we prompt as
the OpenHPI solution.

>  The openhpi library and the openhpi client library both have a full HP=
I API.
>  Do you want to have a better integration of the openhpi
>  daemon and the openhpi library ?
>  Or is the question: it necessary to have 2 libraries with HPI APIs ?
>
Thomas your final point here sums it up.  Why have two libraries.  I=20
propose using the good work you and David Ashely have done over the last=20
couple years.
I believe we should use what we have called at  various times the=20
remoting solution as the preferred build configuration.  And prompt the=20
use of it as a system
service.  The management app developer would link to what we call the=20
client library.  This would greatly simplify the build choices, make HPI=20
usage a more
formal administrative task and ease management app development. =20

>
>
>Thomas
>
>
>
> =20
>
>>-----Original Message-----
>>From: ope...@li...=20
>>[mailto:ope...@li...] On Behalf=20
>>Of David Judkovics
>>Sent: Wednesday, January 25, 2006 22:16
>>To: ope...@li...
>>Subject: [Openhpi-devel] Propose moving OpenHPI library to a=20
>>service oriented model.
>>
>>Propose moving OpenHPI library to a service oriented model.
>>
>>
>>Presently OpenHPI is compiled as a shared dynamically loadable
>>(libopenhpi.so)
>>or statically linked library (libopenhpi.a). Each management=20
>>application that wishes to make HPI API calls links to one of=20
>>these two libraries. In doing so any and all threads that may=20
>>be spawned by this library become part of that applications=20
>>memory space. Problems may arise for those application=20
>>developers who are not aware that their application space is=20
>>shared with threads. For this reason and others it is not=20
>>considered good practice for linkable libraries to spawn threads.
>>
>>
>>The solution to date has been to allow OpenHPI to be compiled=20
>>with or without threading enabled. This gave the management=20
>>application developer the choice of designing for a threaded=20
>>solution or not.
>>
>>
>>The downside of this is OpenHPI has suffered from conflicting=20
>>design requirements.
>>One requirement is always function well without the use of=20
>>threads. The second is operate as optimally as possible in=20
>>reporting asynchronous events. This has resulted in issues=20
>>and can be observed during discovery. Lengthy discovery=20
>>intervals have become the norm in systems with multiple=20
>>servers and is not acceptable.
>>
>>
>>The solution is to move the OpenHPI project to a=20
>>client-server model with the server installed as a service.=20
>>This is fundamentally the existing remoting solution. It=20
>>would divorce the management applications from any threading=20
>>issues. It would allow for fully optimized event and data=20
>>handling model using POSIX threading, locking, and signaling.
>>It would greatly simplify build options by eliminating the=20
>>threading option and the client-server options.
>>
>>
>>An additional benefit would be a more simplified development=20
>>process for management application developers. The=20
>>segregation of the core functionality of OpenHPI from the=20
>>management application would make the configuration of=20
>>OpenHPI an administration task and not a development task.=20
>>Also automated recovery from catastrophic errors would be=20
>>limited to just OpenHPI issues on the daemon side and just=20
>>management application issues on the application side.
>>
>>Best Regards/ Mit freundlichen Gr=FCssen
>>
>>David Judkovics
>>
>>dmj...@us...
>>Adv. Software Engineer
>>LTC xSeries Linux
>>IBM Server -- Endicott, NY
>>Tel: 607-429-4745 - Tie 620-4745
>>
>>
>>
>>
>>
>>   =20
>>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log f=
iles
>for problems?  Stop!  Download the new AJAX search engine that makes
>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=103432&bid#0486&dat=121642
>_______________________________________________
>Openhpi-devel mailing list
>Ope...@li...
>https://lists.sourceforge.net/lists/listinfo/openhpi-devel
>b
> =20
>