1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 <2016> 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 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: deny ca_search response for a record? |
From: | Paul Sichta <[email protected]> |
To: | Andrew Johnson <[email protected]> |
Cc: | "[email protected]" <[email protected]> |
Date: | Fri, 29 Apr 2016 13:57:18 -0400 |
Hi Paul,
Using Channel Access security to deny read access will give you one kind
of response which is worth testing for, but it won't be quite the same
as what happens if the network connection to the IOC dies and then gets
restored. Unreadable channels can still be found, you just won't get any
data from or about them, so making a channel unreadable isn't the same
as the server completely disconnecting.
You can send a Unix IOC process the SIGSTOP and SIGCONT signals to
suspend/resume it (or press Crtl-Z on the console to stop, run fg to
resume). Somewhat more complicated might be to enable and disable a
firewall rule to block network packets between the client and server.
- Andrew
On 04/29/2016 12:21 PM, Paul Sichta wrote:
> Kay,
> That's a good solution, and I can load "test support" .ascf files
> without rebooting the IOC. The record I want to affect uses an ASG that
> other records also have, so I'll have to see if I can set precedence in
> the .ascf file to single out just that one record for "no read".
>
> Thanks,
> -ps
>
>
> On Fri, Apr 29, 2016 at 12:48 PM, Kasemir, Kay <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hi Paul:
>
>
> I believe the channel access rules security not only cover write
> access but also read access.
>
>
> So you could have a channel access security rules which, based on
> the value of some PV, allows or prohibits read access to your test
> records.
>
>
> -Kay
>
>
> ------------------------------------------------------------------------
> *From:* [email protected]
> <mailto:[email protected]>
> <[email protected]
> <mailto:[email protected]>> on behalf of Paul Sichta
> <[email protected] <mailto:[email protected]>>
> *Sent:* Friday, April 29, 2016 12:11 PM
> *To:* [email protected] <mailto:[email protected]>
> *Subject:* deny ca_search response for a record?
-->
> For testing a script with caget's in it I'd like to test it's
> response to a "timeout" situation, in a transient fashion to test
> error handling/recovery. Is there a way from the IOC console to
> cause a record to act "hidden", and then make it normal again?
> dbpf into the .NAME field?
>
> I realize I can add logic in the script itself to simulate this
> condition, but was just wondering about the alternative. I also
> have a fuzzy feeling I can use a gateway to do something like this
>
> -ps
>
>
>
>
There are only two hard problems in distributed systems:
2. Exactly-once delivery
1. Guaranteed order of messages
2. Exactly-once delivery
-- Mathias Verraes