PVReaderDirector never stopped on OPIView disposed (and its IPV)

[DjThunder]

Scenario:

• I open a series of OPIView (and their PV) in runtime mode (contains 3 Text Update and 3 XYGraph using 3 PV)
• I close the view and change the perspective
• I go back to the perspective with OPIView (so it reload them, faster than first time because static backed thread pool are already created)
• I repeat this action for a while and I end on a clean environment without any view - call gc - sound to be a memory leak with XYGraphModel, in PVMgr Worker 4 -> ScheduledThreadPoolExecutor -> ScheduleFuture (according to MemoryAnalyzerTool)
• Now I can see the increasing memory, as if IPV, or Director, or Recipe where never closed.

Any idea on how to close an OPIView when disposing a perspective that contains such displays ?
(The IPV sounds to be stopped in case of AbstractBaseEditPart - edit mode - partDeactivated event, but not the case for runtime mode).

[kasemir]

Is that with code from the master branch or the boy_runtime_view branch?
It could be related to the behavior of RCP Views and Perspectives in general, combined with the internal ID of the OPIView. When you close an RCP view, it is initially just hidden, not really closed. Only when it's closed in all perspectives that contain that view, the actual hidden view is really disposed.

When you do this N times for the same *.opi input file, do you get N copies in memory or just one, i.e. are N copies of the view opened, or is one and the same opened, hidden, displayed again, finally hidden but never really closed?

[DjThunder]

Ah yes sorry about the version: 3.2.0 (get in december 2013)

The same are opened (no copy or duplication in view, but it could be another instance...).
The only action I can perform is to hide all view before closing the perspective, and then I hope resources are released when perspective changed, as there are not used anymore (also, I can't call dispose myself on the OPIView, else it is the mess on RCP).

The only thing I can see is the memory activity: PVManagerDirector & pvmanager.Notification, increasing memory usage all the time, even if I can't see any OPI as I changed the perspective.

When looking at code, the only way to close IPV, is when AbstractBaseEditPart is deactivated (partDeactivated event).
I tried to use the DisplayModel from OPIView accessor, and perform a deactivate() manually, but it doesn't matter.
And of course, if I use PVManager accessors to close Scheduler, I'm not able to reopen OPIView anymore (illegal pool access, because closed).

I also tried to get reciepe from my DataSource when one is created, and then manually call disconnect for each of these reciepe, but I have some exceptions (PV not found), and the OPIView is then broken (disconnected purple) for ever.

Edit: Using eclipse debug, the code in AbstractBaseEditPart#deactivate (which close all script and pv) is effectively called when I change perspective. So I really don't understand what could remain between each load.

PVManagerPV close correctly the PV (closed flag to true), but PVManagerDirector is still seeing a false flag in isActive(), as if it was not the right reference.

Last breaking new: PVManagerPV scanner is stopped for the 3 PV, but there are other instances of theses PV (hashcode are not the same, compared to the one which get closed), and so Director is still alive because of them. So the final question is any idea on how are created PV when parsing the XML of an OPI ? There should be 3 PV instance (1 for each channel), but I can find more.

[DjThunder]

Finally: The PV instance closed by PVManagerPV is not the same that is checked by PVManagerDirector.
For an OPIView with only one channel (one PV), there is two instances of this same PV. One is closed (by PVManagerPV), the other is not (used by PVManagerDirector).
So this is this instance that is remaining between load & reload of OPIView (and a new one each time).

[kasemir]

I think at least way back the reason for two PVManager channels for each PV was because of some need for a separate reader and writer when using the PVManager.

On Nov 28, 2014, at 03:58, Pierre-Alexandre <notifications@github.com
For an OPIView with only one channel (one PV), there is two instances of this same PV. One is closed (by PVManagerPV), the other is not (used by PVManagerDirector).
So this is this instance that is remaining between load & reload of OPIView (and a new one each time)

[DjThunder]

I found the cause: it was the opi refresh.
Sounds to be a synchronization issue, as I refresh synoptics once they are loaded (i read displayModelFilled field in OPIRuntimeDelegate). When I perform the refresh, a second PV is created for each original PV (the duplicated one). If not refreshing, no problem with such PV.

In fact I'm performing refresh because sometimes my synoptics (or just some of their elements) are stuck on "Disconnected", even value are correctly sent.

Any idea on how to be correctly synchronized on the BOY process and avoid this kind of troubles ?

• How to refresh synoptics only when all PV are correctly created (to avoid duplication)
• Or how to avoid the "Disconnected" purple status on some of synoptics element when opening it

[kasemir]

When you write "I refresh synoptics once they are loaded (i read displayModelFilled field in OPIRuntimeDelegate)", you're not talking about a user manually refreshing the display, but your code which somehow loaded an OPIView is automatically refreshing the display?

Can you duplicate the PV duplication when you manually open an OPIView, using the sources from the 'master' branch, then manually cause a refresh?

As for threading, BOY is basically a single-threaded tool, doing all its work on the user interface thread. PV updates arrive on their own threads, but when they trigger the execution of scripts (rules) or change widget properties which then cause a GUI update, that work is moved to the UI thread via Display.asyncExec. So if you 'refresh' programmatically, that might need to happen on the UI thread as well.
Some work like loading *.opi files from http:// sources is on worker threads, and we had to fix a few problems in there. This would be a good area for a fundamental *.opibuilder.* rework: Do as much as possible in background threads, make all the code thread safe via proper locking (or better by using lock-free mechanisms), and only do the essential UI updates in the UI thread.
But this is a substantial task which currently lacks a long-term maintainer of the *.opibuilder.*. Having people go in now and change little bits here and there is likely to only worsen the situation.

[DjThunder]

I currently cannot check with master code, but I will give a try when possible.

About the problem, I solved it by not refreshing the opi once loaded, but performed a channel connection and send default value at the same time (processConnection & processMessage). Sounds to be fine for the moment.

Thanks for the explanation.

[berryma4]

@shroffk testing