有没有办法释放饱和的连接池？
我正在 glassfish 服务器上使用开放式 esb。 我们有一个与 as400 数据库配合使用的连接池。
每隔几天我们就会收到此错误： 分配连接时出错。 原因：使用中的连接数等于 max- 池大小和过期的最大等待时间。 无法分配更多连接
缓解 cp 的最佳方法是重新启动服务器。 我们还成功地设置了另一个具有相同属性的 cp。
我的问题是： 有没有办法主动“告诉”cp释放其所有打开的连接？
干杯， 埃兰
I'm working with open esb on a glassfish server.
We have a connection pool that works with an as400 Database.
Every couple of days we get this error:
Error in allocating a connection. Cause: In-use connections equal max-
pool-size and expired max-wait-time. Cannot allocate more connections
The best way to relief the cp is to restart the server.
We've also managed to set to another cp with the same attributes.
My questions is:
Is there a way to actively "tell" the cp to release all of its open connections?
Cheers,
Eran
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
在此之前，请找出连接未正确释放的原因。 听起来好像有一个地方忘记了这一点（finally 子句中是否有所有 close() ？）。
我强烈推荐迈克尔·尼加兹的《释放它！》 了解使软件生产做好准备的技术。
编辑#1：如果我正确理解你的描述，你的后端程序会进入 QSYSOPR 中的 MSGW，这会导致连接挂起，直到给出响应，在你的情况下几乎永远不会。 是否可以选择使用默认回复“C”的配置文件，从而允许故障作为异常传播给您？
否则，您可以为连接或整个服务器设置 24 小时的超时期限吗？ 那么至少连接最终会被关闭。 该解决方案虽然无法扩展，但可能会使开发变得更容易。
请注意，也可以有一个单独的监视线程，定期查找 MSGW，并在抓取回调堆栈进行事后分析后自动向它们发送答案。
Before doing so, figure out why the connections are not released properly. Sounds like there is a single place where this is forgotten (do you have all close() in finally clauses?).
I can strongly recommend Michael Nygards "Release It!" for techniques to make software production ready.
EDIT#1: If I understand your description correctly your backend programs go in MSGW in QSYSOPR which results in a hanging connection until the response is given which in your case is close to never. Is it an option to use a profile with a default reply of "C" which allows the fault to propagate to you as an exception?
Otherwise you may be able to set a timeout period for either the connections or for the whole server of 24 hours? Then at least the connections will eventually be closed. This solution does not scale though, but may make development easier.
Please note, it is also possible to have a separate surveillance thread which looks for MSGW's regularily and send them an answer automatically AFTER grabbing the call back stack for post mortem analysis.
如果您可以在几秒内确定“正常”连接使用的上限，则可以使用 GlassFish 的连接泄漏检测机制。 在 GF 的管理控制台（我使用 v2.1）中，转到资源/JDBC/连接池/[您的 cp]/高级，然后在连接设置下将泄漏回收设置为 true，并设置泄漏超时时间（以秒为单位）。
If you can determine an upper bound for "normal" connection usage in seconds you can use GlassFish' connection leakage detection mechanism. In GF's admin console (I use v2.1) go to Resources / JDBC / Connection Pools / [your cp] / Advanced and under Connection Settings set Leak Reclaim to true and set a time in seconds for Leak Timeout.
我遇到了这个问题，结果发现是事务管理的问题。 将 @TransactionManagement(TransactionManagementType.BEAN) 添加到类中解决了该问题。 就我而言，我不需要任何交易代码，但您的里程可能会根据您的要求而有所不同。
I had this problem and it turned out to be the Transaction Management. Adding @TransactionManagement(TransactionManagementType.BEAN) to the class solved the problem. In my case, I didn't want any transaction code, but your mileage may vary depending on your requirements.
您在对 Andersen 的评论中提到您收到了抛出的 AS400 消息。 您可以设置这些消息的自动应答，以避免异常消息处于打开状态。 查看 AS400 上的 WRKRPYLE（工作回复列表条目）命令，以自动回复这些错误并避免挂起。
You mentioned in your comment to Andersen that you're getting AS400 messages thrown. It's possible for you to set up automatic answers to these messages to avoid leaving the exception message open. Check out the WRKRPYLE (Work Reply List Entry) command on the AS400 to automatically reply to these errors and avoid a hang.