RE: gateway enum writes

["Kenneth Evans, Jr." <evans@aps.anl.gov>]

> One could speculate that the original GW design might have intended to
> perform all puts with completion notification in order to know exactly
when
> to update the GW's cache. 

> One could further speculate that a solution, for the GW, might be to not
> start a write for a channel if a write is already outstanding on that same
> channel. Instead the GW might save the value from the last write request
for
> a busy channel and initiate another write request using this saved value
as
> soon as the outstanding write request completes. 

     That is what it does.

	-Ken

-----Original Message-----
From: Jeff Hill [mailto:johill@lanl.gov] 
Sent: Wednesday, March 29, 2006 9:57 AM
To: 'Dirk Zimoch'; 'Leicester, PJ (Pete)'
Cc: 'Tim Mooney'; tech-talk@aps.anl.gov; 'Ken Evans'
Subject: RE: gateway enum writes


Here my two centi-euro's worth.

> if (ctx.getMsg()->m_cmmd == CA_PROTO_WRITE_NOTIFY) {
>    docallback == GATE_DOCALLBACK;
> } else {
>    docallback == GATE_NOCALLBACK;
> }

The context (in this case the variable is named ctx) is a class whose
definition is private to the portable server and subject to change in the
future. Its header file is typically not installed for public consumption.
We would not want, for example, to have the gateway code become too
dependent on the internal details of the server or its protocol. That might
create maintenance headaches.

One could speculate that the original GW design might have intended to
perform all puts with completion notification in order to know exactly when
to update the GW's cache. 

Nevertheless, use of put callback just might cause behavior problems for the
gateway if the destination record takes a long time to complete the write
request, and a 2nd write is started while the GW has a write to the same
record in progress. That would block the incoming protocol stream from the
GW to the IOC (for all channels on that IOC). The CA server is unable to
initiate another put notify request with this record until it completes the
put notify request that is pending, and in that situation the current server
design suspends processing of incoming requests until it can initiate the
put notify request (when the record completes processing).

One could further speculate that a solution, for the GW, might be to not
start a write for a channel if a write is already outstanding on that same
channel. Instead the GW might save the value from the last write request for
a busy channel and initiate another write request using this saved value as
soon as the outstanding write request completes.

Jeff

> -----Original Message-----
> From: Dirk Zimoch [mailto:dirk.zimoch@psi.ch]
> Sent: Wednesday, March 29, 2006 4:41 AM
> To: Leicester, PJ (Pete)
> Cc: Tim Mooney; tech-talk@aps.anl.gov; Ken Evans
> Subject: Re: gateway enum writes
> 
> This is from the gateway code (gateVc.cc):
> 
> caStatus gateVcData::write(const casCtx& ctx, const gdd& dd, gateChan
> &/*chan*/)
> {
> 	int docallback=GATE_DOCALLBACK;
> 
> [...]
> 	switch(at) {
> [...]
> 	case gddAppType_ackt:
> 	case gddAppType_acks:
> 		docallback = GATE_NOCALLBACK;
> 		// Fall through
> 	default:
> [...]
> 			caStatus stat = pv->put(&dd, docallback);
> 			if(stat != S_casApp_success) return stat;
> 
> 			if(docallback) {
> 				// Start a pending write
> #if DEBUG_GDD
> 				fflush(stderr);
> 				printf("pending_write\n");
> 				fflush(stdout);
> #endif
> 				pending_write = new
gatePendingWrite(*this,ctx,dd);
> 				if(!pending_write) return S_casApp_noMemory;
> 				else return S_casApp_asyncCompletion;
> 			} else {
> 				return S_casApp_success;
> 			}
> 
> It seems that ALL puts except alarm handler ackt and acks are done with
> callback. There is no direct flag to write() from the generic CA server
> which indicates writes with or without callback, as far as I can see.
> But the gateway should have look at the CA command in ctx, probably like
> this:
> 
> if (ctx.getMsg()->m_cmmd == CA_PROTO_WRITE_NOTIFY) {
>    docallback == GATE_DOCALLBACK;
> } else {
>    docallback == GATE_NOCALLBACK;
> }
> 
> 
> Dirk
> 
> 
> Leicester, PJ (Pete) wrote:
> > I can confirm that the problem appears isolated to the scaler record CNT
> > field and not enums in general.
> >
> > It looks like Tim's ca_put_callback theory may be correct. Is there a
> > Gateway expert out there who can confirm this? How are writes done from
> > the Gateway. Does it always use ca_put_callback regardless of how the
> > put reached the gateway?
> >
> > Thanks for everyones responses on this.
> >
> > Pete Leicester
> > Diamond
> >
> > -----Original Message-----
> > From: Tim Mooney [mailto:mooney@aps.anl.gov]
> > Sent: 28 March 2006 21:07
> > To: Leicester, PJ (Pete)
> > Cc: tech-talk@aps.anl.gov
> > Subject: Re: gateway enum writes
> >
> >
> > Leicester, PJ (Pete) wrote:
> >
> >>I am getting some strange behaviour when writing enumerations through
> >>the Gateway (version 2.0.0.0 on 3.14.8.2 and RedHat Enterprise 4).
> >>
> >>The problem first showed itself in edm when pressing a button on a edm
> >>screen to send the value resulted in the following error:
> >>
> >>    CA.Client.Exception...............................................
> >>        Warning: "Virtual circuit unresponsive"
> >>        Context: "diamrs0005l.diamond.ac.uk:6064"
> >>        Source File: ../tcpiiu.cpp line 896
> >>        Current Time: Tue Mar 28 2006 16:19:01.334736000
> >>    ..................................................................
> >>
> >>I did some further tests using caput with similar results:
> >>
> >>    [pjl45@pc0005 pjl45]$ caput  -w15 GDA:scaler2.CNT Count
> >>    Old : GDA:scaler2.CNT                Done
> >>    Read operation timed out: PV data was not read.
> >>    New : GDA:scaler2.CNT
> >>    CA.Client.Exception...............................................
> >>        Warning: "Virtual circuit disconnect"
> >>        Context: "op=0, channel=GDA:scaler2.CNT, type=DBR_TIME_STRING,
> >>count=1, ctx="diamrs0005l.diamond.ac.uk:6064""
> >>        Source File: ../getCopy.cpp line 82
> >>        Current Time: Tue Mar 28 2006 17:04:24.488496000
> >>.
> >>Despite the above error message the write does actually reach the IOC.
> >>However if I now try the change the value back as follows:
> >>
> >>    [pjl45@pc0005 pjl45]$ caput  -w15 GDA:scaler2.CNT Done
> >>    Old : GDA:scaler2.CNT                Count
> >>    Read operation timed out: PV data was not read.
> >>    New : GDA:scaler2.CNT
> >>    CA.Client.Exception...............................................
> >>        Warning: "Virtual circuit disconnect"
> >>        Context: "op=0, channel=GDA:scaler2.CNT, type=DBR_TIME_STRING,
> >>count=1, ctx="diamrs0005l.diamond.ac.uk:6064""
> >>        Source File: ../getCopy.cpp line 82
> >>        Current Time: Tue Mar 28 2006 17:22:36.167980000
> >>    ..................................................................
> >>
> >>I get an error again however this time the 'Done' value gets written
> >>to
> >>the IOC exactly ONE MINUTE after I entered the caput command. This is
> >>long after the caput command has timed out so it appears the gateway
> >
> > is
> >
> >>responsible for the delay?
> >>
> >>Has anyone any idea what may be happening? Is there a 60 second
> >>timeout
> >>in CA or the gateway which may give a clue as to what I am seeing?
> >>
> >>(For the record this test was done with a very lightly loaded test
> >>gateway serving only 20 or so PV's. Also using caput -w70 results in
> >
> > the
> >
> >>same timeouts)
> >
> >
> > Do you get this kind of result with *all* enum fields that you write to
> > through the gateway, or only this one?  The scaler record's CNT field is
> > different from other enum's in that it starts an operation that may take
> > a long time to complete.  I don't know what the gateway is using to do
> > put's, but if it should happen to be ca_put_callback(), the gateway may
> > be waiting for a callback that will come only after the scaler has
> > finished counting.
> >
> 
> --
> Dr. Dirk Zimoch
> Swiss Light Source
> Paul Scherrer Institut
> Computing and Controls
> phone +41 56 310 5182
> fax   +41 56 310 4413