acceptor need threadpool？

[zhoufudun]

my thinking:

QuickFixJ is built on top of MINA, and MINA allows configuring the number of Processor threads. Assuming there are 10,000 connections, generally, configuring the Processor threads to 100-200 is sufficient. Let’s say we configure 100 Processor threads; on average, each Processor thread handles the read and write requests of 100 clients.

Currently, in QuickFixJ, a separate thread is allocated for each client at the business layer to execute business logic. Messages can be initiated by the client or sent by the server to the client. Even if the messages from the client are processed quickly and responses are sent promptly, these responses need to be executed by MINA’s Processor threads to be truly sent to the remote client.

Therefore, the performance bottleneck lies in MINA rather than QuickFixJ. QuickFixJ can fully utilize a thread pool at the business layer for execution，Additionally, a thread pool can mitigate the risk of creating too many threads.

Is it necessary to do this? If so, I’ll create a pull request。 look forward to hearing from you on this matter.

[philipwhiuk]

Assuming there are 10,000 connections

Is this a practical number? I'd be surprised if it's a good design to try to have so many connections on a single FIX application endpoint.

I have no real objection to a thread pool, I've just never seen enough connections on a single appliance to warrant this sort of performance optimisation.

[zhoufudun]

10,000 is just my assumption. I believe that as a middleware, it should consider robustness to prevent misuse by users。Thank you for your answer。