RE: CA error

[john sinclair <sinclair@mail.phy.ornl.gov>]

On Wed, 30 Oct 2002, Jeff Hill wrote:

> 
> > 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.

I am getting callbacks from ca_get_callback with status
set to ECA_DISCONN but I have not yet seen an event
callback with status set to ECA_DISCONN.

So, are you saying that I should not have to consider the
possibility of getting an event callback with status
set to ECA_DISCONN?

Sorry if I appear confused.

John







> 
> 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)
> 
> 

John Sinclair
sinclair@mail.phy.ornl.gov
Oak Ridge National Lab
865-576-6362   865-574-1268 (fax)