4

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

我们可以在 components.xml 中为并发请求超时（以毫秒为单位）设置一个合理的默认值：

<core:manager concurrent-request-timeout="500" />

然而，我们发现 500 毫秒对于我们必须处理的大多数情况来说还不够，尤其是在对话访问受到严格限制的情况下。

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

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

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

现在的问题是：我们是否缺少一些明显的东西（例如一种允许并发访问对话并处理我们自己所需的锁定的方法，例如:)？人们如何在 seam 中解决这个问题（ajax 请求与用户驱动的交互混合）？在 ajax 请求正在进行时禁用页面上的所有链接（如一个博客页面所建议的那样）实际上不是一个可行的选择。

还有其他建议吗？

TIA，安德烈

4

4 回答 4

4

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

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

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

In my opinion there are many poor aspects to this design, so it's best to use a much higher timeout and try to avoid the issues.

于 2011-10-20T19:19:23.213 回答
3

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

<core:manager concurrent-request-timeout="5000"
    conversation-timeout="120000" conversation-id-parameter="cid"
    parent-conversation-id-parameter="pid" />
于 2010-05-20T09:32:52.613 回答
1

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

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

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

于 2011-06-28T14:50:18.200 回答
0

你能分析一下哪些类型的请求需要很长时间吗？是否有一种特定类型可以通过异步执行“工作”并在投票中获取更新来减少请求时间？

在我看来，ajax 请求应该总是相当快地完成，然后您可以通过（请求时间 * 可能发起的最大请求数）计算最大并发请求时间

于 2010-05-20T08:23:15.613 回答