RE: CA error

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

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

The callback order at channel disconnect is always as follows.

1) IO request disconnect callbacks
2) Connection state callback
3) Access rights state callback

It's true that the CA client library does *not* call the monitor
subscription update event callback handler with status set to
ECA_DISCONN when the channel disconnects. This was a GTA
era decision that was probably wrong. The CA client interface
would probably be simpler and easier to use if a monitor
subscription could be used also to monitor the connection
state. This has come up before, but the decision was always
to maintain strictly the same behavior as in the past. However,
since all clients should be checking the status field its
not strictly an interface change to introduce this behavior.
The most likely outcome from legacy clients that have not been
updated would be extra messages, but perhaps worse problems are also
possible. This could be discussed at the upcoming EPICS internals
meeting.

Jeff

> -----Original Message-----
> From: john sinclair [mailto:sinclair@mail.phy.ornl.gov]
> Sent: Wednesday, October 30, 2002 1:40 PM
> To: Jeff Hill
> Cc: 'EPICS-tech-talk'
> Subject: RE: CA error
>
> 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)