Re: [Openhpi-devel] Daemon sync

[Jonathan F. <jon...@bl...>]

If I'm using OpenHPI in the non-daemon mode (I'm aware that it's kinda
deprecated...), will I still have these issues? How's the DAT and DEL
are maintained in that situation?

Regards,

/jonathan

On Fri, 2007-08-03 at 18:13 -0400, Renier Morales wrote:

> ope...@li... wrote on 08/03/2007
> 02:37:15 PM:
> 
> > I have restarted Blade 10 HPI daemon, now the 74/75 are gone, so 
> > Blade 10 missed to asserted false event? How did it miss it? That's 
> > not a really reliable process?
> 
> Like I said, the events that indicated an alarm condition for 74/75
> must have happened during normal event pull, not during initial
> resource discovery. Than means that those events came and went. The
> HPI instance saw them at the time, and logged alarms approprietly.
> Restarting the daemon does not necessarily mean you will get the same
> alarms. The daemon must see those events again which promted the alarm
> entries in the first place which may or may not be generated
> immediatedly after re-startup depending on the plugin. Maybe the
> plugin is only picking up sensor events when there is a change, and in
> that case you are seeing what you are seeing.
> The DAT is kept entirely in software, so the daemon must see a
> sequence of events in order to enter and remove alarms from the DAT.
> You can't really expect the DAT to be kept intact between restarts
> because the event sequence is broken, unless...
> 
> One thing you can do is turn on DAT persistence in the openhpi.conf
> file (OPENHPI_DAT_SAVE="YES"). This way the daemon can recall past
> alarm entries between restarts.
> 
> > 3.6 Synchronization
> > ...
> > There may be multiple HPI implementations present in a system, such 
> > as those offered by different vendors. HPI Users should not assume 
> > any synchronisation between different HPI implementations.
> > ...
> > 3.6.2 Multiple HPI implementations
> > ...
> > Any software layer using concurrent access via multiple HPI 
> > implementations should take appropriate care; for
> > example, by updating both RDR tables, reading most current sensor 
> > values, etc., if it is possible that anything
> > may have had an effect on the other HPI implementation.
> > 
> > By "HPI implementation" the spec means instance of the 
> > daemon/library or like in 3.6 different vendors?
> 
> 3.6 doesn't restrict what it means by different implementations to
> different vendors. It uses different vendors as an example of
> different implementations. I very much understand an HPI
> implementation as an HPI running instance in this text. Running
> multiple instances of one code implementation is the same as running
> multiple HPI implementations. Thus you are subject to the warning in
> 3.6.2.
> 
> > 
> > Because from what I understand "different HPI implementations" means
> > e.g. one from OpenHPI and one from Motorola, I assume that both 
> > process wont talk to each other to sync (even if most commercial HPI
> > implementation are based on OpenHPI :)). But two instances of 
> > OpenHPI daemon for me share the same HPI implementation.
> 
> No, because, even though they run the same code, they are different
> running instances. Each manages its own set of domains separate from
> the other. All clients connected to the same daemon, are synchronized.
> The daemon is the single thing that ensures a consistent view to all
> HPI users (i.e. all connected sessions). Multiple instances do not
> share data and thus you can't expect an aggregated  consistent view
> between them. You can't really extend the synchronization scope
> described in the spec to running one implementation multiple times,
> same vendor or not.
> 
> > 
> > 3.6.1 Synchronization Responsibilities 
> > It is the responsibility of an HPI implementation to ensure that a 
> > single, consistent view of the system and its
> > domains and resources is presented to all HPI Users. In the face of 
> > multiple concurrent changes, the HPI
> > implementation should attempt to make updates visible system-wide in
> > a timely manner; however, no specific
> > timing is specified.
> > 
> > An HPI implementation shall guarantee that each HPI operation on any
> > resource is atomic; that is, if two writes
> > are attempted to a resource (e.g. from different sessions), one 
> > write shall succeed entirely, and then the other
> > write shall succeed entirely. The order in which the writes occur 
> > may be undefined, depending on timing and
> > the locations of the sources of the writes.
> > 
> > Any one HPI implementation is required to report all events for all 
> > resources to all sessions which have
> > subscribed to receive events and which have visibility of those
> resources.
> > 
> > Synchronization across sessions for me is just an example and one 
> > case of where sync should occurs. But sessions from different daemon
> > to the same shmm should have a 
> > consistent view of the system.
> > 
> 
> Same as above.
> 
> --Renier
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________ Openhpi-devel mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/openhpi-devel