- pvaSrv put behavior 
- what’s up with exampleJava?
- rc1 readiness and schedule (new tags will be needed, and therefore
dependencies re tagged also).
Present: AJ, DH, GC, MK, MS, RL, GW
NEW TOPIC: pvaSrv put behavior
MK: if you have process true, and block false, then it just calls …. and it’s done.
Before, he was going through notify code. now he directly call dbProcess.
dbProcess does not hang. If it had already started process, then it continued.
[not sure I got all of this]
MK: so we need DH to check proper functionality now
DH: <doesn’t understand hg tags [for pvaSrv]>
<meeting can’t see where ralph made relevant changes>
MK <brings rl up to date>
MK: I found it on 0.1.0
RL: The Thursday change is the code MK was proposing,but does not solve your problem
DH: the thing that doesn’t work is if the put doesn’t work, nothing cleans up
RL: the notify doesn’t get called, so the [channel] doesn’t get cleaned up
MS: pvaccess server code creates a “channel” that takes a ref to a channel. The pvserver (pvasrv) should create the channel. There may be a circular dependency - we have to check
RL: I see the channel being destroyed.
When putDone is called, the channel is destroyed
RL: regular operation:
[RL describes regular operation, and the circumstances in which putDestry is not called]
MS: pvaSrv does call destroy on a channel only. It is the channel’s responsibility to clean up the channel.
RL: ok, I know what I have to do.
MK: But I’m not sure if that’s true [couldn’t catch whey]
MS: for that case [of MK] use shared pointers
MK: you have a list of channels already at [?] level, now you are suggesting a channel must also keep a list. Is that sensible
RL; Matej and I can sort this out
MK: and include me
AJ: ok we will fix this in email
aj: can we fix it prior to release?
aj: i think it’s reasonable for this to go in
RL: but it’s a very special case - it’s a use case which uses the busyRecord beyond its documentation
Resolution: We await fixing of the pvaSrv fix, it will be included when it’s ready but won’t compromise the final release (include in -rc1 if by end of this week, in -rc2 if next week). Will come out with a 4.4.1 release soon afterwards if it takes longer.
NEW TOPIC: What’s up with exampleJava?
GW: Nothing now [it’s fixed]. 2 things held up: exampleJava with the flow model, GW gets error message that Ralph doesn’t. 2 issues: directoryService version number; caj & jca not in our maven area so not included in package from remotes.
GC: They are in maven central. The mvn repo on SF should be phased out, use maven central.
GW: Nobody made that decision.
GC: JCA & CAJ have not been updated on SF in 18 months.
MS: Talking about moving all our modules to maven central.
GC: Can you change the script to get them from maven central?
GW: Just change the URL? Compatible?
GC: Final releases are at
Released version: https://repo1.maven.org/maven2/org/epics/caj/1.1.14/
AI on GW: Modify the Makefile script to take jca & caj from maven central
AI on MS & GC: Move other core modules to Maven Central
GC: Maven can automake creating tar files with build info, I can help with that.
NEW TOPIC: readiness and schedule
AJ: Nominally then we decided on an rc1 next week. And rc2 a week later.
AJ: Is that ok with DH?
AJ: so we will be preparing rc1 on november the 24th, rc2 on Dec 1st.
AJ: If all the changes we have been waiting for [to pvaSrv in particular] are in rc1, then we don’t necessarily need an rc2.
--- Meeting ends 8:48 PST ---