发送报价请求拒绝（35=AG）后fromApp方法无法接收消息

问题场景 #

• 基于QuickFix 4.4版本的应用，接收报价请求（MsgType=35-R）并执行校验
• 校验不通过时，发送报价请求拒绝（MsgType=35-AG）
• 异常表现：发送AG后，后续的35-R消息无法被fromApp方法接收处理，应用看似阻塞，但fromAdmin、toAdmin这类管理消息可正常处理
• 恢复特征：经过1-10分钟不等的时长后，应用自动恢复正常处理35-R消息
• 关键细节：未被fromApp处理的35-R消息仍能正常写入数据库表JdbcLogIncomingTable

排查建议 #

• 检查fromApp或AG消息发送逻辑的线程阻塞：QuickFix默认使用单线程处理应用层消息，如果发送AG时存在同步IO阻塞（如数据库操作超时、网络调用挂起），会卡住整个应用消息处理线程——而管理消息走独立线程，因此不受影响。重点排查发送AG的代码中是否有未处理的IO等待、锁竞争。
• 验证会话状态与消息序列：查看QuickFix会话日志，确认发送AG后会话的序列号是否正常递增，是否存在消息重传逻辑触发的线程等待，确认后续35-R消息是否被会话层接收但未递交给应用层。
• 排查日志表写入的同步/异步逻辑：消息能写入JdbcLogIncomingTable说明会话层已接收并持久化消息，但未转发到fromApp。如果日志写入是同步操作，且出现隐性阻塞（如数据库连接池耗尽但未抛出异常），可能导致会话层线程挂起，无法完成消息转发。
• 检查QuickFix线程模型配置：确认是否自定义了线程池，或配置了ThreadPoolSize参数，若线程池耗尽会导致应用层消息无法被调度处理。
• 抓取JVM线程堆栈：在阻塞期间生成线程快照，定位是否有线程卡在fromApp方法、AG发送逻辑或相关依赖调用上，这是最直接的定位手段。

内容的提问来源于stack exchange，提问作者Adan Vinicius