Jeff.
Thanks for your reply.
Jeff Hill wrote:
1) Be careful about using R3.14's new feature allowing preemptive
callback with EZCA. Being a legacy single threaded code, the EZCA
library probably isn't properly protected against CA callbacks occurring
preemptively from another thread, at any time, even when it is not
executing in a CA function.
I guess it's not safe.
2) If the CA client library does not see the server's beacon then it
sends an "are you there" message to the server over TCP. It is supposed
to work (in preemptive callback mode or otherwise) in a way that if you
do not call ca_pend_event() very often and a UDP beacon is lost, then it
will still send the "are you there" message and will not disconnect
until ca_pend_event() is called again and the "are you there" has not
been replied to within a reasonable amount of time.
3) This disconnect message that you are seeing, assuming that it is not
the false message occurring only when the process calls ca_task_exit()
I believe that not being the case. ezca never calls ca_task_exit().
BTW: I could distill a trivial test program (attached) to reproduce the
problem. It essentially does:
ezcaGet();
sleep(120);
ezcaGet();
After about 1min, the message:
Unable to contact CA repeater after 50 tries
Silence this message by starting a CA repeater daemon
appears (note that I _have_ a repeater running) when the
2min expire and the second ezcaGet() attempt is made, I
finally get the message (2nd ezcaGet() fails):
CA.Client.Exception...............................................
Warning: "Virtual circuit disconnect"
Context: "134.79.35.35:5064"
Source File: ../cac.cpp line 1809
Current Time: Thu Dec 05 2002 12:29:24.852541000
..................................................................
get_callback() : Virtual circuit disconnect
Neither of these messages appears when I either enable the preemptive
callback or when I use ezcaDelay() instead of sleep() (I suppose because
the ezcaDelay() does ca_pend()).
-- Till
and channels are still connected (that has been fixed after R3.14 beta
2), could be a bug related to proper implementation of (2) above.
However you are using R3.14 beta one which was a very preliminary (and
certainly buggy) release of R3.14. Given that we are about to release
R3.13.1, then it would be very interesting (at least for me) to see if
the same problem exists with R3.14 beta 2 and ezca.
Jeff
-----Original Message-----
From: Till Straumann [mailto:[email protected]]
Sent: Wednesday, December 04, 2002 9:24 PM
To: Jeff Hill
Cc: 'Tech-talk'
Subject: Re: libezca and EPICS-3.14
Having Stephanie next door pays off :-)
My application behaves like this:
ezcaGet();
/* user works; this can take minutes, hours, days */
ezcaGet();
/* second ezcaGet() fails if more than ~80sec expire
* between the ezca calls
*/
Steph pointed out that the CA library still needs to handle
beacons even when idle and recommended to initialize the
application's CA context with ca_enable_preemptive_callback.
As a (undocumented) side effect, this would result in beacons
being handled by one of the CA background threads.
(At least, this is what I recall from our conversation - if
not completely accurate, I'm to blame for misquoting)
Anyways, this helped, the disconnects are gone and I'm happy
because I no longer need 3.13 around :-)
-- Till
PS: the app now does
ca_context_create(ca_enable_preemptive_callback);
...
ezcaGet();
/* user works for hours */
ezcaGet();
/* SUCCESS */
Jeff Hill wrote:
CA.Client.Exception..........................................
..
...
Warning: "Virtual circuit disconnect"
Context: "134.79.35.35:5064"
Source File: ../cac.cpp line 1809
Current Time: Wed Dec 04 2002 13:48:18.219267000
.............................................................
..
Do you know for certain that the "read command" is failing or
are you
encountering the following situation?
In R3.14 beta 1 and beta 2 the ca client library will print
the above
message if a connected channel still exists when you call
ca_task_exit(). To remain strictly backwards compatibility
this message
is suppressed, only for this specific situation, in the
latest version
of R3.14.
Does ezca block in ca_pend_io() when it is waiting for the
"read
command" to complete? If so, then how long is the timeout
which is
provided to ca_pend_io()?
Jeff
-----Original Message-----
From: Till Straumann [mailto:[email protected]]
Sent: Wednesday, December 04, 2002 3:12 PM
To: Tech-talk
Subject: libezca and EPICS-3.14
Hi.
I discussed this briefly with Marty at JLAB. He suggested
I should post to the list. I was not sure whether the
EZCA library is supported under 3.14.
Here's my problem:
I have put together a CA interface for SCILAB (a nice open
source tool a la matlab) who builds on top of libezca. Works
fine with 3.13.
Using 3.14_beta1, I can access (e.g. read using ezcaget) a PV
into SCILAB without problem. An attempt to access the same PV
a couple of minutes later fails, however, giving the
following
error:
CA.Client.Exception..........................................
..
...
Warning: "Virtual circuit disconnect"
Context: "134.79.35.35:5064"
Source File: ../cac.cpp line 1809
Current Time: Wed Dec 04 2002 13:48:18.219267000
.............................................................
..
.....
Strange enough, if I repeat the read command for a couple
of times, it works again. Let some time expire and it again
fails.
And so on.
Does somebody have an explanation or, yet better, a fix?
-- Till
- References:
- RE: libezca and EPICS-3.14 Jeff Hill
- Navigate by Date:
- Prev:
RE: libezca and EPICS-3.14 Jeff Hill
- Next:
Re: Building 3.13Extensions with 3.14 base Problem. Andrew Johnson
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
<2002>
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: libezca and EPICS-3.14 Jeff Hill
- Next:
Re: libezca and EPICS-3.14 Till Straumann
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
<2002>
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|