問題タブ [session-replication]

2 つの tomcat サーバー (tcat01 と tcat02) を負荷分散アーキテクチャに配置する必要があります。

Tomcat 6.x を使用しており、tomcat tcat01 で次のように conf/server.xml を編集しました。

tcat02 では、conf/server.xml は次のようになります。

tcat01 を開始し、次に tcat02 を開始しました。 il catalina.out tcat01 は tcat02 とうまく通信しているようです。

次に、インターネットナビゲーターを使用して webapp に接続し、webapp で何かを行うたびに (ナビゲートするとき)、次の例外が発生します。

そして、これが sezialize できないクラスのコードです (つまり、スタック トレースで言及されている Java Bean):

次に、Java Bean グループのコードを示します (グループのコレクションに遅延初期化例外があるため)。

ご協力いただきありがとうございます

Tomcat クラスターに関する基本的な概念について質問があります。つまり、2 台のマシン ( m1 と m2 と言います) を持つ tomcat クラスターがあるとします。

m1 の Web ページにhttp://192.168.0.10:8080/examples/test.jspという URL でアクセスすると、セッション ID が取得されます (s1 と言います)。

次に、次の URL で m2 の別の Web ページにアクセスします。

セッション レプリケーション機能を既に構成している場合、s1 と s2 は同じですか?

ありがとう ！

現在、クラスター化された WebSphere 7 環境にデプロイされている JSF 2 + Spring 3 アプリケーションがあります。サーバーは、セッション処理のためにメモリ間レプリケーション用に構成されています。アプリケーションでテストを実行しているときに生成される一般的な例外は次のとおりです。

これが何を意味し、どのように解決するかについての考えはありますか? ありがとう。

フロントエンドのロードバランサーとしてApacheを使用してubuntuサーバーでテストTomcat Clusteringしました。session replication私のテスト経験から、Tomcat クラスタリングを使用しない方がよいと思いますが、各ノードをスタンドアロンとして実行し、セッション レプリケーションを使用せずにお互いを認識しないようにする方がよいと言えます。速度が遅く、Tomcat サービスの起動に時間がかかり、より多くのメモリを消費すると感じたからです。また、FarmDeployer展開では常に信頼できるとは限らず、構成全体を<Host></Host>要素の下に配置して、ファーム デプロイヤーが機能するようにし、各仮想ホスティングと巨大な server.xml ファイルを配置する必要があります。以下は、私が使用したノードの 1 つからのクラスター構成の tomcat 仮想ホスティングです。

Tomcat クラスタリングは本番環境での使用に適していますか、それともセッション レプリケーションの別の方法はありますか? または、上記の構成で微調整できるものが欠けていますか?

どんなアイデアでも大歓迎です。ありがとう！

Glassfish 3.1.1 オープン ソース エディションでのセッション レプリケーションに問題があります。クラスタには 2 つの物理サーバーが含まれています。最初のサーバーには DAS とインスタンス 1 があります。2 番目の物理サーバーにはインスタンス 2 があります。両方のサーバーで Windows 7 x64 が実行されます。私はこのチュートリアルに従っています：

http://javadude.wordpress.com/2011/05/12/glassfish-3-1-%E2%80%93-clustering-tutorial-part2-sessions/

セッション レプリケーションがいつ機能するかを理解する限り、両方の物理インスタンスの Web アプリにアクセスすると、同じセッションが存在するはずです。したがって、インスタンス 1 にログインすると、インスタンス 2 にも自動的にログインするはずです。これは正しいですか？

この問題を解決する方法を知っている人はいますか？

前もって感謝します。

Tomcat のコンテキストで、スティッキー セッションを有効にせずにセッション レプリケーションを実行できますか?

スティッキー セッションの目的は、クライアントをセッション全体で 1 つのサーバーに「固定」することだと理解しています。セッション レプリケーションを使用すると、クライアントとサーバーのやり取りがクラスター全体 (多数の Web サーバー) に複製されます。

上記の場合、セッションのレプリケーションは実行できますか? つまり、クライアントのセッションは Web サーバー全体に分散され、任意の 1 つの Web サーバーとの各対話がレプリケートされるため、シームレスな対話が可能になります。

両方のサーバーが稼働している2つのTomcatノードがあります。

1台のサーバーをシャットダウンすると、次の例外が発生し、セッションが複製されません。もう一度ログインする必要があります。いくつかの手順を逃しましたか？

Elastic Beanstalk を使用してデプロイされ、最低 2 つの EC2 マイクロ インスタンスで実行される Amazon Web Services で実行されている Web サイトを持っています。Web サイトのトラフィックに応じてスケールアップおよびスケールダウンできるように、自動スケーリング ポリシーが設定されています。この自動スケーリング ポリシーにより、スティッキー セッションの使用を避けたかったため、memcached-session-managerを使用しています。memcached サーバーに Amazon ElastiCache (スモール インスタンス) を使用しています。

context.xml の構成は次のとおりです。

これは、トラフィックが少ない場合 (つまり、オンラインのユーザーが 10 人未満) は正常に機能しますが、EC2 インスタンスが再起動することがあります。Web サイトが現在 2 つのインスタンスで実行されていて、両方が同時に再起動することを決定した場合、Web サイトにアクセスできなくなり、大きな問題になることは想像に難くありません。これらは、EC2 インスタンスが再起動を決定する前に Amazon S3 でローテーションされる tail_catalina.log の最後の行です。

Amazon ElastiCache ノードに障害が発生しているように見えますが、Amazon CloudWatch で確認すると、CPU 使用率が 8% を超えたことはありません。それほどストレスがかかっていないにもかかわらず、Amazon ElastiCache ノードが失敗する理由はありますか? また、Amazon ElastiChace ノードに障害が発生したときに、Amazon が再起動 (または、より良い方法: 新しいインスタンスを終了して開始) を決定するのはなぜですか?

どんな助けでも大歓迎です。

ありがとう！

Websphere 6内のhttpセッションに古い属性があり、メモリ内セッションのレプリケーションに関連している可能性があります。

手順：

1. オブジェクトA.0-ID「ABC」でセッションに配置されます
2. セッションからA.0を削除します。
3. オブジェクトA.1（新しいインスタンス）-ID「ABC」でセッションに配置されます
4. セッションからID「ABC」のオブジェクトを取得します-結果：A.1（正しい）
5. サーブレットの転送またはリダイレクトを実行します（両方の機能で問題が発生します）。
6. セッションから「ABC」を取得します-結果：A.0、セッションから削除されたオブジェクト。

ノート -

• 2つのJVM（単一クラスター）間でメモリレプリケーションを使用する手順1〜5で使用した同じセッションオブジェクト（ハッシュコード/セッションID）
• ステップ2と5の間の時間は合計4秒です
• その間、他の外部スレッドはセッションにアクセスしていません。
• 1つの特定のユースケースでのみ注目されます。
  他のユースケースではこれに遭遇していません。

古いデータがWebsphereアプリケーションサーバーから返される前に、このようなものを見た人はいますか？

ありがとう、

イアン。

mod_jk 構成で複数レベルのバランサ ツリーを構築することは可能ですか?

たとえば、次の構成があります

また、次の 2 つのマルチキャスト Tomcat クラスタ (t1、t2) および (t3、t4) があります。したがって、セッションは t1 と t2 の間、および t3 と t4 の間でのみ複製されます。

t1 が失敗した場合、mod_jk は要求を t2 に転送しますか? つまり、バランサーを尊重するのか、それとも左の tomcat ワーカーのいずれかにリクエストを送信するのでしょうか? これは重要です。クラスター間でセッションがレプリケートされず、1 つのワーカーが停止したクラスター内にアクティブなワーカーが存在する場合に要求を別のクラスターにリダイレクトすると、ユーザー セッション情報にアクセスできなくなるためです。