# Tag Change Scripts stop working **URL:** \ **Category:** Ignition\ **Created:** [January 26, 2024, 4:25pm UTC](https://forum.inductiveautomation.com/t/tag-change-scripts-stop-working/84819 "2024-01-26T16:25:45Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![jtdfan](https://avatars.discourse-cdn.com/v4/letter/j/a88e4f/32.png) [@jtdfan](https://forum.inductiveautomation.com/u/jtdfan)\ **Post date:** [January 26, 2024, 4:25pm UTC](https://forum.inductiveautomation.com/t/tag-change-scripts-stop-working/84819/1 "2024-01-26T16:25:45Z")
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. WARN Common.BasicExecutionEngine - Execution rejected... running in calling thread [AWT-EventQueue-0] immediately. [com.inductiveautomation.ignition.designer.tags.tree.TagTreeModelImpl$BatchOp$$Lambda$949/0x0000016597b1a668@d72dc75] Any ideas where I can look to see what scripts are causing us to get into this scenario? ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [January 26, 2024, 4:35pm UTC](https://forum.inductiveautomation.com/t/tag-change-scripts-stop-working/84819/2 "2024-01-26T16:35:07Z")
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. } ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [January 26, 2024, 4:36pm UTC](https://forum.inductiveautomation.com/t/tag-change-scripts-stop-working/84819/3 "2024-01-26T16:36:03Z")
Next time they appear stop working take a thread dump from the Gateway. I don't think the error snippet you posted is related. ---
**Author:** ![jtdfan](https://avatars.discourse-cdn.com/v4/letter/j/a88e4f/32.png) [@jtdfan](https://forum.inductiveautomation.com/u/jtdfan)\ **Post date:** [January 29, 2024, 1:42pm UTC](https://forum.inductiveautomation.com/t/tag-change-scripts-stop-working/84819/4 "2024-01-29T13:42:49Z")
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? ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [January 29, 2024, 1:48pm UTC](https://forum.inductiveautomation.com/t/tag-change-scripts-stop-working/84819/5 "2024-01-29T13:48:04Z")
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. ---
**Author:** ![rickard.eriksson](https://avatars.discourse-cdn.com/v4/letter/r/7cd45c/32.png) [@rickard.eriksson](https://forum.inductiveautomation.com/u/rickard.eriksson)\ **Post date:** [March 19, 2026, 11:13pm UTC](https://forum.inductiveautomation.com/t/tag-change-scripts-stop-working/84819/6 "2026-03-19T23:13:11Z")
Could one use **invokeAsynchronous** on tag change events to make it safer? ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [March 20, 2026, 12:15am UTC](https://forum.inductiveautomation.com/t/tag-change-scripts-stop-working/84819/7 "2026-03-20T00:15:12Z")
Making new threads is a heavy operation and busy tags can spawn thousands of threads before they make a difference. See this topic for better solutions: > [@Java concurrent queue for tag change scripts](https://forum.inductiveautomation.com/t/java-concurrent-queue-for-tag-change-scripts/82044): > > Continuing the discussion from [[SOLVED] Are tag Value Changed scripts running asynchronously?](https://forum.inductiveautomation.com/t/solved-are-tag-value-changed-scripts-running-asynchronously/68704/5): We've got code in our standard library that I need to log a value change on a tag and then associate various data points with that value change. The value is located in a UDT, and because this is part of our "standard" library we use for our customers, the number of tags is variable and quite possibly numerous so having a gateway tag event script isn't feasible for this solution. I was reading up on … (See all the cross-referenced topics, too.) Mind you, these are not **simpler** solutions. Sorry.