Azure Kubernetes部署应用连接本地DB2出现JDBC连接异常是什么原因？

你遇到的该连接异常大概率和两端跨不同网络的部署架构直接相关。

对应报错信息如下：

ERROR : 07.16.2021:0709 (05.988) [[]http-nio-8080-exec-4] ShippingSatelliteForm: /addLeadTimeForShippingBakeries.xhtml, user - The bean encountered a non-application exception; nested exception is: ERROR : 07.16.2021:0709 (05.988) [[]http-nio-8080-exec-4] ShippingSatelliteForm: /addLeadTimeForShippingBakeries.xhtml, user - The bean encountered a non-application exception; nested exception is:  org.hibernate.exception.JDBCConnectionException: could not execute query 

Caused by: com.ibm.db2.jcc.am.DisconnectNonTransientConnectionException: [jcc][t4][2030][11211][4.21.29] A communication error occurred during operations on the connection's underlying socket, socket input stream,  Caused by: com.ibm.db2.jcc.am.DisconnectNonTransientConnectionException: [jcc][t4][2030][11211][4.21.29] A communication error occurred during operations on the connection's underlying socket, socket input stream, or socket output stream.  Error location: Reply.fill() - insufficient data (-1).  Message: Insufficient data. ERRORCODE=-4499, SQLSTATE=08001

上述报错中的ERRORCODE=-4499, SQLSTATE=08001是IBM DB2 JDBC驱动的标准连接中断错误码，本质是应用端和数据库之间已经建立的TCP连接被意外断开，驱动读取数据库返回报文时只拿到了不完整的数据，因此抛出该异常。

跨网络场景下的常见触发原因 #

Azure Kubernetes集群部署在公有云，DB2部署在本地机房，两者之间的通信链路属于跨网链路，这类场景下触发该错误的常见原因如下：

• 链路中间的NAT网关、防火墙等设备存在空闲连接超时回收机制，会主动断开长时间无流量的TCP连接，而数据库连接池中的闲置连接无法感知到该断开操作，当业务请求拿到这类已经被静默断开的连接执行查询时就会触发报错
• 跨网链路本身存在抖动、丢包问题，高峰时段带宽不足或者链路故障也会导致连接中途断开
• 两端的网络访问控制策略（本地机房出口防火墙规则、Azure VPC网络安全组规则）存在动态限流、连接数上限限制，也会偶发中断已建立的连接

修复建议 #

• 先验证链路稳定性：进入Azure Kubernetes集群的业务Pod中，长时间执行mtr或者tcping命令向DB2的IP和服务端口发包，确认是否存在丢包、超时的情况
• 调整数据库连接池配置：
  • 开启连接有效性检查，每次从连接池获取连接时先执行验证SQL（DB2下为SELECT 1 FROM SYSIBM.SYSDUMMY1），确认连接可用后再交给业务使用
  • 调低连接的最大空闲时间，确保该值小于链路中间所有网络设备的最小空闲超时阈值，一般设置为5~10分钟即可
  • 开启连接池的闲置连接定期清理功能，主动销毁长时间未使用的空闲连接
• 网络层面优化：如果当前是走公网连接本地DB2，优先切换为Azure专线或者IPsec VPN打通两边网络，降低公网抖动影响；同时确认两边的网络设备没有对DB2的服务端口做额外的连接超时限制

异常截图参考：

内容的提问来源于stack exchange，提问作者One Developer