kasemir / org.csstudio.display.builder

Update of org.csstudio.opibuilder.*
Eclipse Public License 1.0
2 stars 10 forks source link

Display Builder keeps searching for not found PVs after OPI is closed #529

Closed claudio-rosati closed 5 years ago

claudio-rosati commented 5 years ago

If an OPI contains a PV that cannot be found, CS-Studio keeps issuing CA search requests even after the OPI is closed.

CSSTUDIO-1019.bob.zip

This is what reported by my colleague the raised the issue:

The attached OPI has a Text Update using a PV name that is not defined in any IOC. There is nothing relevant in the logs.

Running the OPI and monitoring the network traffic with Wireshark reveals that Display Builder is sending CA search requests for the PV (as it should). However, after closing the OPI Display Builder keeps sending these CA search requests (there is nothing in the log about it). My expectation is that Display Builder stops all CA operations belonging exclusively to a closed OPI (of course if a PV is referenced by another OPI it should not be disconnected).

kasemir commented 5 years ago

Can you try with Phoebus, opening Applications, Debug, PV List, and prefreshing that as the display is opened and closed? I'd like to understand if the problem is related to actively holding on to the PV, or if we think we released the PV, yet some lower level is still searching. With the RCP code, we have no PV list UI. You could add this to the end of PVPool.releasePV:

System.out.println("PV Pool:");
    for (ReferencedEntry<PV> ref : getPVReferences())
         System.out.println(ref);
claudio-rosati commented 5 years ago

Sorry I've not understood: the code has to be added to the Eclipse version or Phoebus one?

kasemir commented 5 years ago

Eclipse/RCP. Phoebus has a UI panel (Applications, Debug, PV List) to list PV references. In Eclipse/RCP there's no UI to see the PVPool, so adding that printout shows the remaining PVs whenever one is closed.

claudio-rosati commented 5 years ago

Done. Here the code I've added:

System.out.println("PV Pool after release:");

if ( getPVReferences().isEmpty() ) {
    System.out.println("  <empty>");
} else {
    for ( ReferencedEntry<PV> ref : getPVReferences() ) {
        System.out.println("  " + ref);
    }
}

Running the attached CSSTUDIO-1019.bob file and closing it is outputting:

PV Pool after release:
  <empty>
kasemir commented 5 years ago

Do you still see PV name search requests on the network when the PVs have all been released? Then this is a JCA/CAJ library error.

claudio-rosati commented 5 years ago

OK the problem is a bit more complex.

macOS

When CS-Studio is run on macOS, the following is written in console:

PV Pool after release:
  <empty>

And no CA search requests are sent using the following version of the OPI:

CSSTUDIO-1019.zip

Linux

On Linux things are different. When the OPI is closed nothing is written in the console, like if the PVPool.releasePV() was not called at all. Correspondingly, CA search requests are continuously sent.

claudio-rosati commented 5 years ago

More on LInux:

Opening another OPI with good PV names worked and when I closed it the following appeared in console (this is the very last message of its kind):

PV Pool after release:
  JCA_PV 'there_is_no_pv_with_this_name' = null (2 references)

So there are 2 references to the PV used in the first OPI. A note: the first OPI closes itself after few seconds.

kasemir commented 5 years ago

Ah, I see. When you change

ScriptUtil.closeDisplay(widget);

into

import time
time.sleep(10)
ScriptUtil.closeDisplay(widget)

it's fine. The issue is not the semicolon. I assume when you close the display right away, the runtime is still in the process of starting PVs. So the PV gets started while the display already closes down, a race condition. Will look at it.

claudio-rosati commented 5 years ago

Thank you. In the meanwhile I'm adding a preference to org.csstudio.vtype.pv to enable/disable the printout that I think could be very useful (until the move to Phoebus of course):

# If true, the last statement of PVPool.releasePV()
# will be printing to the standard output the
# content of the PVPool itself.
print_pvpool_content_on_release=false
kasemir commented 5 years ago

I think I got it. The problem was reproducible when adding a Thread.sleep(2000) to PVPool.getPV, asserting that the runtime startup was slow, and the shutdown thus happened while the runtime was still starting up. So the UI and model got disposed, and when the runtime finally stopped, it didn't find any widgets to stop, so PVs remained open.

Now the shutdown always is in order: Await startup, then stop runtime, stop UI, finally dispose model.

claudio-rosati commented 5 years ago

Thank you Kay