0. Preliminaries, 5 mins
1. Modules for 4.4 release bundle (Greg).
2. Proposal and practicality of concentrating on only 2 items next year,
Gateway, dbGroup and areaDetector. (Bob and Greg)
3. Sorting out Normative Types.
a. How we got here and how not to get here again.
b. Type identification plan - we stay with type identification as is,
until after the 4.4 release and the next NT release, when, if there is a
well researched and written alternative proposed, we can vote on it.
3. If time remaining, status reports (everyone)
Present: AJ, MK, MS, NM, RL, GW, MS, GS, GC
TOPIC 1. Modules for 4.4 release
# 4.4-pre1 Java Module MP
EPICS-Java-4.4.0-pre1 pvDataJava MK
EPICS-Java-4.4.0-pre1 pvAccessJava MS
EPICS-Java-4.4.0-pre1 easyPVAJava MK
EPICS-Java-4.4.0-pre1 exampleJava GW
EPICS-Java-4.4.0-pre1 caj MS
EPICS-Java-4.4.0-pre1 jca MS
EPICS-Java-4.4.0-pre1 directoryService RL
# 4.4-pre1 CPP
EPICS-CPP-4.4.0-pre1 pvCommonCPP MS
EPICS-CPP-4.4.0-pre1 pvDataCPP MK
EPICS-CPP-4.4.0-pre1 pvAccessCPP MS
EPICS-CPP-4.4.0-pre1 pvDatabaseCPP MK
EPICS-CPP-4.4.0-pre1 exampleCPP DH
EPICS-CPP-4.4.0-pre1 pvaSrv RL
EPICS-CPP-4.4.0-pre1 normativeTypesCPP MS
EPICS-CPP-4.4.0-pre1 pvaPy SV
MK: do we need a branch for this release
RL: procedure is described in the document
RL: yes. document will be updated
GW: each module will have its own version unrelated with the epics V4 release
RESOLUTION: pvIOCCPP shall not be bundled in v4.4. pvIOCJava shall not be bundled in v4.4.
AI on RL by 4-Sep-14: will update the release document with the branching procedure (asap)
GS: Why are we bundling caj and jca
MK: So that a user can use the pvAccess API to talk to an IOC that has no v4 module in it (i.e. no pvaSrv).
GC: problem with threads
TOPIC: Version requirement of EPICS IOC for v4 CA interoperability.
GC/MS: There have been observed deadlock issues with caj and jca with versions of EPICS IOC prior to v3.14.
GC: It’s extremely difficult (i.e. impossible) to write a client that is fully thread-safe on any implementation of caj/jca, because the thread policy/locking is different. Some internal locks are exposed, no guarantee on which thread the callback can happen, therefore it is difficult to avoid deadlocks in general.
MS: The issue is in 3.13
AJ: But 3.13 can’t be changed, the client side has to be changed
AI on MS . The interoperability document being prepared by MS needs to address requirement of IOC version, presently 3.14.
AI on MS: Make pvAccessCPP CA provider able to select JCA implementation (CAJ vs. JNI JCA). Document this.
In summary CAJ has some deadlock issues with 3.13. JCA does not. Presently, CAJ is our default. So, we need to tell people who want to want to interop with 3.13, that they should switch to JCA, in particular if they use access security. .
GC: we need a test suite caj/jca against different version of IOCs (3.13, 3.14, etc.). There is some suite within diiirt, but it should be extended
GW: This is a big task and should be defined by AJ. Also it must be a topic of the Saclay meeting
TOPIC 2. Next year
GW: proposal of two priorities for next year are gateway and “multi” (with multiple aspects) for most of the group. Depending on whether the same developers would be involved or not, areaDetector may be second priority.
TOPIC 3. Normative Types
AI: GW will create the second branch and update the corresponding document.
Meeting ends 9.03 PST