使用OracleJdbcMessageStore遇ORA-01795错误，处理千条消息后异常

嘿，看你描述的情况：配置了ExpressionEvaluatingRequestHandlerAdvice，成功时转日志、失败时回存JDBC消息存储，前期正常但处理1000条后炸了——这种场景我碰到过好几次，给你梳理几个高概率的排查方向和解决办法：

1. 先查数据库连接池是不是被耗干了 #

JDBC消息存储全靠数据库连接撑着，处理到一定量就报错，大概率是连接没正确释放，把连接池占满了。

• 先看事务配置：如果消息处理开了事务，但异常场景下事务没正确回滚、连接没归还，那每条失败消息都会占着一个连接，攒到1000条就把池掏空了。
• 解决思路：
  • 确认ExpressionEvaluatingRequestHandlerAdvice的异常逻辑里，事务能正常触发回滚（比如用@Transactional或者Spring Integration的事务网关），确保连接能还给池。
  • 临时救急可以调大连接池的maxActive参数，但这只是缓兵之计，核心还是要找连接泄漏的点——比如开HikariCP的leakDetectionThreshold（设成30秒），能直接定位到哪段代码没释放连接。

2. 消息存储的并发锁冲突也可能搞事情 #

失败消息回写JDBC存储时，高并发下很容易出现锁竞争或者事务冲突，尤其是处理量上来之后：

• 检查你JDBC Message Store的isUsingIdCache配置，如果开了ID缓存，高并发下可能出现缓存不一致，导致插入/更新失败。
• 解决思路：
  • 先试试把ID缓存关了（setUsingIdCache(false)），虽然会多一点数据库查询，但能避开并发缓存冲突的坑。
  • 调小处理线程池的核心线程数，别让太多线程同时写数据库，减少锁竞争的概率。
  • 数据库隔离级别别设太高，用READ_COMMITTED就够了，能缩短锁的持有时间。

3. 看看Advice的失败处理逻辑有没有暗坑 #

如果onFailureExpression里的转发逻辑有未捕获的异常，比如消息头缺失、类型转换错了，那处理到某条消息时就会崩掉整个链路：

• 检查你的Advice配置，比如onFailureExpression是不是正确处理了失败消息的所有属性，有没有可能转发时触发了新的异常。
• 解决思路：
  • 在失败表达式里加个try-catch包裹逻辑，确保即使转发失败也不会抛出未处理的异常。
  • 开Spring Integration的DEBUG日志，盯着失败消息的详细处理流程，看转发回存储时到底哪一步报错了。

4. 数据库表的性能瓶颈也不能忽略 #

如果JDBC消息存储的表没建对索引，处理1000条后查询和写入速度会暴跌，甚至超时：

• 检查你的消息存储表（比如默认的INT_CHANNEL_MESSAGE），看看CHANNEL_ID、CREATED_DATE这些字段有没有建索引。
• 解决思路：
  • 给这些常用查询字段加索引，优化读写性能。
  • 定期清理已处理完的消息，别让表数据堆太满——用Spring Integration的MessageStoreCleaner就能自动清理过期消息，省得手动删。

要是能把完整的异常栈贴出来，就能更精准定位问题了，但上面这几个方向是这类问题的常见诱因，你可以先挨个排查试试~

内容的提问来源于stack exchange，提问作者Rok Purkeljc