RE: CA error

["Jeff Hill" <johill@lanl.gov>]

> I also naively assumed that I wouldn't get event
> callbacks between disconnects and reconnects.

Looking in the source code for both R3.14 and R3.13 it
appears that the user's get callback function *is*
called with status set to ECA_DISCONN, indicating that the
request has been canceled, just prior to calling the users
connection callback handler. You should not be receiving
get callbacks between the connect and disconnect notification
callbacks. If you have evidence to the contrary then I
will need to investigate further.

Jeff


> -----Original Message-----
> From: john sinclair [mailto:sinclair@mail.phy.ornl.gov]
> Sent: Wednesday, October 30, 2002 8:49 AM
> To: Jeff Hill
> Cc: EPICS-tech-talk
> Subject: RE: CA error
>
> Jeff,
>
> I think everything is OK. I see that this is clearly the best way
> to do things from a performance perspective. I naively assumed that I
> would get all the get-callbacks based on a previous state. I also
> naively
> assumed that I wouldn't get event callbacks between disconnects and
> reconnects. Back to the drawing board...
>
> John
>
> On Tue, 29 Oct 2002, Jeff Hill wrote:
>
> >
> > John,
> >
> > Do you check the status from ca_get_callback() when you call it?
> > It's possible to get ECA_DISCONN back as status if the connection
> > is down at the instant that ca_get_callback() is called. You will
> > also see ECA_DISCONN in the status field of event_handler_args if
> > the virtual circuit disconnects sometime after the get callback
> > request is made, but before the response arrives from the server.
> >
> > If you think that your situation is occurring in a situation that is
> > not related to disconnects then I will need to research this in
> > more detail.
> >
> > Jeff
> >
> > > -----Original Message-----
> > > From: john sinclair [mailto:sinclair@mail.phy.ornl.gov]
> > > Sent: Tuesday, October 29, 2002 11:23 AM
> > > To: Jeff Hill
> > > Cc: 'tech talk'
> > > Subject: RE: CA error
> > >
> > >
> > > My mistake, the error is ECA_DISCONN (which makes more sense)
> > > and not ECA_ANACHRONISM (I shifted the value twice instead
> > > of 3 times).
> > >
> > > And, no, I'm not calling CA from a multi-threaded application.
> > >
> > > John
> > >
> > >
> > > On Tue, 29 Oct 2002, Jeff Hill wrote:
> > >
> > > >
> > > > John,
> > > >
> > > > >   examine args.status
> > > > >
> > > > >   // status here is sometimes ECA_ANACHRONISM
> > > > > Has this always been possible?
> > > >
> > > > I think you are asking if CA will set the status
> > > > field in the event_handler_args structure to
> > > > ECA_ANACHRONISM. The answer is no. I searched
> > > > all of the source code in the latest versions of
> > > > R3.13 and R3.14 and ECA_ANACHRONISM is returned
> > > > only when you call a very old CA interface from
> > > > R3.11 or probably earlier that is no-longer
> > > > supported.
> > > >
> > > > Are you calling CA from a multi-threaded
> > > > application?
> > > >
> > > > Jeff
> > > >
> > > > > -----Original Message-----
> > > > > From: john sinclair [mailto:sinclair@mail.phy.ornl.gov]
> > > > > Sent: Tuesday, October 29, 2002 10:48 AM
> > > > > To: tech talk
> > > > > Subject: CA error
> > > > >
> > > > > One stress test I have applied to edm is performing a
moderately
> > > rapid
> > > > > succession of connects/disconnects via a channel access
server.
> > > > >
> > > > > I have recently noticed one problem.
> > > > >
> > > > > The logical code structure is shown below:
> > > > >
> > > > >
> > > > >
> > > > > global needInit
> > > > >
> > > > > ==========================
> > > > >
> > > > > main routine:
> > > > >
> > > > > needInit = false
> > > > > search_and_connect
> > > > >
> > > > > do {
> > > > >   pend io, event
> > > > >   if ( needInit ) {  // needInit is set in the connect
callback
> > > > >     ca_get_callback(...)
> > > > >     needInit = false
> > > > >   }
> > > > > } until all outstanding io is complete
> > > > >
> > > > > ===========================
> > > > >
> > > > > connect_callback function (...) {
> > > > >
> > > > >   if ( pv is connected ) {
> > > > >     needInit = true
> > > > >   }
> > > > >   else {
> > > > >     needInit = false
> > > > >   }
> > > > >
> > > > > }
> > > > >
> > > > > ===========================
> > > > >
> > > > > get_callback function (
> > > > >   struct event_handler_args args
> > > > > ) {
> > > > >
> > > > >   examine args.status
> > > > >
> > > > >   // status here is sometimes ECA_ANACHRONISM
> > > > >   // and args.dbr is NULL
> > > > >
> > > > > }
> > > > >
> > > > >
> > > > >
> > > > > Has this always been possible? I'm sure I get the connect
> callback
> > > > > before
> > > > > the get callback (by examining other data that gets set in the
> > > connect
> > > > > callback {not shown in above simplified example}).
> > > > >
> > > > > John Sinclair
> > > > > sinclair@mail.phy.ornl.gov
> > > > > Oak Ridge National Lab
> > > > > 865-576-6362   865-574-1268 (fax)
> > > >
> > > >
> > >
> > > John Sinclair
> > > sinclair@mail.phy.ornl.gov
> > > Oak Ridge National Lab
> > > 865-576-6362   865-574-1268 (fax)
> >
> >
>
> John Sinclair
> sinclair@mail.phy.ornl.gov
> Oak Ridge National Lab
> 865-576-6362   865-574-1268 (fax)