2

ワークフローを実装するために、Servicemix 3.3.2 内で apache ode 1.3.3 を使用します。負荷が増加すると (つまり、単位時間あたりのフロー呼び出しの数)、ode はフリーズし、新しい要求の処理を停止してハングします。通常、「データ」フォルダーのクリーンアップ後に Servicemix を再起動することで問題を解決します。

最初は、これはスレッドの問題 (ode が使用するスレッドの不足) だと思っていました。ode-jbi.properties の「スレッド プール サイズ」を増やした後、この問題は解決されました。それでも、重い負荷がかかると、ode はハングアップし続けます。

追加のログを使用してさらに調査すると、負荷が高い状態では、ode が DB への十分な接続を取得できず ( NoManagedConnectionException )、その状態を維持できないことが明らかになりました。私たちの ode 永続化構成は INTERNAL ( ode-jbi.db.mode=INTERNAL を参照) であり、接続プールはコンテナー/ランタイム自体によって維持されます。それを EXTERNAL jndi データソース構成 (接続プールのパラメーターを構成できる場所) に移行する努力は、まだ成果を上げていません (各段階で発生し続ける無数のエラーを理解できなかったおかげです :( :) )

そこで、プロセスの「インメモリ実行」という他の利用可能なオプションを試しました。これは「テスト セットアップ」で正常に機能し、シミュレートされた負荷の下で「NoManageConnectionException」をスローしなくなりました。

しかし、これを PROD に移行することについていくつか懸念があります。インメモリ実行と「永続化」実行の違いは何ですか? これにより、どれだけ多くのメモリが消費されますか? これにより、'OutOfMemoryOutages' が発生して、PROD セットアップの信頼性に影響しますか?

デプロイされた約 10 の bpel プロセスがあります。そして、負荷（リクエスト数）...通常は最小限ですが、時々急増します（ここで、プロセスを非常に高速に実行する必要がありますが、OutOfMemory PRODの停止を引き起こすことなく...うまくいけば:D :) :P )

これに関するあなたの考え、提案、アドバイスが必要です。

前もってありがとう、アルン

4

1 に答える 1

1

答えは少し遅れていますが、まだ関連性があり、将来誰かに役立つことを願っています.

外部 DB 構成に関して、このリンクでは、Bitronix TM を Tomcat と組み合わせて使用​​する方法について説明しています。はい、それはTomcatに固有のものですが、他のアプリケーションサーバーでは、管理されたデータソースを指定する他の方法があります. Apache ODE の参照がweb.xmlおよびode-axis2.propertiesファイルに適切に設定されていることを確認してください。これにより、外部データベースを使用できるようになります。

高負荷でプロセスをメモリ内で実行すると、ConcurrentModificationException. この JIRAは問題を参照しており、修正バージョンは 1.4 に設定されています。

したがって、インメモリ実行が安定しているかどうかに関係なく、答えは NO だと思います。現在、高負荷時に現れるバグが存在するためです。

また、外部 DB 結合も可能です。外部 DB を使用して CME もスローされるかどうかを明日テストします。

編集：

ConcurrentModificationException外部 DB (コンテナ管理) に接続したときは見たことがありませんが、パッチ適用可能なこの JIRAの症状に出くわしましたが、問題にはフィードバックが提供されておらず、現在ソースをビルドできません。

編集：

メモリ内で実行される BPEL プロセスは、ここで説明されているように、同期 (1 つの受信アクションを持つ) に制限されます。これは、実際には、このまったく同じ質問に対する ODE 開発者による回答です... :)

したがって、BPEL プロセスのインメモリ実行は、同期している限り安定しています。

于 2014-01-16T16:22:26.663 に答える