As far as i know,the smtp queue flusing is every minites,sometimes it is dead lock never works,check SmtpQueue.log it never any new log,after server restart,it works again.

Any fast method to force the smtp queue flusing?

What value are you using for Retry Interval under Server Configuration/Advanced tab? Even though the queue is flushed every minute, emails are not sent again until the Retry Interval occurs.

When you search Flusing SMTP queue at SmtpQueue.log,you can see it run task every minutes.When it is dead,you can not see any more Flusing SMTP queue at the log,and many emails stay at outbound queue.
After several restart,it works again.It seems the queue run task is dead.

I found some unusual at queue iteration.

2023-01-13 15:18:22,137 - Outbound queue iteration completed in 5301 ms.
2023-01-13 15:19:23,540 - Outbound queue iteration completed in 1403 ms.
2023-01-13 15:20:50,813 - Outbound queue iteration completed in 27273 ms.
2023-01-13 15:21:52,219 - Outbound queue iteration completed in 1405 ms.
2023-01-13 15:22:52,239 - Outbound queue iteration completed in 20 ms.
2023-01-13 15:23:52,239 - Outbound queue iteration completed in 0 ms.
2023-01-13 15:24:52,239 - Outbound queue iteration completed in 0 ms.
2023-01-13 15:25:52,240 - Outbound queue iteration completed in 0 ms.
2023-01-13 15:27:01,951 - Outbound queue iteration completed in 9711 ms.
2023-01-13 16:03:04,860 - Outbound queue iteration completed in 2102909 ms.
2023-01-13 16:20:42,905 - Outbound queue iteration completed in 47068 ms.
2023-01-13 16:21:42,906 - Outbound queue iteration completed in 1 ms.
2023-01-13 16:22:42,907 - Outbound queue iteration completed in 1 ms.
2023-01-13 16:23:42,908 - Outbound queue iteration completed in 0 ms.
2023-01-13 16:24:42,909 - Outbound queue iteration completed in 0 ms.
2023-01-13 16:25:42,910 - Outbound queue iteration completed in 0 ms.
2023-01-13 16:28:52,131 - Outbound queue iteration completed in 129221 ms.
2023-01-13 16:30:06,506 - Outbound queue iteration completed in 14374 ms.
2023-01-13 16:31:22,171 - Outbound queue iteration completed in 15665 ms.
2023-01-13 16:50:15,067 - Outbound queue iteration completed in 276064 ms.
2023-01-13 16:52:34,419 - Outbound queue iteration completed in 79351 ms.
2023-01-13 16:53:34,420 - Outbound queue iteration completed in 0 ms.
2023-01-13 16:54:34,420 - Outbound queue iteration completed in 0 ms.
2023-01-13 16:55:59,994 - Outbound queue iteration completed in 25573 ms.
2023-01-13 16:56:59,994 - Outbound queue iteration completed in 0 ms.
2023-01-13 17:11:18,137 - Outbound queue iteration completed in 798142 ms.
2023-01-13 17:12:28,050 - Outbound queue iteration completed in 9913 ms.
2023-01-13 17:13:28,050 - Outbound queue iteration completed in 0 ms.
2023-01-13 17:14:35,888 - Outbound queue iteration completed in 7837 ms.
2023-01-13 17:15:35,889 - Outbound queue iteration completed in 0 ms.
2023-01-13 17:16:37,724 - Outbound queue iteration completed in 1835 ms.
2023-01-13 17:17:37,724 - Outbound queue iteration completed in 0 ms.
2023-01-13 17:43:35,794 - Outbound queue iteration completed in 1498070 ms.
2023-01-13 17:44:43,136 - Outbound queue iteration completed in 7342 ms.
2023-01-13 17:45:43,150 - Outbound queue iteration completed in 13 ms.
2023-01-13 17:46:43,168 - Outbound queue iteration completed in 18 ms.
2023-01-13 17:47:43,210 - Outbound queue iteration completed in 42 ms.
2023-01-13 18:19:01,542 - Outbound queue iteration completed in 1818331 ms.
2023-01-13 18:25:06,955 - Outbound queue iteration completed in 305405 ms.

I found the issue,for the retry queue,the email is sent one by one,if the one is still sending,it will not open another thread and send other one. 

This will be problem if one of big email sending to downstream server,and many small emails keep stay in the queue.

Best suggestion:

For the retry queue,if one of the email is not sent finished within 1 minutes,open another new thread to deliver other emails,this can avoid email queue issue.

Any solutions for that? 

Your assessment is correct: once emails go into the queue, a single thread processes all of them. Changing this logic is not trivial. I have submitted a request to our to-do list and our dev team will evaluate and assign a priority to the task.

Note that most emails will never go into the queue if they are delivered on the first attempt.

Xeams can run for muti-domains,if one of the email has issue,it will have many others waiting behind it.

I think 3 threads for queue is best choice.

For example,xeams is running as front,if the downstream server has some problems for a long time,there are hundreds of emails stay at the retry queue,once the downstream server back online,if send one by one,it is too slow and takes too long time.

Best suggestion:

There is changeable options at the control pannel,by default,the retry thread is set to 1 or 2,for urgent case,administrator can change to be 5-10 and restart xeams to make it works.

Any update on this function?

Any update on this function?

For example,the xeams is running at the could server,backend service offline due to outage for several hours or a day. In that case,there maybe too many emails stay at the queue,after the backend server back online,if send one by one,it is really too slow and takes too long time.

If backend server is exchange,it is easily to have below issue:

451 4.7.0 Temporary server error. Please try again later. PRX4
451 4.7.0 Temporary server error. Please try again later. PRX5

If you do not check the log,maybe not know the exchange issue,as telnet exchange 25 port is normal status.This case also cause too many queue.

So extend the retry queue threads is urgently needed function.

Tommy,

We already have this feature in our to-do list. However, it is a major change and therefore, will take some time.