我在这里打开了一个关于提高XPage中30gb工作流应用程序性能的问题。有很多建议，但大多数都涉及回收，改进代码等。实际上已经解决了速度问题的问题 - 应用程序属性中的高级选项卡（请参阅我的上一篇文章）
现在我的应用程序运行得非常好，速度很快，人们很高兴，但服务器仍然会定期崩溃。或者我应该说，HTTP变得没有响应，并且在极端情况下运行100％CPU，因此Domino也很迟钝但仍在运行。
我一直用
监视HTTP线程告诉http show thread state
在大多数情况下，我看到80个http线程处于空闲状态，或者正在做一些事情但很快就会发布。自上次更新应用程序以来，我们更专注于回收SSJS中的notes对象，我想我们会看到挂起的http线程的结束，但它仍然存在。
我几乎肯定这不是一个导致这个问题的无限循环，因为我与最终用户确认的2个案例是完全不同的，据我所知，没有循环。
用户正在编辑文档，按工作流程按钮批准并将其发送给下一个用户。他们正在使用Chrome。 Chrome选项卡上的旋转圆圈启动，然后服务器应运行工作流代理，发送电子邮件，然后在浏览器上关闭页面。我注意到有2或3个挂起的http线程在一小时后没有被释放所以我联系了用户，她告诉我页面没有刷新但旋转的圈子仍在旋转，表明服务器正在做某事。我检查了日志和工作流代理HAS运行，电子邮件已发送并且文档已更新。她刷新了页面，现在可以看到它已被更新，但无论出于什么原因，Chrome坐在那里耐心地等待，从未收到LS代理已运行的消息。我使用notesAgent.runOnServer并返回结果整数以确认代理是否已运行。如果它返回1（我认为）那么该页面应该关闭，否则它应该显示一条消息。页面永远不会刷新，所以它没有显示任何内容，但代理确实完成了。
晚上的用户最终得到了大约15个挂起的http线程。在日志中我可以看到她试图多次重新加载页面。然后搜索了她想要的文档，然后尝试打开它。当我检查她说她搜索了文件时，搜索页面显示了结果（重复控制），每次她点击文件打开它都没有发生。因此，她甚至没有进入文档，但每次尝试后线程都挂了。我从笔记日志中获取了URL并尝试了，文档打开正常。我运行相同的搜索，文档打开正常。我直接向她发送了一份文件链接，对她来说很好。怪异!!
有没有办法诊断这种行为，因为现在我必须让domino管理员打开运行tell http show ....命令全天密切关注它以确保线程不会挂起。它通常到午餐时间，服务器需要重启，这是垃圾。
请帮助我理智： - ）
答案 0 :(得分：1)
寻找锁定的线程。 As I said before，获取更多信息 - 在您的情况下，javadumps会有所帮助。发出服务器命令tell http dump java core（当http被冻结时，浏览器中的按钮赢得了帮助:-)）。这会生成javacore文件并使用IBM Thread and Monitor Dump Analyzer for Java来查看每个线程的状态。
您将（可能）发现的是线程等待一些Notes API调用。请发布悬挂线程的样本堆栈跟踪。
答案 1 :(得分：1)
我使用了一些Java转储来分析它们是否存在内存泄漏，而我在那里发现了大量信息，并不知道我在寻找什么意味着我没有得出任何结论。
纯粹是偶然的，我需要使用随机导致这些线程锁定的系统中的文档，并且我手动运行在处理这些文档时调用的Workflow代理。我花了一分钟才意识到发生了什么，但是当试图根据文档内容生成一个mime电子邮件时，代理似乎陷入了困境。
当预定的代理卡在Domino中的无限循环中时，只需查看管理客户端中的代理管理器即可轻松发现。您将看到它不断消耗CPU并且永远不会完成。
当XPage调用一个卡住的代理时，没有任何线索（至少在我的情况下）代理管理器正在运行且HTTP Server任务没有显示它正在做任何不寻常的事情。这就是为什么我最初认为没有无限循环，但我完全错了！
我添加了一些代码来计算mime电子邮件生成器例程中已达到的循环次数，并添加了一个中断，如果它达到某个任意高的值，表明它被卡在循环中。 EtVoilà！没有更多的挂起的http线程！
这是一个很好的借口，可以通过整个系统并修复一些旧的（差）代码，并整理所有内容。最终虽然是代理商而不是导致问题的xpage。谢谢大家的建议。
答案 2 :(得分：0)
我强烈建议采取两种措施：
并使用Frantisek的见解