Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Fri, 8 May 2009 09:45:13 -0600

Dirk,

In the PCAS, when the server initiates a read request with the service the
service has three options. It can complete the request immediately, it can
complete the request asynchronously, or it can postpone the request till
later if too many asynchronous requests are already in progress. Since it is
a single threaded server the service isn't allowed to block when too many
asynchronous requests are outstanding. If the service returns status
requesting postponement then the server has the hard job of remembering
where it was with a particular client and, knowing how to resume the request
later once some of the asynchronous IO completes, go off and take care of
other clients.

When the server is setting up a channel whose native type is enumerated it
must fetch the string table from the service using a read request, and cache
this value for use later when converting between types. This is a _once_
only request, it is the first IO request to the channel so no requests are
outstanding at that time, and restarting the multi-step channel create
operation is very complicated, so it seemed sensible (when I wrote that
code) to not support postponement of this particular request.

It is possibly a bug in, or at least an odd design of, the GW that it wants
to postpone the first read request issued to the channel. A possibly better
alternative of course would be to complete the read request asynchronously.
The postponement option was originally intended to be used when at least one
asynchronous IO request is already outstanding against the channel. If the
GW does not have any asynchronous IO outstanding against the channel, then
the server has no way to be asynchronous notified when the IO is done so
that it can resume requests with the channel immediately when a new request
can be started.

This type of headache is one reason why I converted the client library to
fully threaded operation for R3.14, and PCAS is being converted to fully
threaded operation for R3.15.

I created Mantis 339 to track the issue. The entry currently is against
PCAS. We will need to decide on which side of the fence it needs to be fixed
(PCAS or GW). 

Jeff

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Behalf Of Dirk Zimoch
> Sent: Friday, May 08, 2009 8:08 AM
> To: tech-talk
> Subject: CAS problem?
> 
> Hi all, (Jeff, Gasper, others?)
> 
> Today I got the following error message when trying to read through a CA
> gateway:
> 
> Invalid channel identifier
> host=x05da-cagw-psi.ch:5064 ctx=Bad Resource ID=2172742414 detected
> at ../../../../src/cas/generic/casStrmClient.cc.1700
> 
> On the gateway I found this error log:
> 
> --*snip*------------------------------------------------------------
> CAS Request: e11277 on x05da-cons-1: cmd=12 cid=2172742414 typ=0 cnt=0
> psz=0 avail=1
> filename="../../../../src/cas/generic/casStrmClient.cc" line number=1389
> postpone asynchronous IO - enum string tbl cache read ASYNC IO postponed ?
> 
> May 01 10:28:52 !!! Errlog message received (message is above)
> The server library does not currently support postponment of
> 
> May 01 10:28:52 !!! Errlog message received (message is above)
> string table cache update of casChannel::read().
> 
> May 01 10:28:52 !!! Errlog message received (message is above)
> To postpone this request please postpone the PC attach IO request.
> 
> May 01 10:28:52 !!! Errlog message received (message is above)
> String table cache update did not occur.
> 
> May 01 10:28:52 !!! Errlog message received (message is above)
> --*snip*------------------------------------------------------------
> 
> Any idea what went wrong? Gateway and caget both use 3.14.8.2.
> 
> Dirk
> 
> --
> Dr. Dirk Zimoch
> Paul Scherrer Institut, WBGB/006
> 5232 Villigen PSI, Switzerland
> Phone +41 56 310 5182

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System