Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Thu, 16 Sep 2010 12:42:18 -0600

Hi Dirk,

When gateways are involved it can be confusing to discuss the details
of the situation unless we are clear about perspective. This is because 
each gateway process has both a ca client and a ca server inside of it. What
gets confusing is that there are also other clients and servers (IOCs) with
which the gateway communicates, either directly or indirectly, over the
network.

In this particular mail I was presenting the perspective of the portable 
server library (the PCAS) because the defects in question are in either
the PCAS or its service (the gateway). The PCAS library has multiple clients

on the network, and it views the gateway code as a service. It actually does
not 
know that its service is a gateway, and that the gateway happens to be
also a client of several IOCs. 

> > o the ca service (the gateway) has a PV who's native type is advertised
> > 	to be enumerated (i.e. menu)
> 
> Shouldn't that be:
> the *ioc* has a pv who's native type is advertised to be enumerated

>From the PCAS server library's perspective, it is attached to a ca service 
(the gateway) that has a pv who's native type is advertised to be
enumerated. 
In this situation, where the ca service is a gateway, the gateway happens
to be a client of an IOC that has a PV that is enumerated, but that fact 
isn't directly known by the PCAS library.

> > o the ca server is fetching the enumerated state set string table
> > 	application type from the ca service (the gateway). That typically
> > 	occurs when the ca server attaches to an enumerated pv and it needs
> > 	to initialize its cache for the enumerated state set string table.
> And this:
> the ca *client* is fetching the enumerated state set string table
> application type from the gateway. That typically occurs when the ca
> *client* attaches to an enumerated pv...

Actually, the PCAS server library always fetches the enumerated state set 
string table and caches it, when it discovers that a new PV in its service
(the gateway) has native type that is enumerated. The decision to make
that request to the PCAS's service (the gateway) actually occurs
independently 
of what any ca client of the PCAS library decides to do (related to fetching

a copy of the enumerated state set string table).

> > o the ca service (the gateway) is providing a response data type which
> > 	does not have a GDD primitive type that is (scalar or array of)
> > 	string.
> I completely don't understand this sentence. The gateway fetches the
> native type from the ioc and provides a string or a number depending on
> the request type of the client, right?

Again I think that confusion can result because of choice of perspective.
Perhaps this can be clarified by showing what happens when a new PV
is established in the gateway.

o First, a ca client of the PCAS in the gateway searches for PV XXXX.
o The PCAS asks its service (the gateway) if it has this PV XXXX.
o The gateway creates a ca client channel called XXXX.
o This ca client channel connects
o The gateway informs the PCAS that channel XXXX does exist
o The PCAS creates a PV in its service (the gateway) called XXXX
o The gateway informs the PCAS that XXXX is in fact of
native type enumerated
o The PCAS starts a read request with its service (the gateway)
requesting GDD application type "enumerated state set string table"
o The gateway sends a ca client get request to the IOC asking 
for type DBR_CTRL_ENUM
o the gateway hopefully extracts the string table out of the 
dbr_ctrl_enum and replies to the read request from the PCAS
for GDD application type "enumerated state set string table"
with a primitive type which is "array of strings", but in this
situation it appears that that things didn?t go as planned.

> > o this is not a useful response for the server so it is printing a
> > 	(could be easier to understand) message
> In the context where the message is printed, neither the PV name nor the
> contents of the string or enum table seem to be known. 

Actually, its within casPVI::updateEnumStringTableAsyncCompletion which
should definitely have access to the name of the PV, via a virtual 
function in casPV accessed via casPVI's reference to casPV (working 
from memory). So I agree that this is a defect that can be fixed and I 
did create a bug entry against the PCAS in launchpad.

> Furthermore the
> function returns void and does not trow exceptions. Thus the caller who
> might have these information cannot know about any problems and cannot
> provide a useful context.

It is very typical for callback methods to return void, and not throw 
exceptions. 

In this situation the PCAS has deduced that the gateway has 
not provided, in response to the PCAS's read request, the application type 
that was requested. This was deduced because the primitive type was not 
array or scalar string. Throwing an exception back at the gateway would 
not be likely to improve the situation. The gateway would be very
unlikely to catch the exception and respond again with different data
seeing as its probably confused about what it needed to provide in the 
first place.

So IMHO a message is the appropriate response, and of course we will need
to find out more about what happened in the gateway.

> > o once this happens I doubt that the server will successfully provide
> > 	the enumerated string table meta data to its clients
> >
> I have no idea what the client actually requested. I also don't know who
> the client is or which PV is affected. All useful context information is
> missing.

We hopefully know what the PCAS requested because we are in its read
response 
callback casPVI::updateEnumStringTableAsyncCompletion.

> I also don't know who
> the client is or which PV is affected. All useful context information is
> missing.

The PCAS asks for a copy of the string table when the new PV is created,
in order to populate its cache, independent of what its clients ask for.

> I think first an improvement in cas and gdd is necessary to allow to
> track down any potential bug in the gateway.

I agree completely that the message from the PCAS could be improved, but I
wouldn?t 
give up necessarily. Many programmers use only print statements to debug,
but IMHO 
source code debuggers are much easier and more productive approach. You do
have to 
recompile for debugging.

Admittedly, I will have troubles pointing the source code debugger at the 
issue if I can't reproduce it here, and you will have a better chance
at figuring out how to reproduce the issue if you have a better message.

Inside of casPVI::updateEnumStringTableAsyncCompletion one can get the 
channel name like this.

printf ("PV name is \"%s\\n", this->pPV->getName () );

Thanks for your help,

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: Dirk Zimoch [mailto:[email protected]]
> Sent: Thursday, September 16, 2010 7:28 AM
> To: Jeff Hill
> Cc: 'EPICS'
> Subject: Re: Strange gateway error message
> 
> Jeff,
> 
> Unfortunately I don't understand your reply.
> 
> Jeff Hill wrote:
> > Dirk,
> >
> > The following is probably occurring.
> >
> > o the ca service (the gateway) has a PV who's native type is advertised
> > 	to be enumerated (i.e. menu)
> 
> Shouldn't that be:
> the *ioc* has a pv who's native type is advertised to be enumerated
> 
> > o the ca server is fetching the enumerated state set string table
> > 	application type from the ca service (the gateway). That typically
> > 	occurs when the ca server attaches to an enumerated pv and it needs
> > 	to initialize its cache for the enumerated state set string table.
> And this:
> the ca *client* is fetching the enumerated state set string table
> application type from the gateway. That typically occurs when the ca
> *client* attaches to an enumerated pv...
> 
> > o the ca service (the gateway) is providing a response data type which
> > 	does not have a GDD primitive type that is (scalar or array of)
> > 	string.
> I completely don't understand this sentence. The gateway fetches the
> native type from the ioc and provides a string or a number depending on
> the request type of the client, right?
> 
> > o this is not a useful response for the server so it is printing a
> > 	(could be easier to understand) message
> In the context where the message is printed, neither the PV name nor the
> contents of the string or enum table seem to be known. Furthermore the
> function returns void and does not trow exceptions. Thus the caller who
> might have these information cannot know about any problems and cannot
> provide a useful context.
> 
> > o once this happens I doubt that the server will successfully provide
> > 	the enumerated string table meta data to its clients
> >
> I have no idea what the client actually requested. I also don't know who
> the client is or which PV is affected. All useful context information is
> missing.
> 
> > The message from the portable server could use some work so I created
bug id
> >
> > 638288 at the launchpad EPICS site.
> >
> > The root cause of this situation is possibly an issue in the EPICS
gateway.
> 
> I think first an improvement in cas and gdd is necessary to allow to
> track down any potential bug in the gateway.
> 
> > I must admit that I don?t know at the moment where one would properly
enter
> > a bug
> > against the EPICS gateway; probably the Mantis maintained bug tracker
> > entries for
> > the EPICS gateway on the EPICS site are now deprecated?
> >
> > 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 Dirk Zimoch
> >> Sent: Tuesday, September 14, 2010 3:02 AM
> >> To: EPICS
> >> Subject: Strange gateway error message
> >>
> >> Hi all, (Jeff in particular)
> >>
> >> Sometime I see in the CA gateway log file entries like this:
> >>
> >> filename="../../../../src/cas/generic/casPVI.cc" line number=251
> >> Bad data type application type "enums" string conversion table for
> >> enumerated PV isnt a string type?
> >>
> >> Can anyone tell me what this means? Unfortunately it does not print any
> >> context like PV name or involved enum strings. So the problem is quite
> >> hard to debug.
> >>
> >> The message comes from
> >> void casPVI::updateEnumStringTableAsyncCompletion(const gdd & resp)
> >>
> >> I suspect this may happen when the enum string set has been modified on
> >> the IOC while the channel is connected though the gateway.
> >>
> >> Dirk
> >
> >

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System