Re: Inter-IOC link problems

[Ralph Lange <Ralph.Lange@bessy.de>]

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
>