How does garbage collection for gateway or client scripts work? Does it use same heap as Java’s heap and JAVA’s garbage collector? For example if you are doing lot of string manipulation such as splitting , concatenation of strings in gateway/client scripts in a cyclic loop every few seconds, then it will obviously result in a lot of garbage memory as strings are immutable in Python as in JS. Will this be handled properly by the garbage collector? What precautions do we have to ensure there are no memory leaks from the scripts?
Jython objects are java objects and are managed by java’s garbage collector.
There are two major sources of memory leaks, triggered by project updates:
-
Persistent background threads that monitor sockets or serial ports or otherwise stay running for special reasons. They will keep running old code. You must use some mechanism (tag or client tag) to signal such threads that they’ve been replaced and need to shut themselves down.
-
Jython implementations of java Listeners of various types. These will retain their old code until deliberated replaced. Or the event source ceases to exist–the listeners are cleaned up at that point.
I used to recommend the dictionary from system.util.getGlobals() as a safe place to track other objects through restarts. I now recommend my free Life Cycle module as a replacement.
What if the the sockets that are waiting for inputs on a system.a separate tread on a util.invokeAsynchronous call ?
Too far fetched from my use case in mind. I want to specifically know the impact of strings routines like split and concatenate point of view..
That is precisely the kind of thread you need to replace. Usually by closing the socket. (If a python socket, you must close it to replace it.) Let the replacement thread open the socket fresh. Use of Thread.interrupt() can help implement this.
Ok. You asked. I hope you recall it when implementing a listener, as they are all over Ignition's infrastructure.
Yup. They create garbage that needs to be collected. Regardless whether done by java or jython. No special handling required.
Ok, got it. So sockets, threads, listeners and resources in general are the major things that could lead to memory leakage in scripts. Garbage resulting from string functions are automatically taken of by Java’s garbage collector.
I am experiencing a situation that whenever I put my development computer (Windows 10) in hibernate mode, and restart (wake it up) it the next day, the system generally reboots in most of the cases whenever I have run my ignition trial version, with my scripts running for sometime (say 30 mins to couple of hours) before the hibernation! I thought is its due to some memory leaks resulting from my gateway scripts! Of course a production server will never go to hibernation.
I had asked this question before also, under what circumstances can a windows machine (with Ignition and designer running on it) reboot after waking from a hibernate state ? If I don’t start Ignition , just do some normal browsing or MS office work, the system wakes up quickly without roboot after hibernate! Has anyone experienced this behavior ? Can I see some where on any Ignition dash boards or logs, that will give me an idea about the cause of system reboot ?
No idea. Probably should be a new topic. I don’t use Windows for Ignition development, so I have nothing to suggest. FWIW, I suspend and resume my laptop every day, and any of its VMs containing Ignition Gateways suspend and resume with it just fine. Kubuntu 18.04 hypervisor w/ a multitude of Ubuntu Server LTS VMs.
Thanks a lot. I guess there is some issue with my laptop HW. I have 4GB RAM but upgraded to I think 12GB, all patches are uptodate and defender firewall and antivirus are in place. Guess I should try development on ubuntu on a separate laptop. Thanks a ton.
I call util.invokeAsynchronous on rising edge of a tag change event triggered by a user, in a gateway script where I open a socket waiting for a client to connect. The communication goes on well after a client connects. On reset of this tag by user, or in the event of an error on socket (such as client disconnects) , I close the socket on manual close or on exception as the case may be , but the do nothing with the thread. To restart the communication again after that, the user resets and sets the tag, and the invokeAsynchronous is called again and cycle repeats. This works just fine, but will repeated set/reset of the tag cause any thread issues? It has never caused any problems while running in a single run (I might have set/reset the comm 40 to 50 times in a run) , but will it cause build up of any resource leakage, which manifests later? Do I have to close the thread created by invokeAsynchronous call in my scripts explicitly? How do I do that? Which function do I call?
You quoted the answer. Your async threads need to regularly check for interrupted status.
Also, I strongly recommend you properly implement a listening socket that accepts() runtime sockets. Then you have no need for a trigger tag.
how to do that in scripts? I don't want to to do it thru modules?
Use an asynchronous thread with a ServerSocket to listen for connections. Wait for client connections with .accept(). Pass the new socket returned from .accept() to a new asynchronous thread that implements your actual protocol traffic. Both the listening thread and the protocol work thread should check for a thread interrupt regularly.
In fact that's what I am doing, but the asynchronous thread is opened manually by a tag change event! I can put it in gateway start up script to automatically start it, but I wanted to avoid automatic creation.
I can still implement it in this on existing implementation.
What is the impact of running the scripts with tag change events such as the socket script or tag change event script , without Ignition running , i.e. trial mode not reset. The scripts seem to work fine, such as changing tags , fetching tag values thru scripts. Only the timer scripts don't work in server freeze mode. But does it have an adverse effect on memory leaks etc? I guess the Ignition server running state will only impact the history, the PLC data read/writes, etc but scripts will run normally. Just want to ensure, whether the off line running of scripts (with out the server in run mode) has any adverse impact.
Gateway event scripts are not supposed to run when trial mode is expired. Long-running threads are not disrupted by the end of trial mode, though. I’m not aware of any particular memory leak potential that would result.
Ok, but Asyncthreads waiting for an input from sockets , or scripts triggered by a tag change event cannot be termed as long running threads. They are just waiting. I can understand a thread taking long time to complete its execution will not stop on expiry of trial, it will stop only after completion of the running task.
What impact will not updating to latest java version (for Ignition 8) on the system have? I have upgraded to Sun’s latest version build 1.8.0_261-b12. I am still experiencing the reboot problem when ever I run Ignition and hibernate and wake up next time! I wonder if its some compatibility issue with JRE version!
A thread that is waiting on I/O is still “running”. If it waits on I/O a long time, it is “long-running”.
I don’t have your hibernation problems, and I’m not switching to Windows to find out if I’ll have them, too.
1 Like
Ok, thanks a million for all the help. I am not expecting you to switch to windows! It was very useful discussion.
1 Like
I think I found the problem of Windows rebooting after hibernate! I think its due to the designer and the launcher remaining ON while putting the system to sleep. It has nothing to do with scripts or memory/resource leakage in scripts. I used to leave designer running always. Now I exit the designer and launcher before putting system to sleep (hibernate), and next time when I wake the system up, system comes on without rebooting windows! I have to observe it for a few more days/weeks before I conclude, but its better to exit the designer while not is use and before hibernating. Perhaps designer is optimized for better user experience but may not worry much about memory usage and resource optimization in my opinion. I will observe it for few weeks and update on this post.