EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: JCA problems and questions
From: "Chu, Paul" <[email protected]>
To: Matej Sekoranja <[email protected]>, Till Straumann <[email protected]>
Cc: "[email protected]" <[email protected]>
Date: Thu, 25 Oct 2012 14:30:14 +0000

Hi Matej,

 

Thanks for clarifying this.  I just browsed the JCA-2.3.6 and caj-1.1.10 source code to confirm.  This means my latest modification didn’t get into the official version.

 

In the official version the complete flow in the code is the following:

1.       Check jca.use_env=true/false (alternatively one can also use the protected variable gov.aps.jca.jni.JNIContext.use_env)

2.       If use_env = true: check if any of these EPICS environment variables (EPICS_CA_ADDR_LIST… only 7 of them)  defined, if defined, use them; if not, still use whatever in the JCALibrary.properties

3.       If use_env = false: read parameters from JCALibrary.properties

 

This has some flaws:

1.       If some JCA parameters are not defined as EPICS environment variables, they will never be read in.

2.       If developer would like to try a different parameter setting, she/he has to change the environment variable instead of editing JCALibrary.properties or using –D…  This is rather inconvenient and dangerous.

 

What I stated in my earlier message was the consensus we had at SLAC which covered both consistency for system maintainers and flexibility for developers.

 

I will send you my (SLAC) version of the source code for you to see.

 

Thanks,

Paul

 

From: [email protected] [mailto:[email protected]] On Behalf Of Matej Sekoranja
Sent: Thursday, October 25, 2012 5:10 AM
To: Till Straumann
Cc: Chu, Paul; Mark Rivers; [email protected]
Subject: Re: JCA problems and questions

 

Till is right. It system env. (C++ style) or JCA style.

"jca.use_env" must be given via JVM (-D) option.

 

Matej

 

On Wed, Oct 24, 2012 at 1:04 AM, Till Straumann <[email protected]> wrote:

Is that really true? The way I recall it (but it has been a while I dived into that subject) is

if use_env property is true then
  1.
else
  2.
  3.
  4.
endif

- T.



On 10/23/2012 11:01 PM, Chu, Paul wrote:

When I first implemented this feature at SLAC, I believe JCA or CAJ took the following override order (higher number overrides lower ones, e.g. 2 overrides 1):

1. EPICS environment variables
2. System level JCALibrary.properties (in system JRE or JDK's lib folder)
3. User level JCALibrary.properties (e.g. in user's ~/.JCALibrary for Linux)
4. Command line -D option

Paul

-----Original Message-----
From: [email protected] [mailto:tech-talk-
[email protected]] On Behalf Of Mark Rivers
Sent: Tuesday, October 23, 2012 4:37 PM
To: 'Matej Sekoranja'; [email protected]
Subject: RE: JCA problems and questions

Hi Matej,

Thanks for the reply.

Lewis also pointed out the new feature of caj.use_env to have CAJ use the
traditional EPICS environment variables.  I am now using that in the
areaDetector ImageJ plugin.  However, I have a couple of questions:

- What is the order of obtaining values from a JCALibrary.properties file
versus the EPICS environment variables?

- Is the new caj.use_env documented anywhere except the single line in the
change notes?

Thanks,
Mark


From: [email protected] [mailto:tech-talk-
[email protected]] On Behalf Of Matej Sekoranja
Sent: Tuesday, October 23, 2012 3:33 PM
To: [email protected]
Subject: Re: JCA problems and questions

Hi,

Rok Sabjan notified me about this thread. Thanks to Lewis for replies.

The old send buffer algorithm was to initialize the send buffer size
to max_array_bytes and automatically resize on demand (there is one send
buffer per TCP connection). Not something one would dare to use on a
server, however very convenient on the client side.

However, if a client has a lot of connections there is a lot of memory required
when max_array_bytes is large (e.g. 100 connection * 10MB = 1GB!).
Current algorithm starts with an initial size of 1k that can be automatically
resized up to max_array_bytes.
This also mimics C++ CA algorithm (that has also evolved over the years).

Cheers,
Matej

 

 

 


References:
Re: JCA problems and questions Matej Sekoranja
RE: JCA problems and questions Mark Rivers
RE: JCA problems and questions Chu, Paul
Re: JCA problems and questions Till Straumann
Re: JCA problems and questions Matej Sekoranja

Navigate by Date:
Prev: RE: what are your definitions of softIOC and soft record? Hu, Yong
Next: Re: what are your definitions of softIOC and soft record? Ernest L. Williams Jr.
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: JCA problems and questions Mark Rivers
Next: RE: JCA problems and questions Zhou, Jingchen
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·