Support for JDK 21 (or JDK25) and Virtual Threads

[matadorr]

Hello QuickFIX/J maintainers,

I would like to propose a feature request to enhance QuickFIX/J support for JDK 21 and the use of virtual threads for high-concurrency scenarios.

Currently, QuickFIX/J primarily uses blocking IO (BIO) with a traditional thread-per-session model:

Acceptor / Initiator IO layer: Uses blocking sockets (ServerSocket / Socket) and creates one OS thread per session for reading/writing.

Business logic layer: Runs in the same thread or a delegated thread pool, typically synchronous.

This model works well for small to medium numbers of sessions but can face challenges when handling tens of thousands of B2B connections, due to the overhead of OS threads and context switching.

With JDK 21 virtual threads, it would be possible to:

Keep the IO layer blocking (BIO), but assign virtual threads per session instead of OS threads.

Maintain the synchronous, blocking-style business logic code without forcing users to adopt complex asynchronous programming.

Dramatically reduce memory and context-switching overhead, enabling high-concurrency B2B deployments.

Feature request summary:

Ensure QuickFIX/J is fully compatible with JDK 21.

Provide an option to use virtual threads for session-level read/write threads while keeping the underlying IO model blocking.

Maintain backward compatibility with the current thread-per-session model.

This change would allow QuickFIX/J to scale to large numbers of sessions without requiring a full rewrite to asynchronous IO.

Thank you for considering this enhancement. I would be happy to help with testing or prototyping if needed.

Best regards,
leegoo

[chrjohn]

Hi @matadorr ,

did you try passing Executors.newVirtualThreadPerTaskExecutor() in your https://github.com/quickfix-j/quickfixj/blob/master/quickfixj-core/src/main/java/quickfix/ExecutorFactory.java ?

Disclaimer: I have not tried it, but it should work.

[the-thing]

@chrjohn

I was thinking about this and I think this will require more work.

• there are still some places where new Thread() is being called

quickfix.mina.ThreadPerSessionEventHandlingStrategy.ThreadAdapter.DedicatedThreadExecutor used by quickfix.mina.ThreadPerSessionEventHandlingStrategy.MessageDispatchingThread

Possibly more. We would have to expose a way to provide thread factories.

• also we ideally want to get rid of (replace with reentrant locks) all synchronized methods and blocks to avoid thread pinning and related issues.

https://issues.apache.org/jira/browse/HTTPCORE-746

[chrjohn]

Should I throw the AI at it?

[the-thing]

Why not, but be careful what you fish for.

[chrjohn]

General question: is there a way to have this without requiring JDK21 for the whole project? Is there another way than creating a new project with just the connectors with virtual thread support that could be plugged in?

[the-thing]

Thread factories and reentrant locks (or factories of locks if required).

This is not something that should require dependency on any specific JVM or something to be enabled / disabled by properties or QuickFIX/J API.

Unless the author wants to implement non blocking API that is significantly different to the one currently used.

[chrjohn]

I understood the part about the reentrant locks.
But apart from that: I need to compile the code, don't I? How am I supposed to compile QFJ with JDK8 when it uses Executors.newVirtualThreadPerTaskExecutor() in the code?
Or are you suggesting we probably do not need to do other changes than what you suggested in #1042 (comment) and then passing in Executors.newVirtualThreadPerTaskExecutor() from user code will do the trick?

[the-thing]

Exactly. Factories / Threads and Executors can (should?) be passed from client code.

Again. This is what I think author had in mind. Making changes to threading model, API style is bigger and more difficult.