Repository navigation
SETTING_MAX_SCHEDULED_WRITE_REQUESTS does not work for TLS session #406
Description
Describe the bug
When a session is a TLS session, for example, a Bloomberg TLS session, SETTING_MAX_SCHEDULED_WRITE_REQUESTS does not work as expected.
If we set SETTING_MAX_SCHEDULED_WRITE_REQUESTS to be 10 for a TLS session, when we send (very very slowly) total messages more than 10, the session will be disconnected. It seems that for a TLS session, this number is the accumulated FIX messages we could send out after session logon (35=A).
To Reproduce
- Setup a TLS FIX session
- set SETTING_MAX_SCHEDULED_WRITE_REQUESTS to be 10
- Connect and Logon this TLS session (35=A)
- Send 11 messages very very slowly
- This TLS session is disconnected after 11 messages sent with error message - Disconnecting: Slow consumer
Expected behavior
When set SETTING_MAX_SCHEDULED_WRITE_REQUESTS to be 10 for a TLS session, only if total unsent FIX messages in Write Request Queue is greater than 10, then disconnect the TLS session.
system information:
- OS: Linux
- Java version JDK8
- QFJ Version 2.2.0
Additional context
SETTING_MAX_SCHEDULED_WRITE_REQUESTS is working fine for non-TLS session, when a FIX message is sent out, the Write Request Queue size will decrease correctly. For a TLS session, it seems that Write Request Queue size does not decrease at all, it just keep increasing forever.
Activity
chrjohn commentedon Jul 13, 2021
chrjohn commentedon Jul 26, 2021
https://issues.apache.org/jira/browse/DIRMINA-1146
the-thing commentedon Sep 8, 2026
I have a feeling that it will take quite a while before my mina PR is merged and then released so I might prepare local quickfixj patch soon.
[-]SETTING_MAX_SCHEDULED_WRITE_REQUESTS does not work for TLS session[/-][+]`SETTING_MAX_SCHEDULED_WRITE_REQUESTS` does not work for TLS session[/+]the-thing commentedon Oct 17, 2026
This was patched and released in MINA 2.2.10.
https://issues.apache.org/jira/browse/DIRMINA-1146
apache/mina#61
I should be following this up with a reasonable test soon. There might be more requests leaks, but we shall see.
chrjohn commentedon Oct 18, 2026
@the-thing thank you for fixing that issue. 👍
I've created #1347 but it seems there is a problem, even a deadlock in one of the tests if I observed correctly. Was just doing it from my mobile so I couldn't check properly. Will check again on Monday.
the-thing commentedon Oct 18, 2026
I have seen and it is not looking good initially. Well, we will have to look.
chrjohn commentedon Oct 18, 2026
https://productionresultssa12.blob.core.windows.net/actions-results/959db8af-165d-8ddb-b81e-d4494daddf49/workflow-job-run-1e15a314-ee87-53d1-947a-a78c8cdd59d0/logs/job/job-logs.txt?rsct=text%2Fplain&se=2026-10-18T10%3A44%3A25Z&sig=U6ZjXf5GUz9Z3C0fpv1d7rVgtjR9s1BNFSzUHBWNcjY%3D&ske=2026-10-18T13%3A06%3A16Z&skoid=ca7593d4-ee42-46cd-af88-8b886a2f84eb&sks=b&skt=2026-10-18T09%3A06%3A16Z&sktid=398a6654-997b-47e9-b12b-9515b896b4de&skv=2025-11-05&sp=r&spr=https&sr=b&st=2026-10-18T10%3A34%3A20Z&sv=2025-11-05
Here is the job log, looks like it is even deadlocking for non TLS? But small screen here ;)
chrjohn commentedon Oct 18, 2026
Copilot said:
This confirms the deadlock:
ssl-exec-0 holds SSLHandlerG1.mWriteQueue in forward_writes().Its downstream filterWrite() waits for Socks5LogicHandler.NioProcessor-633 holds Socks5LogicHandler and waits for mWriteQueue.
The lock added in 2.2.10 around forward_writes() must not span next.filterWrite(). A single-drainer AtomicBoolean should serialize queue draining while dispatching callbacks without holding a monitor.
the-thing commentedon Oct 18, 2026
Lets move the discussion to here #1348
the-thing commentedon Oct 18, 2026
This doesn't help too much - it is too vague, but failing minimal working example in MINA would help...