切换PostgreSQL后QuickfixJ的FIX连接心跳及登录超时问题

问题背景 #

我们的客户端应用基于FIX协议实现，依赖QuickfixJ 2.3.0组件，此前使用Oracle数据库的quickfix_sessions表存储会话收发序列（QuickfixJ会自动维护该表的序列数据）。切换到PostgreSQL后，出现以下无规律异常：

• 发送TestRequest后触发heartbeat响应超时，但FIX消息日志明确显示已收到对应响应
• 重连阶段多次出现等待登录响应超时，但最终能成功完成重新登录
• 断开现象无固定规律：有时全天正常，有时一天发生2-3次，间隔1~4小时，且数据库日志无异常
• 当前心跳间隔配置为heartbeatInt = 30s

异常日志示例 #

Disconnecting: Timed out waiting for logon response
Initiated logon request
Disconnecting: Timed out waiting for logon response

排查与解决思路 #

1. 核对PostgreSQL事务处理逻辑差异 #

Oracle和PostgreSQL的READ COMMITTED隔离级别实现存在差异：PostgreSQL会在事务开始时生成快照，而Oracle是语句级快照。QuickfixJ在读写quickfix_sessions表时，若事务未及时提交，可能导致会话线程阻塞在数据库操作上，错过心跳/登录响应的超时判断。

• 确认QuickfixJ对quickfix_sessions的更新操作是否在每次序列变更后立即提交，避免长时间持有事务锁
• 可临时将PostgreSQL的事务隔离级别调整为READ UNCOMMITTED测试，看是否能缓解问题（仅用于排查，不建议长期使用）

2. 验证JDBC驱动兼容性 #

QuickfixJ 2.3.0属于较旧版本，需确保使用的PostgreSQL JDBC驱动版本与其兼容：

• 建议使用适配JDK1.6+的驱动版本（如postgresql-9.4.1212.jre6.jar），避免驱动层面的性能瓶颈或事务处理异常

3. 优化会话序列表的读写性能 #

对比Oracle与PostgreSQL下quickfix_sessions表的读写耗时：

• 开启PostgreSQL的慢查询日志（设置log_min_duration_statement = 1000），查看序列更新/查询操作是否存在耗时过长的情况（若单次操作超过10s，可能阻塞会话线程）
• 为quickfix_sessions表的主键字段（如beginstring、sendercompid、targetcompid等组合主键）建立索引，确保查询与更新的效率

4. 检查线程阻塞与会话缓存配置 #

QuickfixJ的消息处理线程可能因数据库操作阻塞，无法及时处理收到的响应：

• 添加线程监控，查看超时发生时会话线程是否卡在数据库IO环节
• 检查QuickfixJ配置中的CacheSessions参数是否设为true，开启会话序列缓存，减少频繁的数据库读写操作

5. 核对数据库连接池配置 #

若使用连接池（如HikariCP、DBCP），检查以下配置：

• 最大连接数是否满足应用需求，避免连接池耗尽导致获取连接阻塞
• 连接超时、空闲超时等参数是否合理，防止因连接回收不及时影响数据库操作

内容的提问来源于stack exchange，提问作者Avinash Mishra