問題タブ [jboss-esb]

FUSE と Camel の新機能。

( https://github.com/jboss-fuse/quickstarts )から CBR プロジェクトをダウンロードし、スタンドアロンのラクダ プロジェクトとして実行できました。cbr.xml は次のとおりです。これにより、MSG が work/cbr/input ディレクトリから別のディレクトリにドロップされます。これを mvn camel:run として実行できます

しかし、ReadMe には、FUSE SEVER を起動して、スタンドアロンとして実行できるのに FUSE コンテナーが必要な理由を理解しようとしていると書かれています。

非同期にするためにクライアントからの Web サービス呼び出しが FUSE を通過するというプロジェクト要件があります。

この場合、ヒューズコンテナは必要ないと仮定します

時間を割いて読んでくれてありがとう

私たちのローカルネットワークには、一般的なWeb ブラウザ経由でアクセスできる既存のWeb IDE タイプのアプリケーションがあります。Jboss FUSE ESBを使用して、ローカルとクラウド/任意のネットワーク間のトンネルとして/機能させ たいと考えています。そのため、 Web ブラウザー client を介して、ブラウザーが存在するネットワークに関係なくアプリケーションに接続できます。ESBを介して要求応答を常にクライアント ブラウザーに送信します。

私はプロキシアプローチを使用しています:

• ブラウザに URL を入力すると、初回のみ ESB を使用するアプリケーションにリダイレクトされます。
• 次に、通常の方法でアプリケーションとの対話を開始します。ただし、ESB 経由ではありません。

これは JBOSS-FUSE-ESB で可能ですか、それともこのタスクには不適切なツールですか?

どんな提案でも大歓迎です。

新しいサービスを JBOSS SOA-P 5 にデプロイすると、次のエラーで停止します。

私はすでにこのトピックを読みました: jboss サーバーの起動中にエラーが発生しました。しかし、それは私をあまり助けませんでした。

完全なスタック トレース:

誰？

サービスを呼び出すと、次のようなエラーが発生しました。

このサービスは別のサービスを呼び出しています。Maven の依存関係を追加しました。

そして、この jar を開くと、StubExt クラスがはっきりと見えます。

何が間違っている可能性がありますか？

この問題は次のようなものです: https://developer.jboss.org/thread/232142

しかし、まったく答えはありません:(

私は、Bean がバインドされていないというエラーがあるいくつかのレガシー コードに取り組んでいます。これはよくあることのようですが、これまでのところ、オンラインで提供されているすべてのソリューションが機能していません (一般的に、データソースが正しく定義されているか、クラスの読み込みの問題が発生しているかを確認するため)。この問題は、Bean がバインドされる場合とバインドされない場合があるという事実によっても悪化します。

Bean はログにバインドされていると表示されます。

また、JNDI ツリーでバインドされているものとして表示され、名前はコードで使用されているものと一致します。

しかし、その後

コンポーネントのロード順序まで原因を追跡したと思います。デプロイが失敗すると、DEBUG ログに次のように表示されます。

デプロイが成功すると、DEBUG ログに次のように表示されます。

同じデータソースと永続化ユニットを共有する 2 つの個別の ESB があり、どちらもステートレス Bean を使用しています。

persistence.xml は両方で同じで、META-INF ディレクトリにあります。

データソース ファイルは次のとおりです。

永続ユニットが常に最初にロードされるように、ロードの順序を制御するにはどうすればよいですか? それとも、これは読み込み順序の問題ではなく、2 つの ESB が同じ永続化ユニットを共有していることが原因でしょうか?

アップデート

次の手順でエラーを再現できます。

• 両方の ESB をデプロイし、エラーはありません
• サーバーをシャットダウンし、常にOKをバインドするステートレスBeanを使用してESBを再デプロイすると、他のESBがエラーをスローします
• サーバーを再起動すると、すべて問題ありません

更新 2

ルート JNDI コンテキストのリストをログに記録すると、デプロイが成功すると、永続性ユニットが JNDI コンテキスト内で使用可能になることが示されます。

アップデート 3

修正ではなく回避策と思われる解決策があります。deployment.xmlパッケージの META-INF フォルダーに配置されたファイルに次のコードを追加することで、壊れていた ESB が動作している ESB に依存するように強制します (どちらも同じ永続化ユニットとデータソースを共有します) 。

したがって、作業中の ESB は常に最初にデプロイされます。つまり、持続性ユニットは JNDI コンテキスト内の他の ESB で利用できます。ただし、これは永続ユニットが最初にロードされる理由には答えません。パッケージングに関連している可能性があると思いました-壊れたESBはjboss-packaging-maven-pluginを使用しますが、動作するESBは使用しません。しかし、そのプロジェクトのソース コードを見ても、すぐに答えが得られるわけではありません。

JBOSS/Hibernate が ESB の前に永続ユニットをロードすることを意味する考えられる原因は何ですか?

注意:

• 両方の ESB は互いに独立して正常にデプロイされます
• ハイバネート コア 3.3.2.GA
• JBOSS SOA-P 5.3

CXF サービスを生成し、120000ms = 2min両方のタイムアウトを設定しました。

それは正常に動作しています。私はそれをテストしました20s, 1min, 3min-正確にその時間の応答を待っているたびに。

ただし、オンにしようとすると問題が発生し5minます。サービスは の応答のみを待ってい~240800ms = ~4minます。

jboss esb サービスを呼び出しています。これは最大持続し5minます。CXF サービスは.jar、PC から単純なアプリケーション内から呼び出されるため、間に他のサーバー/コンテナーはありません (Tomcat など)。

タイムアウト設定を修正するアイデアはありますか?

を使ってApache CXF 3.0.1

編集

2 つの異なるメッセージを受け取っていることに気付いたのは、タイムアウトの設定によって異なります。

• <=4min(my または @pedrofb メソッドを介して)に設定すると、その時間の後に次のようになります。

  org.apache.cxf.interceptor.Fault: メッセージを送信できませんでした。org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:64) で org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) で org.apache.cxf.endpoint.ClientImpl .doInvoke(ClientImpl.java:516)

  原因: java.net.SocketTimeoutException: SocketTimeoutException 呼び出しhttp://esb:8080/MyService/ebws/Category/MyService : 読み取りタイムアウト

• >4minまたはに設定すると0、次のようになります。

  javax.xml.ws.soap.SOAPFaultException: サービス [Category:MyService] に対する応答がありません。再試行しないように指示されました。

正直なところ、私は予想される結果が何であるかについてかなり混乱しています（最初の結果だと思います）

編集2

MyService経由でテストしSoapUIました。5minそこにタイムアウトを設定し、サンプルリクエストで撮影します。

繰り返しますが、4分少し経った後、次の結果が得られます。

ただし、Jboss ESB のログを調べると、例外もエラーもなく、MyServiceさらに 1 分 (約 5 分) 持続し、通常の応答を返します。これは、監査ツールによって確認されます (すべての要求を esb に登録します。応答と時間）。

@pedrofbがコメントで言及したことについて、この点が指摘されていると思います。これが何であるかについての提案はありますか？

JBossESB Programmer's manualでは、次のように言及されています。

「JBossESB 内のクライアントとサービス間のすべての対話は、メッセージの交換を通じて発生します。疎結合を促進するために、一方向メッセージに基づくメッセージ交換パターンをお勧めします。つまり、要求と応答は独立したメッセージであり、必要に応じてインフラストラクチャまたはアプリケーションによって関連付けられます。」</p>

しかし、要求と応答が一方向 MEP の独立したメッセージである場合、要求応答 MEP の違いは何ですか?

そして、それぞれを使用することの実際の利点は何ですか?