XPage HTTP 线程挂起

Question

我有一个关于提高 XPage 中 30gb 工作流应用程序性能的问题。 有很多建议，但大多数涉及回收、改进代码等。实际上解决速度问题的方法很少被讨论——应用程序属性中的高级选项卡（请参阅我的最后一篇文章）

现在我有一个运行良好的应用程序，速度很快，人们很高兴，但服务器仍然会定期崩溃。 或者我应该说，HTTP 变得无响应，并且在极端情况下运行 100% CPU，所以 Domino 也很慢但仍在运行。

我一直在监视 HTTP 线程

告诉 http 显示线程状态

在大多数情况下，我会看到 80 个空闲的 http 线程，或者正在执行某些操作但很快被释放。 自从上次更新应用程序以来，我们更加专注于在 SSJS 中回收笔记对象，我以为我们会看到挂起的 http 线程结束，但它仍然存在。

我几乎可以肯定，导致此问题的不是无限循环，因为我已与最终用户确认的两种情况完全不同，据我所知，没有任何循环。

1. 用户正在编辑文档，按下工作流按钮以批准并将其发送给下一个用户。 他们正在使用 Chrome。 chrome 选项卡上的旋转圆圈开始，然后服务器应该运行工作流代理，发送电子邮件，然后关闭浏览器上的页面。 我注意到有 2 或 3 个挂起的 http 线程在一个小时后还没有释放，所以我联系了用户，她告诉我页面没有刷新但旋转圈仍在 chrome 中旋转，这表明服务器正在做一些事情. 我检查了日志并且工作流代理已经运行，电子邮件已经发送并且文档已经更新。 她刷新了页面，现在可以看到它已经更新了，但无论出于何种原因，Chrome 都坐在那里耐心等待，从未收到 LS 代理已运行的消息。 我使用 notesAgent.runOnServer 并返回结果整数以确认代理是否已运行。 如果它返回 1（我认为）那么页面应该关闭，否则它应该显示一条消息。 该页面从未刷新，因此它没有显示任何内容，但代理确实完成了。

2. 一个用户在晚上结束了大约 15 个挂起的 http 线程。 在日志中，我可以看到她多次尝试重新加载页面。 然后搜索了她想要的文档，然后又尝试打开它。 当我检查她说她搜索了文档时，搜索页面显示了结果（在重复控件中），每次她单击文档打开它时都没有发生任何事情。 所以她甚至没有进入文档，但每次尝试后线程都挂了。 我从笔记日志中获取了 URL 并尝试了它，文档打开正常。 我进行了相同的搜索，文档打开正常。 我直接向她发送了一个指向该文档的链接，它对她来说打开得很好。 奇怪的！！

有什么方法可以诊断这种行为，因为现在我必须让多米诺管理员打开运行 tell http show.... 命令整天关注它以确保线程没有挂起。 通常到午餐时间，服务器需要重新启动，这是垃圾。

请帮助我保持理智:-)

Answer 1

寻找锁定的线程。 正如我之前所说，获取更多信息 - 在您的情况下 javadumps 会有所帮助。 发出服务器命令tell http dump java core （当 http 被冻结时，浏览器中的按钮将无济于事:-)）。 这将生成 javacore 文件并使用IBM Thread and Monitor Dump Analyzer for Java查看每个线程的状态。

您（可能）会发现线程等待某些 Notes API 调用。 请发布挂起线程的示例堆栈跟踪。

Answer 2

我使用了一些 Java 转储来分析它们的内存泄漏，虽然我在那里发现了大量信息，但不知道我在寻找什么意味着我没有找到任何结论。

纯粹是偶然，我需要处理系统中随机导致这些线程锁定的文档，并且我手动运行了在处理这些文档时调用的 Workflow 代理。 我花了一分钟才意识到发生了什么，但是当试图根据文档内容生成 mime 电子邮件时，代理似乎陷入了循环。

当调度的代理陷入 Domino 中的无限循环时，只需查看 Admin Client 中的代理管理器即可轻松发现。 您会看到它不断消耗 CPU 并且永远不会完成。

然而，当 XPage 调用一个卡住的代理时，没有任何线索（至少在我的情况下）代理管理器正在运行，并且 HTTP Server 任务没有显示它正在做任何异常的事情。 这就是为什么我最初认为没有无限循环，但我完全错了！

我添加了一些代码来计算在 mime 电子邮件生成器例程中达到的循环数，并在达到某个任意高的值时添加一个中断，表明它被卡在一个循环中。 等等！ 不再有挂起的 http 线程！

这是一个很好的借口，可以检查整个系统并修复其中的一些旧的（糟糕的）代码，并整理所有内容。 最终虽然是代理而不是导致问题的 xpage。 不过还是谢谢大家的建议。

Answer 3

我强烈建议采取两种措施：

• 将您的代理转换为 Java 库。 这比听起来要少得多，并且可以使您免于每次都启动代理运行时（挂起的潜在来源）
• 如果这还不够，请使用线程，因为您需要重新考虑通知机制，因此工作量更大

并使用 Frantisek 的见解