問題タブ [websphere]

JSF がセッションをいっぱいにする問題が発生しています。先日システムクラッシュがありました。レビューのためにヒープを IBM に送信したところ、50M ものセッションがあったことがわかりました。彼らは、セッション内に JSF コンポーネントと非常に大きなものを見つけました。

それで、実行できるチューニングはありますか？設定項目は? または他の方向。

私たちのシステムは、プレゼンテーション層に JSF と Spring を使用して構築されており、バックエンドは EJB、Spring、および Hibernate であり、すべて WebSphere 6.1 で実行されています。

私は Websphere ポータル 6.0 を使用していますが、doView メソッドからレンダリングするページをサーバーに伝える方法があるかどうか疑問に思っています。processAction メソッドから実行できることはわかっていますが、残念ながら問題のセマンティクスでは許可されていません。

ご協力ありがとうございました

Websphere (5.1) のみを使用して外部 JavaScript ファイルに文字エンコーディングを設定するにはどうすればよいですか? その前にApacheがないので、「AddCharset UTF-8 .js」を使用して設定できません。

それとも、web.xml または同様の魔法を介して Web コンテナーに強制する他の方法があるのでしょうか?

ServletOutputStreamIBM Websphere Application Server v6 と Java 1.4 を使用しており、ユーザーがダウンロードできるように大きな CSV ファイルを に書き込もうとしています。現在、ファイルのサイズは 50 ～ 750 MB です。

小さいファイルはそれほど大きな問題を引き起こしていませんが、大きいファイルではヒープに書き込まれているように見え、それが OutOfMemory エラーを引き起こし、サーバー全体をダウンさせています。

これらのファイルは、HTTPS 経由で認証されたユーザーにのみ提供できます。そのため、Apache に貼り付けるのではなく、サーブレットを介して提供しています。

私が使用しているコードは次のとおりです（これに関するいくつかの綿毛が削除されました）：

別のFileInputStreamファイルに書き込むか、書き込みを完全に削除するかのように問題を引き起こしているようには見えませんが、メモリ使用量は問題ではないようです。

私が考えているのresp.getOutputStream().writeは、データがクライアントに送信されるまでメモリに保存されているということです。そのため、ファイル全体が読み取られて保存されresp.getOutputStream()、メモリの問題やクラッシュが発生する可能性があります。

私はこれらのストリームをバッファリングしようとしましたが、 からjava.nioのチャネルを使用しようとしましたが、メモリの問題に少しの違いもないようです。OutputStreamまた、ループの反復ごとに 1 回とループの後にフラッシュしましたが、これは役に立ちませんでした。

クラスローダーの問題と、wsdl4j との特定の非互換性のために、WAS 6.1 への展開に失敗する war ファイル (実際には私自身のものではありません。Apache ODE 1.2 です) があります。ODE のクラスローダーを手動で編集し、wsdl4j1.6.1 の共有ライブラリを作成すると、問題ありません。

しかし、クライアントは、これは受け入れられず、手動の手順を必要としない自己完結型のインストールである耳を提供する必要があると述べてきました.

war をバンドルする ear ファイルをビルドすることができましたが、ear 内に共有ライブラリを含める方法に関する関連情報を見つけることができず、それをクラスローダーの開始時に使用しました (優先する必要がありますWAS にバンドルされている wsdl4j)。ear ファイル構造を変更する必要がありますか? それともapplication.xmlですか？

誰でも助けを提供できますか？ご想像のとおり、私は「Tomcat には war ファイルが必要」というバックグラウンドから来ており、ear ファイルを理解するのに苦労しています。

私のapplication.xmlには次のものが含まれています：http://java.sun.com/xml/ns/j2ee/application_1_4.xsd"> XXX ODE ode.war odeなど

あるアプリケーションから別のアプリケーションへの移動/トラバースを伴うタスクに取り組んでいます。アプリケーションは別々の JVM にあります。

他のアプリケーションに移動する間、セッション ID を追跡します。ただし、前後にトラバースすると、新しいセッションが作成されます。子アプリケーションから親アプリケーションに戻るときに、保持している sessionId を使用して同じセッションに戻る方法はありますか?

環境: J2EE と WebSphere。

IBM JDK 1.4.2 を使用する AIX 上の Websphere Portal Server 5.1 で、かなり複雑なアプリをポートレットとして実行しています。私たちの実稼働システムでは、詳細な GC ログに奇妙な動作が見られます。通常の動作の期間の後、システムは急速に大きなブロックの割り当てを開始できます。システムは、各 GC を完了するために 1000 ミリ秒を超える時間を費やし始めますが、ブロックが非常に迅速に割り当てられるため、割り当ての失敗の間に 30 ミリ秒のギャップしかありません。

• 各割り当ての失敗は、前回よりわずかに整数 x 1024 バイトだけ大きくなります。たとえば、5 MB があり、しばらくすると 5 MB + 17 * 1024 になる場合があります。
• これは最大 10 分間続くことがあります。
• ブロックは、停止する前に最大 8 ～ 14 MB のサイズになる傾向があります。
• これはクアッドコア システムであり、もう一方のコアが GC を完了するのを待っている 3 つのコアで GC を実行する時間の 95% 以上を費やしていると思います。10分間。ああ。
• 明らかに、この時点でシステムのパフォーマンスは低下します。
• JSF、休止状態と JDBC、Web サービス呼び出し、log4j 出力などがあります。

これは、アプリケーション コードではなく、インフラストラクチャのようなものである可能性が高いと解釈しています。ループ内の不適切な文字列連結である場合、1024 のブロックよりも不規則な増加が予想されます。StringBuffer または ArrayList の増加である場合、ブロック サイズが 2 倍になることがわかります。成長により、ログのバッファリングなどを考えさせられます。私たちのアプリでは、14 MB どころか 1 MB を割り当てるものも思い浮かびません。今日、ディスクにフラッシュされる前にメモリにログを記録する方法を探しましたが、この GC スラッシング期間のログ ステートメントの量はどこにもありませんでした。 MB範囲。

明らかに問題は、ガベージ コレクションではなく過剰なメモリ割り当てにあり、ガベージ コレクションは追いつくために最善を尽くしています。何かが大きなブロックを割り当て、それを非常に小さい増分で非効率的に拡張しようとしています。

システムに負荷がかかっているときに、これらすべてを引き起こしている可能性のあるアイデアはありますか? Portal Server で似たようなものを見た人はいますか?

注: 興味のある人にとっては、原因は時折ではあるが巨大なデータベース クエリにあるように見え始めています。原因は、Hibernate または JDBC ドライバーのいずれかにあるようです。

並列化が必要な Websphere Java EE アプリケーションがあり、CommonJ 作業コンポーネントの使用を検討しています。

各「スレッド」には、データベースからのデータに対する独自のビューが必要です。このほとんどはプリフェッチされますが、一部を取得するにはデータベースにアクセスする必要があります。これらすべてのスレッドの全体的な作業の期間は「長い」(つまり、基礎となるデータが変更されるのに十分な時間) と予想されます。

その結果、アプリケーションによって使用され、スレッドの作業中にクエリされるデータを確実に分離する必要があります。

これを確実にする唯一の方法は、「グローバル」トランザクションを持ち、XA トランザクションを使用することのようです。しかし、可能な限りこの複雑さ (およびオーバーヘッド) を回避したいと考えており、アイデアや代替案を探しています。何か考えはありますか?

また、Common-J Work Components はコンテナ管理のトランザクションをどの程度サポートしていますか?

@Karl：おそらくオーバーヘッドを意味していたのでしょう。私たちの考えでは、XA トランザクションとメッセージングは​​、トランザクションを共有する Common-J 作業コンポーネントが回避できるオーバーヘッドを発生させるのでしょうか? 操作対象のデータセットは、30 万行を超える個別のデータ行であり、それぞれに対して約 100 の計算を行う必要があります。これらは、共有されたキャッシュされた読み取り専用データで動作するさまざまなスレッドに分割できますが、キューへのコピー/キューからの読み取りの比較メモリオーバーヘッドは法外に思えます. 同意しますか？

@Karl: エンティティごとに数十から数百ミリ秒。別のタスクとして、ロジック処理の改善にも力を入れています。
すべてのスレッドが 1 つのデータベース内の一貫したデータ ビューを持つ必要がある場合、XA トランザクションを使用する必要がありますか? これに対する私の答えは、各スレッドには独自の JPA EntityManager (接続など) が必要であり、アクセスを調整するために XA が必要であるということです。
しかし、XAなしでこれを行うことができれば、はるかに良いのではないでしょうか?

Windows オペレーティング システム上の IBM Websphere Application Server で J2EE アプリケーションを実行しています。

時折、javacore ファイルに次の情報を含む OutOfMemoryError Exception が表示されます。

Java は次の構成で実行されます。 -Xms512m -Xmx1350m -Xscmx50M

javacore ファイルを分析すると、スレッド数はわずか 124 です。ヒープ ダンプを分析すると、ヒープが占有するメモリは約 500Mb です。

比較的正常なスレッド数とヒープ サイズが最大値よりかなり小さい場合、このエラーが表示される理由を突き止めようとしています。

これが役立つかどうかはわかりませんが、ここに javacore ファイルの先頭セクションがあります...