Question

在Seam参考指南中，可以找到此段落：

我们可以在components.xml中为并发请求超时（以ms为单位）设置合理的默认值：
<core:manager concurrent-request-timeout="500" />

然而，我们发现500毫秒对于我们不得不处理的大多数情况来说已经不够时间了，特别是在会话访问时存在严重的限制接缝。

在我们的应用程序中，我们有页面范围的ajax请求（由各种用户操作触发），一些全局范围的轮询通知逻辑（标题的一部分，因此包含在每个页面中）和调用操作的常规链接和/或导航到其他页面。

因此，即使网站没有任何重大负载，我们也经常会遇到可怕的并发访问对话异常方式。

在对选项进行了相当多的研究之后，我们最终将这个值提高了几秒钟（我们正在讨论是否将其提升到10秒），因为没有一个推荐的解决方案能够完全解决我们的问题（甚至强制所有ajax请求的全局队列仍然会让我们在我们的某个轮询调用正在进行时让用户决定单击链接。而且我们宁愿让用户等一两秒而不是因为他们在错误的时刻点击链接而得到错误页面。

现在问题是：是否有一些显而易见的问题（例如，允许并发访问对话并自行处理所需锁定的方法）？人们如何解决这个问题（ajax请求与用户驱动的交互混合）？在ajax请求正在进行时禁用页面上的所有链接（如一个博客页面所示）实际上不是一个可行的选择。

还有其他建议吗？

TIA，安德烈

Answer 1

我们使用60000或120000（1-2分钟）。并发请求超时旨在避免死锁。从历史上看，我们在超时问题上遇到的问题多于死锁问题。更好的方法是使用客户端队列（<a4j:ajaxQueue>，如果使用RichFaces）尽可能地序列化和删除重复请求，然后将超时设置得足够高以避免任何剩余问题。

Seam的并发请求超时导致了许多严重问题：

问题是 last 请求获取ConcurrentRequestTimeoutException。如果用户双击或重新加载页面，则只有 last 请求很重要 - 他为什么会收到错误？
通常会抑制ConcurrentRequestTimeoutException，并且只显示辅助NullPointerExceptions和@In注入失败，从而使调试变得困难。
Seam 2.2.1存在严重问题，其中事务，ThreadLocals和锁可能在发生超时后泄漏，尤其是与<spring:spring-transaction/>一起使用时。看看SeamPhaseListener.afterRestoreView：在finally失败后，没有restoreConversation块可以清理！

在我看来，这个设计有很多不好的方面，所以最好使用更高的超时并尽量避免这些问题。

Answer 2

这就是我们所拥有的，它对我们来说很好：

<core:manager concurrent-request-timeout="5000"
    conversation-timeout="120000" conversation-id-parameter="cid"
    parent-conversation-id-parameter="pid" />

Answer 3

我们还为并发请求超时使用了更高的值。

至少对于重复事件，您可以使用a4j组件中的设置来使用eventsQueue，requestDelay和ignoreDupResponses =“true”过滤和延迟它们。

（最后一点http://docs.jboss.org/seam/2.0.1.GA/reference/en/html/conversations.html）

Answer 4

您能分析哪些类型的请求需要很长时间吗？是否有一种特殊类型可以通过异步执行“工作”并在轮询中恢复更新来减少请求时间？

在我看来，ajax请求应该总是很快完成，然后你可以计算最大并发请求时间（请求时间*可能启动的最大请求数）

并发请求超时参数或选项的实用值，用于避免对会话异常的并发访问

4 个答案: