2002 2003 2004 2005 <2006> 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 2002 2003 2004 2005 <2006> 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: alarm hook |
From: | Andrew Johnson <[email protected]> |
To: | "Dalesio, Leo `Bob`" <[email protected]> |
Cc: | Matthias Clausen <[email protected]>, Geoff Savage <[email protected]>, EPICS core-talk <[email protected]>, Fritz Bartlett <[email protected]>, "Liyu, Andrei" <[email protected]>, Bernd Schoeneburg <[email protected]> |
Date: | Fri, 23 Jun 2006 15:26:47 -0500 |
I suggested:
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. Thiswould avoid having to add the hook at all...
Dalesio, Leo `Bob` wrote:
------ This has a lot of appeal. It could cache the last alarm monitor for every record.
Actually it wouldn't even need to do that itself if its job is just to pass the alarm changes on to the log server -- CA will automatically queue and cache the most changes for every channel on the clients behalf, until it finally manages to deliver them to the client.
- Andrew -- Not everything that can be counted counts, and not everything that counts can be counted. -- Albert Einstein