Running Task Log - optimize memory usage

Current Situation

• Currently, the Running Task Log Cache holds strong references to the threads started for log reading.
• This cache is never cleaned up, which leads to unbounded growth over time.
• Although terminated threads release most of their internal resources (e.g. stack memory), the thread objects themselves remain strongly referenced and therefore are not eligible for garbage collection. As a result, memory usage grows slowly but steadily.
• In practice, even with 1000 cached entries, the memory footprint stays low (~100–200 KB), since terminated threads only retain minimal metadata.
• However, this is still unnecessary memory retention.

Desired Behaviour

• Ensure no memory leaks occur over time if the Running Task Log API is used.

Implementation Note

• Instead of storing Thread objects directly, use WeakReference<Thread> to allow GC to reclaim terminated threads when no longer in use.
• Run a periodic cleanup task that removes entries whose threads are either garbage collected or no longer alive.

Test Instructions

• Configure JOC to use DEBUG level
  • Edit resources/log4j2.xml and set both RootLogLevel and JocLogLevel to DEBUG.
• Configure and run a workflow
  • The workflow should run for approximately 1 minute.
• Monitor Order/Task logs
  • Open the Order/Task log while the order is running, then close the log window.
• Check the debug log
  • After about 2 minutes, check joc-debug.log for lines like:

    [RunningTaskLogs][cleanup][after] registeredHistoryIds=...

  • If any values are not equal to 0, wait another 2 minutes and recheck.
  • Expected behavior: within a maximum of 10 minutes, all values should equal 0.
• Retest with multiple workflows
  • Open running logs in multiple browser instances simultaneously.
  • Expected behavior: same as described above.