'threadpool queue is full' seen in MID Server agent log<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } With debug enabled, you may see these log lines in the MID Server's agent log: DEBUG (ECCQueueMonitor.5) [ECCQueueMonitor:281] EXPEDITED threadpool queue is full! Skipping this message (will try again later).DEBUG (ECCQueueMonitor.5) [ECCQueueMonitor:308] Skipped message: IPaaSActionProbe <mid server name> MIDSERVER 8dbb64f81dcbf650d76b082deb432db9 08c2638d3bc37a50e7755c1c95e45ae8DEBUG (ECCQueueMonitor.5) [ECCQueueMonitor:241] Number of messages added to threadpool queue in current polling cycle: 0DEBUG (ECCQueueMonitor.5) [ECCQueueMonitor:257] All thread pools are busy. Back off to the standard polling time.DEBUG (ECCQueueMonitor.5) [ECCQueueMonitor:477] Monitor query: state=ready^queue=output^agent=mid.server.<mid server name> MIDSERVER^sys_created_on>=2026-02-11 04:38:32^ORDERBYpriority^ORDERBYsys_created_onDEBUG (ECCQueueMonitor.5) [ECCQueueMonitor:298] Number of messages read : 250 This example happens to be for the Expedited thread pool, and a IPaaSActionProbe Integration Hub probe, but could be any, This means the MID Server is already running things in all its worker threads, and is queuing a lot of jobs in its internal memory, so is not going to take any more jobs from the ecc_queue until it has run some of the ones it already took. In this situation, for Expedited thread pool, you would expect to see 420 ecc_queue outputs in Processing state, with all newer records in Ready state. 20 running, plus 400 queued in memory.The number of ecc_queue records the MID Server will 'take' for each thread pool is listed in KB0743566 MID Server Max Threads - Worker Groups - Priority and Queues The ECC Queue is a queue, and MID Servers have a set number of Worker threads available (which is configurable), so this is working as expected. However there could still be an unexpected cause for the queue in the first place, with reasons such as: There are not enough MID Servers and Threads available to deal with the load you are giving them. That's an implementation question, dependent on the resources of your host servers, number and time it takes jobs to run, how quickly they must run once added to the queue, and how big the batches of jobs are likely to be, which can only really be worked out by real world testing, and then some calculations.There might be long running or stuck threads, limiting the available threads for other jobs. XMLStats inputs give a snapshot of what's in each thread every 10 minutes. The thread dump in wrapper.log, when you grab logs, will show the call stack of each thread, including any locks, or waiting for connections.Timeouts for failed connections causing threads to run longer than usual.And many more potential causes.