（メモリ内の）セッションにStandardManagerを使用して、Tomcat5.5でベンダー提供のWebアプリを実行しています。セッションは非常に大きくなる可能性があるため（2,000万以上）、ヒープスペースの不足は深刻な懸念事項です。ユーザーは、可能であればセッションを数時間維持したいと考えていますが、ヒープスペースが不足するよりもセッションを排除したいと考えています。ベンダーがセッション化されたオブジェクトにSerializableを適切に実装したようには見えないため、永続的なセッションマネージャーの実装に切り替えることはできません。
Tomcatでは、マネージャーのセッションの総数を制限するmaxActiveSessionsプロパティを設定できます。ただし、その制限に達すると、既存のセッションの有効期限が切れるまで、新しいセッションを作成できません。最も最近使用されていないセッションを最初に壊したいと思います。
理想的には、ヒープ使用量が「Xmx」設定に近づいたときに、無条件に期限切れになるほど古くない場合でも、最近使用されていないセッションを期限切れにします。非常に古いTomcat開発者のメーリングリストスレッドは、これによりサービス拒否攻撃*が可能になる可能性があることを示唆していますが、このアプリケーションは企業ネットワーク内でのみ利用可能であるため、私たちは心配していません。
StandardManagerを拡張してprocessExpires（）をオーバーライドし、ヒープ使用量が最大値の85％を超える場合は、追加のセッションをクローバーすることを考えました。ただし、これは実際には少し問題があるようです。ヒープの多くが参照されておらず、ガベージコレクターが大量のオブジェクトを収集して（実行するのが面倒な場合）、ヒープを最大の50％に減らすことができる場合はどうなりますか？私は不必要にセッションを期限切れにするでしょう。積極的なガベージコレクション設定を使用すれば、このリスクを軽減できると思います。また、セッションを期限切れにすることでどれだけのメモリを節約したかをどのように知ることができますか？確実に知るには、GCサイクルを数回待つ必要があります。おそらく、保守的なアプローチを取り、メモリが許容可能なしきい値を下回るまで、バックグラウンドプロセスサイクルごとに最大Nセッションを削除することができます。
誰かがこの問題を解決しましたか？短期的な修正として、ヒープサイズを増やしていますが、そのバンドエイドにも欠点があります。
- 彼らは、ログイン前にセッションが作成される公開サイトを参照していました。誰かが多くの新しいセッションを作成させ、実際に使用されているセッションを混雑させる可能性があります。
更新：システムのアーキテクチャを実際に制御することはできません。特に、セッションの使用を減らすことはできません。ただし、コンテナは好きなだけ操作できます。ただし、Tomcatは、ベンダーがサポートしている唯一のオープンソースサーブレットコンテナです。