Experimental Physics and
Industrial Control System

Thomas Birke <[email protected]> · Tue, 16 Nov 2004 13:53:47 +0100

Jeff Hill wrote:
Hi Joan,
Would a misbehaving client(s) cause this behavior?

Yes, it appears that the client is attempting to convert “User Request
PS OFF” to a DBR_TIME_FLOAT. The client is receiving one of either
ECA_NOCONVERT or ECA_GETFAIL in response to its request.
The “ server tool changed bounds on request” text in the message isn’t
accurate. I will attend to that. You might see many, many messages if
the client was subscribed with an inappropriate type to a periodically
changing channel. Perhaps adding an entry in the log for a routine
situation like a conversion failure is only a nuisance. I think that
the original concern was that the type used internally by the server
plug-in (in this case a string inside the gateway) would unknown for
fault isolation purposes otherwise. What do you think?
Jeff
-----Original Message-----
*From:* [email protected] [mailto:[email protected]]
*Sent:* Tuesday, October 26, 2004 1:10 PM
*To:* [email protected]
*Subject:* gateway error message
We installed a new linux R3.14.6 gateway yesterday and in less than 24
hours

the log file filled up with ~48k lines of error messages, all referring

to the same pv. The error message is:
Oct 26 08:11:22 !!! Errlog message received (message is above)

----------dump This=0xa0a9c28---------

dimension=0 app-type=16 Scalar

prim-type=aitString(aitEnumString)

this=0xa0a9c28 string=0x4041eac8<User Request PS OFF>, length=19, buf
length=20, type=Allocated

ref-count=1

total-bytes=64, data-size=28, element-count=1

LocalDataFormat

--------------------------------------

filename="../../../../src/cas/generic/casStrmClient.cc" line number=607

server tool changed bounds on request - get notify with PV=TMMSTATUS
type=16 count=1
The addresses following "dump This", and "string=" change with each
message.
The pv in question, TMMSTATUS, is a string out record, written to very
seldom

by a sequencer code. We don't know anything at this time about clients
using this record.
Would a misbehaving client(s) cause this behavior? Is it really an
error? Is the client

getting its data in spite of the message? If data is being delivered,
it might be much

harder to find the "bad" client?
Or am I way off track?
Has anyone else seen this?
Actually it seems, we are seeing exactly the same problem here at BESSY.
I'd just like to add some observations we made.
1. Everything is running fine for quite a while (days, weeks or even more).

"Suddenly" clients accessing PVs through this gatweway get the following
error:
CA.Client.Diagnostic..............................................

Message: "Could not perform a database value get for that channel"

Severity: "Warning" Context: "detected by: gwc1c.acc.bessy.de:5064 for:
server tool changed bounds on request - with request chan=H1PT:stat2
op=0 data type=DBR_STS_DOUBLE count=1"

The operation timed out: H1PT:stat2..............................
At the same time the above mentioned errormessage appears in the gateway
log.
2. We could just see this with PVs that are actually bi-records (enum...)
3. A restart of the gateway makes the problem disappear - for a while.
4. We have no idea what causes the problem to appear.
My guess would be, that the gateway is the "misbehaving client", but I
don't know under what circumstances the problems can be reproduced.
We don't really know what to look for, but we could give more diagnostic
output on request.

The gateway-output on a kill -USR1 looks perfectly healthy...
Thomas
--
______________________________________________________________________
/homas.Birke @ bessy.de
BESSY                                           Tel: +49 30 6392 4934
Albert Einstein Straße 15                       Fax: +49 30 6392 4859
12489 Berlin
Germany

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System