Re: alarm hook

[Andrew Johnson <anj@aps.anl.gov>]

Matthias Clausen wrote:
> Sending all alarms _on change_ - no always all alarms permanently.
> To make this reliable we need a queue between the hook and the network 
> task.
> If the queue is full we - for now - send the number of lost messages.
> To make this even more reliable - as Jeff points out - we could set a 
> 'did not send alarm' flag to the record like:

Channel Access does not have a flag in each record, it keeps a structure 
for each channel/client combination that holds the 'changes pending' 
flag.  I don't like the idea of adding another field to dbCommon for the 
alarm logger, I see your reimplementing this as just one of the costs of 
replacing CA as your alarm transport mechanism if you want to use a hook 
in recGblResetAlarms().

It occurs to me that another model you could consider would be to run a 
local CA client on each IOC that subscribes to alarm events for all 
local records, and forwards them to the log server; this would then make 
use of CA's queue/ cache mechanism, and would mean this CA client 
doesn't need to keep its own queue of messages going to the log server, 
all that queueing would be done for you by CA.  This would avoid having 
to add the hook at all...

- Andrew
--
Not everything that can be counted counts,
and not everything that counts can be counted.
  -- Albert Einstein