The Boomi runtimes stores log messages in a in-memory queue before flushing the queue to persistent storage (i,e. log files). By default, if the queue is full, the publisher thread waits indefinitely for space to free up in the queue. On the other side of the queue is a consumer thread which continuously takes from this queue and writes the logs to the disk.
If the publisher thread is filling up the queue faster than the consumer thread is able to drain the queue we can get into a deadlock condition in certain configurations when the consumer thread is also forced to log a entry, for example when the java.security.debug property is enabled. When the java.security.debug property is enabled, there are a lot of log records which are created and pushed to the queue. Even the consumer thread is forced to add a log entry with this property enabled. When queue is filled, even the consumer thread waits for space in the queue to free up so that it can add its log. Because the consumer is not pulling from the queue the runtimes is now in a deadlock condition.
Unfortunately, the only way to determine if your runtime is hung (i.e. deadlocked ) on the the log queue is to get a thread dump of the JVM and verify that the JVM threads are stuck on logging.
You can add the following runtime properties to streamline the logging process during executions:
These properties can be modified by adding them as Custom Container properties as described in the Help Guide: Properties panel, Custom tab
If you encounter a deadlock due to this issue you can try to either reduce the log level on the runtime or modify these parameter values. You may have to experiment until the deadlock is eliminated.
com.boomi.container.logging.queueSize - 1000com.boomi.container.logging.timeOut - 60000