5

私はフレックス/LCDS スタックを持っていますが、ログアウト後にDuplicate HTTP Sessionクライアントでエラーを受け取ることがよくあります (常にではありません)。

スタックの重要な事実は次のとおりです。

  • フレックス クライアントには、アプリ内にログイン/ログアウト機能があります。ログアウト後にページが更新されません。(したがって、Flex アプリとその基盤mx.messaging.FlexClientは初期化されたままです)
  • ユーザーは複数のタブを開いている場合があります。
  • per-client-authenticationに設定されfalseています-SSO（CASとの統合）を実現しようとしているため、ユーザー原則はJSessionにバインドされています。
  • この問題は、メッセージングにロング ポーリングを使用している場合、および 2 つ (またはそれ以上) のタブが開いている場合に最も顕著になります。
  • RTMP またはストリーミング チャネルを使用している場合、この問題を再現するのは非常に困難です。
  • ユーザーは JSession にバインドされます。つまり、ユーザーが Tab1 にログインすると、Tab2 にログインします。
  • ユーザーがいずれかのタブからログアウトすると、Jsession は無効になります。

問題の原因についての私の現在の理論は次のとおりです。

  • Tab1 (T1) クライアント起動 -> 発行済み ClientId1 (C1) -> JSession1 (J1) 作成
  • Tab2 (T2) クライアントを開始 -> ClientId2 (C2) を発行 -> J1 に参加
  • T1 ログイン -> J1 影響なし
  • T2 ログイン -> J1 影響なし
  • T1 & T2 両方がサブスクライブし、ポーリングを開始しますamflongpolling
  • T1 がログアウトを送信 -> J1 無効化 -> J2 作成
  • T2 がポールを送信 (J1 に対して)
  • T1 ログアウトが完了し、J2 で戻り、Cookie を更新します

最後の 2 つの呼び出しは競合を引き起こし、FlexClientLCDS は が 2 つの JSession に関連しているように見えます。

その結果、次の行に沿ったエラーが受信されます。

Server.Processing.DuplicateSessionDetected 重複した HTTP ベースの FlexSession が検出されました。これは通常、リモート ホストがセッション Cookie を無効にしていることが原因です。クライアント接続を正しく管理するには、セッション Cookie を有効にする必要があります。

注: スタンドアロン プロジェクトで問題を再現できました。 アプリケーション固有のコードの問題ではなく、ステートフル/セッションの性質と、同じセッションを共有する複数のタブ間の競合が原因であると思います。

要約すると、1 つのタブからの呼び出しの結果としてサーバー上でセッションが無効になっているが、新しい JSession を通知する応答がブラウザに送信される前に、古い Jsession で呼び出しが発行されるという問題が発生していると考えられます。 .

この重複セッションの問題を防ぐための適切な戦略は何ですか?

アップデート

明確にするために、シナリオはここで説明したものと似ていますが、その記事のソリューションを不適切にする微妙な違いがあります。

具体的には、この記事では、JSP またはオーケストレーションされた RemoteObject 呼び出しを使用して、両方のブラウザーで JSessionの初期作成を制御することにより、セッションの重複を防止する方法について説明しています。

DSidFlexは、最初のセッションが確立されたことを示すローカル FlexClient 変数が定義されるまで、アウトバウンド RemoteObject 呼び出しを防止することで、実際にこのプロセスを支援します。

私のシナリオは異なります。なぜなら、JSession (および関連する LCDS FlexSession / クライアント側 FlexClient オブジェクト) は既に一度確立されており (その記事で説明されている手法を使用)、その後、ログアウトによって無効化されsession.invalidate()、JSession を破棄するためです。

この問題は、Tab2 が古い JSession、重複 HTTP セッション エラーで呼び出しを送信したときに発生します。LCDS が DuplicateHTTPSession エラーをスローすると、クライアントに接続されているすべての既知の Jsession も無効になるため、状況は悪化します。次に Tab1 が呼び出しを送信すると、IT によって DuplicateHTTPSession エラーが発生し、サイクルが繰り返されます。

残念ながら、セッションが確立されている間に呼び出しを遅らせるための Flex フレームワークのフックには、一度設定すると再度有効にする簡単な方法がありません (私が見つけました)。（私は次のことを試しましたが、役に立ちませんでした:)

 // Reset DSid to get a new FlexSession established on LCDS
   use namespace mx_internal

   public function resetFlexSession()
   {
        FlexClient.getInstance().id = null;  
        // Note - using FlexClient.NULL_ID also doesn't work.
   }
4

3 に答える 3

1

私はあなたに同情します-私は長い間これと戦ってきましたが、解決策は見つかりませんでしたが、私にとってはうまくいく修正を見つけました。（もしそうなら、ここに投稿してください）。

今、私はあなたとは少し異なる環境を持っているので (私はバックエンドで CF を使用しています)、それを心に留めておいてください。

「FlexClient.getInstance().id = null;」全体も試しました。それ自体では機能しませんでしたが、それを機能させる方法と場所でした。

それで、これが私がしたことで、問題は解消されました。

私のメイン フォームでは、RemoteServer 呼び出しが行われる前に、creationComplete ハンドラーをセットアップし、既におなじみの次のコードを配置しました。

// Not sure if this is needed anymore, but I'm leaving it in
FlexClient.getInstance().id = null;

次に、サーバーへの最初の呼び出しで、失敗を適切に処理し、その悪臭を放つ ID を再びクリアします。

    public function login(event:Event): void {

        Swiz.executeServiceCall(roUsers.login(),
            function (event:ResultEvent): void {
                // Handle a successful login here...
            }
            , function (faultevent:FaultEvent): void {
                // This code fixes this issue with IE tabs dying and leaving Flex with a Duplicate Session problem.
                if (faultevent.fault.faultString.indexOf("duplicate")) {
                  FlexClient.getInstance().id = null;
                  Swiz.dispatchEvent(event);
                }
        });

    }

そしてそれはうまくいきました。

基本的に、呼び出しを試して、セッションの重複が原因で失敗した場合は、その ID を消去して呼び出しを再発行します。

重要な点は、サーバーに対して少なくとも 1 回の呼び出しを行うまで、ID の消去が機能しないと思うことです。一度やると、それは私にとって、そして私のすべてのアプリでCHARMのように機能しました.

上記の SWIZ フレームワークを使用しているので、自分の世界に翻訳してください。

ところで、私はこのエラーを IE 以外のブラウザで見たことがありません.

上記が機能しない場合は、サーバー上のいくつかの構成ファイルにいくつかの変更が役立つ可能性があることも知っています。

幸運であれ友よ！

于 2011-11-22T23:50:05.610 に答える
0

知っておくべき追加の、関連のない原因。

一部のブラウザー (Internet Explorer など) は、Cookie にドメイン命名規則を適用します。これは、「my_clientX.server.com」のようなコード ドメインが、有効な BlazeDS 応答を返す可能性があっても、Cookie へのアクセスとして重複セッション通知を継続的にトリガーすることを意味します。ブロックされます。

名前を有効な名前 (アンダースコアなし) に変更すると、問題が解決します。

于 2014-09-02T13:51:04.487 に答える
0

この記事、Avoiding duplicate session detected errors in LCDSというタイトルで、状況で何が起こっているかについて詳しく説明しています。関連する引用は次のとおりです。

...[LCDS] は、リクエストを受信した FlexClient がサーバー上の別のセッションに既に関連付けられていると考えています。

クライアント アプリケーションが、アプリケーション内の FlexClient がこのような悪い状態にならないようにするためには、クライアント アプリケーションは、複数の FlexClient が同時にサーバーに接続する前に、サーバー上でセッションが既に確立されていることを確認する必要があります。

これを修正するには、次のようないくつかのアプローチが推奨されます。

  • jsp ページを呼び出してアプリケーションをロードする
    "The jsp page could both create a session for the client application and return an html wrapper to the client which would load the swf."
  • リモーティング先の呼び出し
    "which would automatically create a session for the client application on the server"
于 2011-11-21T18:25:37.600 に答える