Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Tue, 21 Jul 2009 18:38:58 -0600

> As a side effect, there's now a race condition when you ask for the CA
> properties after connecting to a channel.

When the client library creates a new circuit it immediately sends a message to the name server querying what the name of the host, that the circuit connects to, is. If a client application asks for the PV's host name before this DNS request completes asynchronously then the dotted IP address of the circuit's endpoint is returned - as a string.

We could add a timeout to the ca_host_name () function internals, but then for how long should the timeout be set, and if it's too long then we will lock up the client application when the DNS server isn’t responding. It doesn’t appear to be appropriate to slow down channel connects in any way if DNS is slow for any reason, and even a slowdown in ca_host_name () might be very inappropriate for certain types of clients.

Admittedly, now we have a complication for the client application - a state that changes asynchronously w/o notification. 

We could add asynchronous notification to the client for this particular state change but that seems to be adding quite a bit of interface complexity with a fairly small return. 

I'm fully open to alternative suggestions.

Jeff
______________________________________________________
Jeffrey O. Hill           Email        [email protected]
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

Message content: TSPA

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Behalf Of Ralph Lange
> Sent: Tuesday, July 21, 2009 2:49 PM
> To: Carl Schumann
> Cc: [email protected]
> Subject: Re: cainfo does display host info
> 
> At some point during 3.14, the name resolution was moved into a separate
> thread and handled asynchronously. (Before, there were situations, where
> a DNS malfunction or misconfiguration could hang up an otherwise
> perfectly working CA system.)
> 
> As a side effect, there's now a race condition when you ask for the CA
> properties after connecting to a channel. If name resolution finishes
> first, you get the name. If it's a bit too slow, you get nothing.
> Installing a local caching name server increases the chance for the name
> resolution to finish first. It is not needed for CA to work properly,
> just for seeing the user/host info immediately.
> 
> BTW: a caching name server is not a bad idea, in general. Usually it
> improves system stability in cases of DNS trouble.
> 
> Best regards,
> Ralph
> 
> 
> Dirk Zimoch wrote:
> > Hi Carl,
> >
> > I think the problem started with 3.14.8. When you try again, you will
> > see that sometimes the host name is there and sometimes not. I think
> > the CA library is a bit impatient with the name server. Maybe Jeff can
> > have a look at some timeout.
> >
> > Dirk
> >
> > Carl Schumann wrote:
> >> Hi,
> >>
> >> I ran cainfo for a PV but did not get a result for host:
> >>> [schumann@smartcon1 ~]$ caget PD_MOD1:tstable
> >>> PD_MOD1:tstable                /tmp/table_data.15901.dat
> >>> [schumann@smartcon1 ~]$ cainfo PD_MOD1:tstable
> >>> PD_MOD1:tstable
> >>>     State:         connected
> >>>     Host:              Access:        read, write
> >>>     Data type:     DBR_STRING (native: DBF_STRING)
> >>>     Element count: 1
> >>> [schumann@smartcon1 ~]$
> >> Since the caget is working there would it appears have to be a host
> >> of some sort.   Is there an explanation for the blank host field?
> >> Attempts to find an explanation at the ANL web site were unsuccessful.
> >>
> >> Thanks,
> >> Carl
> >>
> >>
> >>
> >

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System