問題タブ [message-driven-bean]

私の質問は、jboss で構成された JMS データソースを使用するように EJB 3.0 スタイルのメッセージ駆動型 Bean を構成する方法です。

たとえば、私の MDB は次のようになります。

しかし、Bean を特定の JMS データソースにアタッチしたいと考えています (jboss 4.2.2 の場合、これは deploy/jms/jms-ds.xml にあります)。おそらくこれは不可能かもしれませんが、尋ねる価値があります。

だから、ここに私の問題があります:
私はメッセージ駆動型 Bean X を持っており、X の onMessage() メソッドで Logger を利用したいと考えています。アプリケーション サーバーで Bean のインスタンスが 1 つ実行されていると仮定します。したがって、ejbCreate() で log4j を初期化します。これは、次のようなことをしなければならないことを意味します。

ただし、これは役に立ちません。何をしても、ストリームは常に null として取得されます。他のバージョンを試しました: this.getClass().getStream() と ResourceBundle。

プロパティ ファイルを test.jar に jar し、それを EAR ライブラリ (RAD7 を使用しています) の下に追加すると、manifest.mf に反映されました。

以前にこの問題に直面した人はいますか? はいの場合、どのように解決しましたか？あなたの助けに感謝...

2 つのメッセージ駆動型 Bean があります。これらの Bean の 2 つのアクティベーション スペック。1 つのメッセージ バスがあり、両方のアクティベーション スペックがこの 1 つのバスに構成されています。2 つの異なるキューと、その 1 つのメッセージ バス用に構成された 1 つのキュー接続ファクトリがあります。

ここで、キューを決定した後、実行時にキューの 1 つにメッセージを送信するコードを記述します。ただし、両方の MDB が同じメッセージを受け取ります。この構成は一般的にどのように行われますか? 常に 1 つのキュー -> 1 つのキュー接続ファクトリー -> 1 つのメッセージ バス -> 1 つの MDB を構成する必要がありますか? それはすべて一対一の関係ですか？

言い忘れていましたが、私は Websphere Application Server v6.1 を使用しています。

MessageDrivenBean で接続タイムアウトまたはエラーを管理することは可能ですか?

ファクトリーに一定回数接続をリトライさせることはできますが・・・再接続のリトライが必要になるたびに何らかのアクションを起こすことはできますか？何らかの形で ExceptionListener を MessageDrivenBean の接続に登録することは可能ですか?

どうもありがとう。

MDB を使用した JMS のアプリケーションにファイルがejb-jar.xmlあります。jboss.xml

でキューの送信先を設定しましたdestination-service.xml。しかし、私の MDB は呼び出していません。

MDB を呼び出すように構成するサーバー ファイルはありますか?

アプリケーションのデプロイで次の問題が発生します。

サーバー間の通信にJMSとリモートopenMQを使用します。問題は、接続の信頼性が完全ではないため、接続が上下する可能性があることです。再接続するために、jms reconnect glassfishプロパティを設定して、ある時点で接続が失われた場合に再接続するようにしました。アプリケーションをデプロイしようとして接続がない場合に問題が発生します。接続を再試行し続けているように見えますが、接続が利用可能になるまでアプリケーションはデプロイメントを終了しません。

接続がなくても展開が続行され、接続が利用可能になるまで再試行を続けるように構成することは可能ですか？

どうもありがとう。

編集：別のスレッドでMDB初期化を実行しようとしています。私は両方を試しました

sun-ejb.jar.xmlを変更する2つの方法で、MDBに別のスレッドを割り当てようとしています。

そしてまた

しかし、私は運がなかった。新しいスレッドを取得しているように見えるため、このスレッドが終了するのを待っているように見えますが、そのスレッドが終了してアプリケーションの開始が完了するのを待っているため、私の場合、アプリケーションは正しくデプロイされません。

編集2別のスレッドでもjmsサービスを実行しようとしました...

運もありません。

強力なスケーラビリティが必要な Java EE プロジェクトを開始しています。これまでのコンセプトは次のとおりでした。

• アーキテクチャのさまざまな部分を担当するいくつかのメッセージ駆動型 Bean
• 各 MDB には、ビジネス ロジックを処理するセッション Bean が注入されています。
• 永続層へのアクセスを提供するエンティティ Bean のカップル
• JMS メッセージを介した要求/応答の概念による、アーキテクチャのさまざまな部分間の通信:
  • MDB がアクティビティ リクエストを含むメッセージを受信する
  • セッション Bean を使用して必要なビジネス ロジックを実行する
  • msg 内の応答オブジェクトを元のリクエスタに返します

アイデアは、メッセージ バスを介してアーキテクチャの部分を互いに分離することにより、スケーラビリティに制限がないというものでした。より多くのコンポーネントを開始するだけです。それらが同じバスに接続されている限り、どんどん成長していくことができます。

残念ながら、リクエストとリプライの概念に大きな問題があります。トランザクション管理は私たちの邪魔をしているようです。セッション Bean がメッセージを消費することになっていないと思われますか?!

http://blogs.oracle.com/fkieviet/entry/request_reply_from_an_ejbとhttp://forums.sun.com/message.jspa?messageID=10338789を読むと、人々が実際にリクエスト/リプライの概念に反対することを推奨しているように感じますEJB。

その場合、EJB 間でどのように通信しますか? （スケーラビリティは私が求めているものであることを忘れないでください）

現在のセットアップの詳細:

• MDB 1 'TestController'、ビジネス ロジックに (ローカル) SLSB 1 'TestService' を使用
• TestController.onMessage() は、TestService にキュー XYZ にメッセージを送信させ、応答を要求します。
  • TestService は Bean 管理のトランザクションを使用します
  • TestService は、初期化時にジョイント接続ファクトリを介して JMS ブローカへの接続とセッションを確立します (@PostConstruct)
  • TestService は送信後にトランザクションをコミットし、別のトランザクションを開始して応答を 10 秒間待機します。
• メッセージは、ビジネス ロジックに (ローカル) SLSB 2 'LocationService' を使用する MDB 2 'LocationController' に到達します。
• LocationController.onMessage() は、LocationServiceが要求された JMSReplyTo キューに メッセージを送り返すようにします。
  • 同じ BMT コンセプト、同じ @PostConstruct コンセプト
• すべてが同じ接続ファクトリーを使用してブローカーにアクセスします

問題: 最初のメッセージが (SLSB 1 によって) 送信され、(MDB 2 によって) 受信されます。返信メッセージの送信 (SLSB 2 による) も問題ありません。ただし、SLSB 1 は何も受信せず、タイムアウトするだけです。

messageSelector なしで試してみましたが、変更はありませんが、まだメッセージを受信して​​いません。

セッション Bean でメッセージを消費しても問題ないですか?

SLSB 1 - TestService.java

SLSB 2 - LocationService.Java (応答方法のみ、残りは上記と同じ)

sun-resources.xml

アプリケーションをJMSプロデューサーとコンシューマーでデプロイすると次のエラーが発生します

以下の注釈を使用しました。

Producer

次に、接続を作成して開始してから、メッセージを送信します

Consumer

実行時に max-pool-size の値を変更できるようにしたいと考えています。現在、xml を変更して Glassfish を再起動する必要があります。

何か案は？

ejb 3.1、サーブレット3.0（glassfishサーバーv3）を使用

シナリオ：jmsメッセージをリッスンし、他のセッションBean（ステートレス）に処理を提供するMDBがあります。jmsリソースを注入するServelet。

質問1：静的宣言を使用するときにサーブレットがjmsリソースを挿入できないのはなぜですか？

と

私が得るエラーは次のとおりです：

[＃| 2010-05-03T15：18：17.118 +0300|警告|glassfish3.0| javax.enterprise.system.container.web.com.sun.enterprise.web | _ThreadID = 35; _ThreadName = Thread-1; | StandardWrapperValve [WorkerServlet]：PWC1382：サーブレットWorkerServletの例外を割り当てますcom.sun.enterprise.container.common.spi.util.InjectionException：com.sunでクラスua.co.rufous.server.services.WorkerServiceImplの管理対象オブジェクトを作成中にエラーが発生しました。 company.container.common.impl.util.InjectionManagerImpl.createManagedObject（InjectionManagerImpl.java:312）at com.sun.enterprise.web.WebContainer.createServletInstance（WebContainer.java:709）atcom.sun.enterprise.web.WebModule。 createServletInstance（WebModule.java:1937）at org.apache.catalina.core.StandardWrapper.loadServlet（StandardWrapper.java:1252）原因：com.sun.enterprise.container.common.spi.util。InjectionException：未解決のMessage-Destination-Refua.co.rufous.server.services.WorkerServiceImpl/queue@java.lang.String@nullをcom.sunのクラスua.co.rufous.server.services.WorkerServiceImplに挿入しようとしたときに例外が発生しました.enterprise.container.common.impl.util.InjectionManagerImpl._inject（InjectionManagerImpl.java:614）at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.inject（InjectionManagerImpl.java:384）at com.sun .enterprise.container.common.impl.util.InjectionManagerImpl.injectInstance（InjectionManagerImpl.java:141）at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.injectInstance（InjectionManagerImpl.java:127）at com.sun .enterprise.container.common.impl.util.InjectionManagerImpl.createManagedObject（InjectionManagerImpl.java:306）... 27その他原因：com.sun.enterprise.container.common.spi.util.InjectionException：インスタンスベースのインジェクションのみをサポートするクラスでの静的フィールドprivate staticjavax.jms.Queueua.co.rufous.server.services.WorkerServiceImpl.queueの不正使用com.sun.enterprise.container.common.impl.util.InjectionManagerImpl._inject（InjectionManagerImpl.java:532）で... 31詳細|＃]

私のMDB：

静的宣言がなくてもすべてが正常に機能します。

質問2：MDBを操作するためのベストプラクティスは何ですか：onMessage（）で完全なリクエストを処理するか、onMessage（）メソッドで別のBean（私の場合はステートレスBean）を呼び出して処理します。ソープサービスへの呼び出しをほとんど含まない処理なので、完全な処理時間は3秒になる可能性があります。

ありがとうございました。