我正在 glassfish 服务器上使用 open esb。我们有一个与 as400 数据库一起使用的连接池。
每隔几天我们就会收到此错误:分配连接时出错。原因:使用中的连接等于 max-pool-size 和过期的 max-wait-time。无法分配更多连接
缓解 cp 的最佳方法是重新启动服务器。我们还设法设置了另一个具有相同属性的 cp。
我的问题是:有没有办法主动“告诉” cp 释放其所有打开的连接?
干杯,伊兰
我正在 glassfish 服务器上使用 open esb。我们有一个与 as400 数据库一起使用的连接池。
每隔几天我们就会收到此错误:分配连接时出错。原因:使用中的连接等于 max-pool-size 和过期的 max-wait-time。无法分配更多连接
缓解 cp 的最佳方法是重新启动服务器。我们还设法设置了另一个具有相同属性的 cp。
我的问题是:有没有办法主动“告诉” cp 释放其所有打开的连接?
干杯,伊兰
在此之前,请弄清楚连接未正确释放的原因。听起来好像有一个地方被遗忘了(你在 finally 子句中都有 close() 吗?)。
我强烈推荐 Michael Nygards “放开它!” 为软件生产做好准备的技术。
编辑#1:如果我正确理解您的描述,您的后端程序会进入 QSYSOPR 中的 MSGW,这会导致连接挂起,直到给出响应,在您的情况下这几乎没有。是否可以选择使用默认回复为“C”的配置文件,允许故障作为异常传播给您?
否则,您可以为连接或整个服务器设置 24 小时的超时期限?然后至少连接最终将被关闭。此解决方案虽然无法扩展,但可能会使开发更容易。
请注意,也可以有一个单独的监视线程定期查找 MSGW,并在获取回调堆栈以进行事后分析后自动向他们发送答案。
如果您可以在几秒钟内确定“正常”连接使用的上限,则可以使用 GlassFish 的连接泄漏检测机制。在 GF 的管理控制台(我使用 v2.1)中,转到 Resources / JDBC / Connection Pools / [your cp] / Advanced 并在 Connection Settings 下将 Leak Reclaim 设置为 true 并为 Leak Timeout 设置以秒为单位的时间。
我遇到了这个问题,结果是事务管理。在类中添加 @TransactionManagement(TransactionManagementType.BEAN) 解决了这个问题。就我而言,我不想要任何交易代码,但您的里程可能会根据您的要求而有所不同。
您在对 Andersen 的评论中提到您收到了 AS400 消息。您可以设置对这些消息的自动答复,以避免让异常消息处于打开状态。查看 AS400 上的 WRKRPYLE(工作回复列表条目)命令以自动回复这些错误并避免挂起。