PVManager creates another subscription after each 'disconnect'

[kasemir]

To reproduce, run softIoc with this example database on one computer:

record(calc, "ramp")
{
  field(INPA, "ramp")
  field(CALC, "A<10?A+1:0")
  field(SCAN, "1 second")
}

record(compress, "wf")
{
  field(INP, "ramp CP")
  field(ALG, "Circular Buffer")
  field(NSAM, "10")
}

On another computer, run two different versions of CSS 'probe' on those channels:

1. One older, utility.pv-based instance of CSS, like SNS 3.1.6, using one of the PVs.
2. One instance of a current CSS, based on pvmanager, using the other PV.

The exact PVs don't matter. Different PVs are simply used to identify the CSS client on the IOC.

Disconnect the network cable, wait for probe to show disconnect, reconnect the network cable, wait for reconnect.
Repeat a few times.

On the IOC, check casr 2:

Channel Access Server V4.13
Connected circuits:
TCP 160.91.233.73:59343(mac95088): User="ky9", V4.13, 2 Channels, Priority=0
...
    wf(5rw)
TCP 160.91.233.73:59344(mac95088): User="ky9", V4.13, 2 Channels, Priority=0
...
    ramp(1rw)   wf(1rw)

==>
After 5 network disconnects, the older CSS instance based on utility.pv, which in this example monitored both the "ramp" and "wf" channels, keeps only one connection.
The current CSS instance, based on pvmanager, which in this example only monitored the "wf" channel, creates a new subscription after each (re-)connection. In this example, it had 5 subscriptions.

Duplicate channel subscriptions, especially for waveforms, can significantly increased the IOC CPU load after such network hickups to the point where the IOC becomes unresponsive.

[kasemir]

Older version of CSS uses caj-1.1.10.jar
Newer version (which causes multiple subscriptions) uses caj-1.1.13.jar

Updated current snapshot of CSS ('master'):
Replaced caj-1.1.13.jar with caj-1.1.10.jar, commented this section from JCADataSource:

        try {
            if (ctxt instanceof CAJContext) {
//                ((CAJContext) ctxt).setDoNotShareChannels(true);
            }
        } catch (Throwable t) {
            log.log(Level.WARNING, "Couldn't change CAJContext to doNotShareChannels: this may cause some rare notification problems.", t);
        }

because setDoNotShareChannels() is not supported in caj-1.1.10.jar: Still getting a new subscription for each disconnect.

What might be a hint: utility.pv used to clear() the subscription on disconnect. When the connection is re-established, it would again query for meta data and subscribe to the native data type. Looks like

• handled changes in meta data
• handled changes in data type overall
• as a side effect, seemed to avoid a bug in CAJ that adds another subscription

[kasemir]

https://github.com/ControlSystemStudio/cs-studio/blob/master/core/plugins/org.csstudio.utility.pvmanager.epics/src/org/epics/pvmanager/jca/JCAChannelHandler.java actually seems to add additional subscriptions on each re-connect for Monitor.PROPERTY, if that is enabled.
needsMonitor is only used in there to prevent multiple addMonitor for the main subscription, not the one for Monitor.PROPERTY.

[kasemir]

#337 lists related tests

• Simple reboot: connect pv, ioc down, ioc up, only 1 monitor open
• Simple network outage: connect, network down, network up, only 1 monitor open

If those tests pass, this issue should also be solved.

[kasemir]

Eric had asked if this issue still persists.

Yes.

I checked the 'master' sources just now.

• Open Probe for the "ramp" example shown above, running on another computer.
• Unplug network cable, await probe showing disconnected state
• plug network cable back in, await probe to re-connect
  On the IOC, use "casr 2" to list the subscriptions.
  With each re-connect, pvmanager creates another subscription.

With org.csstudio.platform.libs.epics/dbe_property_supported=true, the pvmanager will create 2 subscriptions as expected: one for the value, one for the properties.
After each re-connect, there are then 2 additional subscriptions shown in "casr"

[kasemir]

No, please leave it open until it is fixed.
I've posted another comment with current test results, no change.

On Thu, Feb 6, 2014 at 11:37 AM, Eric Berryman notifications@github.comwrote:

Can I close this Kay?

Reply to this email directly or view it on GitHubhttps://github.com//issues/216#issuecomment-34342243
.