Geoff,
I like your #1 -> #6 :-)
and chain
hook -> logAlarm -> queue -> sendToNetwork -> createMessage -> send
to A -> send to B (if send to A fails)
1. hook
2. hook function
>logAlarm(struct dbCommon *prec, unsigned short sevr, unsigned short
stat)
Why not logAlarm(struct dbCommon *prec)?
>It should also do something reasonable if the data can't be inserted in
the
>queue. It might simply keep track of the number of insertion
>failures and report this number in a message once the queue has space.
I think that a way is
something happen -> error message to Error log (through network).
If ErrorLog can't send message that stop by MPS (through special net).
Another question how can be used this way?
Maybe something like: logAlarm can't put message into queue -> +1 -> if
==100 -> send message to error log and reset counter?
We can decrease quantity of Alarm messages. I suppose alarm with status
DB_LINK is duplicated of another alarm.
3. queue
Sure. Size has default value and can be adjusted by env variable.
4. sendToNetwork.
I think the priority depends of system type. For example, for diagnostic
devices maybe better have alarm then another incorrect data from scan
task? For first step I think alarm can be less than CA task.
Maybe have default value and can be adjusted by env variable.
5. Message through network and createMessage() and #c
>The createMessage routine constructs a string message to be sent
>across the network. To be more generic users should be able to
>define their own createMessage routine. This allows users to use a
>different message protocol within the push out framework.
Sorry but I have totally another approach. I think Alarm message must
have standard! That is like CA standard. From distributed view Alarm and
CA messages definitions are more important than record standard. But it
must be flexible. I would like to have something like
- some predefined fields [ID, Alarm severity, timestamp]
- one flexible field [Alarm status for Epics]
- separator
- string (characters), maybe length can be adjusted by env variable.
In this case anyone can add anything in the end and then take care on
client side.
6. Send the message to server A/B
Env variables can have 1,2,3 Alarm servers. At first try 1, then 2 and
so on. If there is not env variable = "" than Alarm system doesn't work.
Again error concerning Alarm server problem sends into error log.
Also Alarm service can sends one message but it can sends some messages
in one package. It should save time.
Thanks, Andrei.
- Navigate by Date:
- Prev:
RE: alarm hook Liyu, Andrei
- Next:
RE: alarm hook Liyu, Andrei
- Index:
2002
2003
2004
2005
<2006>
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: alarm hook Liyu, Andrei
- Next:
RE: alarm hook Liyu, Andrei
- Index:
2002
2003
2004
2005
<2006>
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|