Every once in a while, we have a situation where basically all of our tag change scripts stop processing. I finally saw this error in the Console of the designer Diagnostics. It's almost as if the Basic Execution Engine has run out of threads.
The execution engine for tag events (defined on the tag) has three threads. Such events must run very quickly--single digit milliseconds, or less on large systems--or you will have congestion. That means such events should never have any sleep() or spin loop or database operation (other than S&F ops) or network operation--nothing that waits for external traffic.
Anything that takes longer than a few milliseconds needs to use a project-defined gateway tag change event. Each of those has its own independent thread, so can do longer operations without blocking other events.
Consider adding start/stop timestamp collection with java's System.nanotime() and logging warnings for any event that takes more then a couple millis.
{ There's a config option to increase the number of threads, but that's a band-aid. It should only be used on very large systems. }
Thank you for the advice. From an architecture perspective, we have a LOT of tag change scripts built-in to UDTs that we use to represent multiple instances of the same types of machines. Object-oriented thinking. For these machines, the instances of the UDTs are created and deleted using a configuration app and an ignition module that stores information in a database and adds a tag of the "UDT Instance." Is there a way to spin those tag change scripts on the UDT onto their own thread without having to create a gateway tag change script manually?
Sort of. I recommend establishing one or more persistent ConcurrentLinkedQueue or LinkedBlockingQueue instances via project libraries and having your tag events stuff tuples of information into them. This is an extremely fast operation.
Then, use one or more relatively fast gateway timer events to drain from those queues to perform the actual processing. Those can run in their own thread.