The controlExecutor in Channel now has its core thread count set to 0 so that the control thread will be disposed after no start/stop/deploy/etc tasks have been started in 60 seconds. Before, every ch…
The controlExecutor in Channel now has its core thread count set to 0 so that the control thread will be disposed after no start/stop/deploy/etc tasks have been started in 60 seconds. Before, every channel's control thread would be alive the entire time the channel is deployed, which is an obvious waste of resources.
The destinationConnectorExecutor and recoveryExecutor in Channel have been combined into channelExecutor as there was no need for RecoveryTask to use its own executor.
The queueExecutor in Channel has been removed and we now create the thread on our own. The queue thread is simple enough that there is no reason to use an executor service.
The executor used in VmDispatcher if response timeout is not 0 is now created on deploy instead of on start. This way it can be shutdown on undeploy. It is also using a cached thread pool now to allow threads to be disposed when they are not currently in use. Without this, a thread could be alive even if the channel was stopped and would not be disposed until the channel was undeployed.
VmRouter now uses a static cached thread pool instead of creating a new single thread executor each time a message is routed. This could have caused excessive garbage collecting when many messages are being routed in a short timespan.
WebServiceConnectorService now uses a static cached thread pool instead of creating a new single thread executor each time importWsdlInterface is called. This allows threads to be reused and cuts the overhead of creating a new executor each time.
DataPruner is now creating threads directly instead of creating a new single thread executor each time a prune job is started. It was not making use of any ExecutorService specific features. This also eliminates any of the overhead shortens the amount of time that the thread remains alive.
AlertWorker's actionExecutor now has its core thread count set to 0 so that the action thread will be disposed after no actions have been taken for 60 seconds. Otherwise each AlertWorker could be leaving an additional thread alive even if it had not seen any action for a long time.
Fixed bug in EventListener where the workerThread would not be disposed when the listener is shutdown.
The status updater executor is shutdown when logging out.
Issue:
MIRTH-2659