Monitor::stop() does not stop network events

[ralphlange]

@mrkraimer opened this issue on Jul 5, 2017:

When a Java client calls monitor.stop() monitor events are still passed from a C++ server to the client.

This problem was discovered while developing the latest version of the EPICS_NTNDA_Viewer.java.
This is an ImageJ plugin for areaDetector.
The client is Java.
The server is a V3 IOC that also has V4 support. In particular the NTNDArray areaDetector plugin.

When the client calls monitor.stop the images are no longer updating but events are still flowing from the NTNDArray to the server.

The problem has not been investigated so the cause has not been found.

It is not known if the same problem exists for a C++ client.
It is not known if the same problem exists for a Java IOC.

@MarkRivers commented on Jul 5, 2017:

If the PvaClientMonitor object is destroyed then the events are no longer passed from the C++ server to the client. This is how we have worked around the problem in the ImageJ plugin. It means that each time we reconnect we have to recreate the PcaClientMonitor.

The ImageJ plugin can be found here.

[mdavidsaver]

It is not known if the same problem exists for a C++ client.

ChannelMonitorImpl::stop() does send a network message. (although MonitorStrategyQueue::stop() does not, so the MonitorStrategyQueue vs ChannelMonitorImpl distinction could cause confusion)

https://github.com/epics-base/pvAccessCPP/blob/master/src/remoteClient/clientContextImpl.cpp#L2404-L2435

That said, my recommendation would be to use an explicit queue size and monitor flow control. eg record[pipeline=true,queueSize=2]. Then, slowing down, or stopping, servicing of the monitor queue will translate into reduced network bandwidth usage.