Openfire uses a thread pool when setting up new server-to-server connections. The thread pool has a ‘core’ thread count (default: 0), a ‘max’ thread count (default: 20) and a limited-sized queue (default capacity: 2000).

I’m pretty sure that the idea behind this is that Openfire has up to 20 concurrent processes going on. However, that’s not how thread pools work. When there’s at least one thread and the amount of threads is equal to (or higher than) the core thread pool amount, then new threads will only spin up if the queue is at capacity.

For S2S, this means that we’d have to have 2000 S2S requests waiting. This is unlikely to happen, and if it does, then most requests will have timed out already.

Openfire should instead allow for up to a configurable maximum of concurrent requests without queuing. One way of doing this is by increasing the core thread pool (which is configurable through the xmpp.server.outgoing.min.threads property).