4

Seam リファレンス ガイドには、次の段落があります。

components.xml で、同時リクエストのタイムアウト (ミリ秒単位) の適切なデフォルトを設定できます。

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

ただし、500 ミリ秒では、対処しなければならないほとんどのケース、特に会話アクセスの厳しい制限の継ぎ目では十分ではないことがわかりました。

私たちのアプリケーションでは、ページ スコープの ajax リクエスト (さまざまなユーザー アクションによってトリガーされる)、いくつかのグローバル スコープのポーリング通知ロジック (ヘッダーの一部であるため、すべてのページに含まれます)、およびアクションを呼び出したり他のページに移動したりする通常のリンクの組み合わせがあります。ページ。

したがって、サイトに大きな負荷がかかっていなくても、会話例外への恐ろしい同時アクセスが頻繁に発生します。

オプションをかなり調査した後、推奨される解決策のいずれも問題を完全に解決できないようだったため (グローバルなすべての ajax リクエストのキューは、ポーリング呼び出しの 1 つが進行中のときに、ユーザーがリンクをクリックすることを決定する危険にさらされたままになります)。また、間違ったタイミングでリンクをクリックしたという理由だけでエラー ページが表示されるのではなく、ユーザーに 1 ～ 2 秒待ってもらいたいと考えています。

そして、ここで質問があります: 何か明らかに欠けているものはありますか? seam でこの問題 (ユーザー主導の対話と混合された ajax リクエスト) をどのように解決しますか? ajax リクエストの進行中にページ上のすべてのリンクを無効にする (あるブログ ページで提案されているように) ことは、実際には実行可能なオプションではありません。

他の提案はありますか？

ティア、アンドレイ

4

4 に答える 4

4

60000または120000（1〜2分）を使用します。Concurrent-request-timeoutは、デッドロックを回避するように設計されています。歴史的に、タイムアウトに関してはデッドロックよりもはるかに多くの問題があります。より良いアプローチは、クライアント側のキュー（<a4j:ajaxQueue>RichFacesを使用している場合）を使用して重複する要求を可能な限りシリアル化して削除し、残りの問題を回避するためにタイムアウトを十分に高く設定することです。

Seamの同時リクエストタイムアウトに起因する多くの深刻な問題があります。

  • 問題は、最後のリクエストがConcurrentRequestTimeoutExceptionを取得することです。ユーザーがページをダブルクリックまたはリロードした場合、最後のリクエストのみが重要になります。なぜエラーが発生するのでしょうか。
  • 通常、ConcurrentRequestTimeoutExceptionは抑制され、セカンダリNullPointerExceptionsと@Inインジェクションの失敗のみが表示されるため、デバッグが困難になります。
  • Seam 2.2.1には、タイムアウトが発生した後、特に。と一緒に使用した場合に、トランザクション、ThreadLocals、およびロックがリーク<spring:spring-transaction/>する可能性があるという深刻な問題があります。見てくださいSeamPhaseListener.afterRestoreView：失敗finallyした後にクリーンアップするブロックはありません！restoreConversation

私の意見では、この設計には多くの悪い側面があるため、はるかに高いタイムアウトを使用して、問題を回避することをお勧めします。

于 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

また、concurrent-request-timeout にははるかに高い値を使用します。

少なくとも重複するイベントについては、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 に答える