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
- References:
- CAS problem? Dirk Zimoch
- Navigate by Date:
- Prev:
CAS problem? Dirk Zimoch
- Next:
Re: DIfficulty with Libusb with EPICS Lawrence T. Hoff
- 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:
CAS problem? Dirk Zimoch
- Next:
RE: Problem with WIN32 Mark Rivers
- 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
|