i wrote some functions in a shared Script which are called from an UDTs valueChanged event. Now every time i save some Changes i made in my Script and the Scripting restarts because of that the Memory usage is grwoing a bit.
After that the Memory performs normal but is generally on a higher level.
What could cause such a behaviour and is there a way to 1. Bring down memory to the usual level and 2. Avoid this in the future?
If you are using system.util.invokeAsynchronous to launch long-lived threads, and you don't kill them off when the project is saved, then you are leaking the entire Jython interpreter infrastructure every time. Also applies to misuse of event scripts that do not complete quickly (infinite loops, or very long tasks).
There's no Ignition fix if this is what you are doing.
There is an update coming in 8.1.23 that corrects for some orphaned objects that weren't getting cleaned up on project scripting restart. The growth here was very small though and manifested more when there were a lot of inherited projects. It is definitely worth taking a look at what @pturmel mentioned above...
Okay. Again, thank you for your answer.
After looking more deeper into some Scripting i found that the system.util.invokeAsynchronous is used.
It is used in the Project library in a shared syript of my "Global" Project from which a few other projects inherit. Now i would like to close the thread if i restart my Scripting but don't quite know how I would do this right now.
I know that system.util.invokeAsynchronous returns the executing thread also that the Gateway Event Update script runs every time i restart my Scripts. Now my idea would be that in the Gateway Event Update i test if my thread is still running and if so kill it off.
How is it possible to safe the executing thread? How do i make sure that the thread i want to kill off is actually the one i called my function on? So in general, how would i kill off the thread when i save my project ?
It isn’t safe to kill threads. Threads can and should be designed to be interruptible (checking for interrupt status and/or exceptions for graceful exit). If you didn’t do that, interrupt() may not work. If not, you will have to restart the gateway.