Hi there,
Thanks for the replies, it seems that the 'undefined' entry might have
been a red herring.
The IOC I am looking at is the client of the PV connection, and the IP
address listed is the server side of the CA gateway. There are in fact
two gateways on this machine - one for each direction as you suggested.
The configuration is really very simple, it is setup to allow read
access for all PVs. Do you need to know anything more specific?
Cheers,
Emma
> -----Original Message-----
> From: Ralph Lange [mailto:[email protected]]
> Sent: 17 October 2008 08:52
> To: Shepherd, EL (Emma)
> Cc: [email protected]
> Subject: Re: Inter-IOC link problems
>
>
> Hi Emma,
>
> I would need a bit more information about your setup to be
> able to fully
> understand your report.
>
> You are looking at the CA client side of an IOC. When you are losing
> connections between IOCs, is the IOC you're looking at the
> server or the
> client of that PV connection?
> It seems there are no beacons coming from the CA Gateway
> (172.23.106.35). Is that the client side or the server side of the CA
> Gateway? Are two (or more) Gateway processes running on that machine
> (i.e. one for each direction)? What is the CA configuration for the
> Gateway(s) on that machine?
>
> CA configuration of a Gateway is difficult and subtle. There
> are a lot
> of environment variables for CA server and client (see the CA Manual)
> which influence the behaviour of a CA application. Some variables are
> using other variables' values as default, which simplifies
> configuration
> of pure CA client or server apps, but may lead to unwanted
> behaviour for
> a CA Gateway (whis is one of the few apps that is as well CA
> server and
> client). E.g, it is quite easy to create a setup where the Gateway is
> sending out beacons on the wrong (i.e. client) side.
>
> Cheers,
> Ralph
>
>
> Shepherd, EL (Emma) wrote:
> > Hi all,
> >
> > We still seem to suffer quite a bit from problems with
> database links
> > between IOCs, particularly when a gateway is involved. For some
> > reason the links can become disconnected and a reboot is usually
> > necessary to get them working again. I have just had an
> opportunity
> > to do some diagnosis on one such problem and found a clue in the CA
> > beacon hashtable part of the dbcar report. The entry for
> the gateway
> > (172.23.106.35) is 'undefined', although the gateway itself
> seems to
> > be working just fine and I can use caget through the gateway as
> > normal.
> >
> > Any ideas what could cause this to happen, or how to fix it when it
> > does? None of the tasks are suspended, CPU usage is low and
> > everything else looks fine.
> >
> > CA beacon hash entry for 172.23.106.32:5064 with period estimate
> > 15.000521
> > beacon number 168436, on THU OCT 16 2008 14:27:46
> > CA beacon hash entry for 172.23.106.35:5064 <no period estimate>
> > beacon number 0, on <undefined>
> > CA beacon hash entry for 172.23.106.97:5064 with period estimate
> > 14.988265
> > beacon number 76356, on THU OCT 16 2008 14:27:52
> > CA beacon hash entry for 172.23.106.96:5064 with period estimate
> > 14.988637
> > beacon number 39491, on THU OCT 16 2008 14:27:53
> > CA beacon hash entry for 172.23.106.98:5064 with period estimate
> > 14.980477
> > beacon number 58989, on THU OCT 16 2008 14:27:47
> > CA beacon hash entry for 172.23.106.102:5064 with period estimate
> > 14.990867
> > beacon number 39993, on THU OCT 16 2008 14:27:53
> > CA beacon hash entry for 172.23.106.32:5064 with period estimate
> > 15.000521
> > beacon number 168436, on THU OCT 16 2008 14:27:46
> > CA beacon hash entry for 172.23.106.35:5064 <no period estimate>
> > beacon number 0, on <undefined>
> > CA beacon hash entry for 172.23.106.97:5064 with period estimate
> > 14.988265
> > beacon number 76356, on THU OCT 16 2008 14:27:52
> > CA beacon hash entry for 172.23.106.96:5064 with period estimate
> > 14.988637
> > beacon number 39491, on THU OCT 16 2008 14:27:53
> > CA beacon hash entry for 172.23.106.98:5064 with period estimate
> > 14.980477
> > beacon number 58989, on THU OCT 16 2008 14:27:47
> > CA beacon hash entry for 172.23.106.102:5064 with period estimate
> > 14.990867
> > beacon number 39993, on THU OCT 16 2008 14:27:53
> entries per
> > bucket: mean = 0.011719 std dev = 0.107617 max = 1
> >
> >
> > Thanks in advance....
> >
> > Emma
> >
>
<DIV><FONT size="1" color="gray">This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
</FONT></DIV>
- Replies:
- RE: Inter-IOC link problems Shepherd, EL (Emma)
- Re: Inter-IOC link problems Ralph Lange
- References:
- Re: Inter-IOC link problems Ralph Lange
- Navigate by Date:
- Prev:
Re: LvEPICS on USB Key pre-release Umashankar Panda
- Next:
Re: Converting Archive info to SDDS David Dudley
- 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: Inter-IOC link problems Ralph Lange
- Next:
RE: Inter-IOC link problems Shepherd, EL (Emma)
- 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
|