Hello all,
Sorry about the late reply - I have been enjoying a week and 2 days
vacation.
----------
> From: Alan K Biocca <[email protected]>
> To: [email protected]
> Subject: Re: ioc re-connect problem
> Date: Monday, April 07, 1997 9:56 AM
>
> We occasionally experience similar problems. I believe that Al Robb
noticed
> this behavior and did something in his sequencer to compensate. Not
pretty.
>
> I've suspected there are some subtle reconnect bugs,
CA is designed to reconnect transparently and nearly instantaneously
in all circumstances where:
o The client is able to see beacons from the server
o The server is able to see the client's search requests
I am unaware of any outstanding problems with 3.12 EPICS in
this area. Please provide additional details about the subtle
reconnect bugs you have seen.
> and we have spent time
> on the beaconing system since it causes a similar problem - if beacons
> aren't working correctly (like not getting through the router due to
> misconfiguration), and connectivity is lost, rebooting an UNINVOLVED
crate
> can fix the problem since it causes all unconnected channels to be
> re-searched.
>
> The problem seems to be that unconnected channels give up at some point
and
> never retry.
If CA does not find a channel within some reasonable (i.e. very long time
out) then
it will stop searching until:
o It sees a new server beacon
o It sees that the period of an existing server beacon has changed
o the client side tool creates a new channel
> While that might be the desired behavior, I think I would set
> the max-retry to a different value. Perhaps this is easily configurable
in
> some version, it didn't seem to be when we looked (3.12?).
The retry time out is a compile time parameter and not an environment
parameter. Since CA will always connect/reconnect when it sees the beacon
then providing the ability to run time configure the length of this long
time out
did not (during the design cycle) appear to be that important.
> Since the retry
> should only generate a broadcast packet (for the few unconnected
channels)
> every N minutes this would be acceptable for us. It would be nice to set
> the 'global default' in the compile and be able to adjust the individual
> client value in an environment variable. It should clamp to a minimum
value
> (say 1 minute) and a zero value would disable it (no retrys after initial
> series).
>
I could add environment variables for the following:
1) turn on/off search retry suspension after some delay expires
(pending the occurrence of a new server beacon on the LAN)
2) adjust the length of time before search retries are suspended
(pending the occurance of a new server beacon on the LAN)
3) adjust the search retry interval final plateau (used before search
retries are suspended)
The negatives are:
1) I have to write the code
2) EPICS become more complex to configure
3) Your LAN may see additional (site configurable) broadcast messages
4) In situations where the server beacons do not get through (are
incorrectly
configured) the max delay from when the server is available to when
the client actually reconnects will be similar to the delay specified
in (3) above.
Comments?
Jeff
______________________________________________________
Jeffrey O. Hill Internet [email protected]
LANL MS H820 Voice 505 665 1831
Los Alamos NM 87545 USA FAX 505 665 5107
- Navigate by Date:
- Prev:
Re: cdev & CORBA Chris Timossi
- Next:
Re: NFS mounting and channel access Jeff Hill
- 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
- Navigate by Thread:
- Prev:
Re: ioc re-connect problem Alan K Biocca
- Next:
ioc re-connect problem (fwd) + Johnny Tang
- 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
|