0

Mule 3.3 CE について:

非同期の「一方向」交換パターンがありますが、実際の応答の前に「空の」メッセージで発信者に 2 回応答します。すると、3 つの応答が得られます。最初の 2 つは空の「がらくた」であり、実際の応答が返されます。

最初の 2 つの「空の」応答を無効にして、実際の応答を返信すべき場所に戻すことはできますか? 呼び出し元は、フローからの応答用に TEMP キューを設定します。(現在、その応答キューで 3 つの応答を取得します。)

ActiveMQ の動作を変更する必要がありますか? 今のところデフォルトです。

<jms:activemq-connector name="Active_MQ_Staging" brokerURL="tcp://xxx.xxx.xxx.x:yyyy" validateConnections="true" maxRedelivery="2" doc:name="Active MQ" forceJndiDestinations="true" honorQosHeaders="true" specification="1.1" disableTemporaryReplyToDestinations="true"/>
<flow name="MyFlow2" doc:name="MyFlow2">
    <jms:inbound-endpoint queue="myQueue" connector-ref="Active_MQ_Staging" doc:name="JMS" exchange-pattern="one-way"/>
                <all doc:name="All">
                    <processor-chain>
                        <jms:outbound-endpoint queue="${queue.mule.levinforequest}" disableTemporaryReplyToDestinations="true" connector-ref="Active_MQ_Staging" doc:name="JMS"/>
                    </processor-chain>
                    <processor-chain>
                        <logger message="Leaving AppFacade" level="INFO" doc:name="Logger"/>
                    </processor-chain>
                </all>
....

編集:わかりました、上記のステートメントにすべてを投稿していません。

これが私たちがやりたいことです: Mule-app は JMS メッセージを受け取ります。送信者 (私が正しければステートレス EJB MDB) は、私が持ち歩く必要があるいくつかのプロパティを設定し、さらにいくつかのプロパティを追加します。送信者は、応答用に設定された一時キューの名前を教えてくれます (ミュール アプリ (別のフローで) は、他のいくつかの手順と他の統合の後に応答します)。この最初のミュール フローは、応答させたくないため、「一方向」としてセットアップしました。

この最初のフローは、メッセージを別の JMS キューに入れます。次に、別の Mule-app (および muleflow) がメッセージを (一方向でも) 受信し、それを別の形式に変換して、別のキューに入れます。これは意味をなさないかもしれませんが、私たちの環境ではそうです。;-) 次に、「サードパーティ」からの応答を受信した後、2 番目の Mule-app が応答を受信し、JMS メッセージを独自の形式に変換します (プロパティはまだ保持されています)。次に、最初の Mule-app (および 2 番目のフロー) (または他のユーザー) がメッセージを取得できるトピックに送信します。いいえ、発信者に応答したいと思います。誰がリクエストを送信し、どのキューにレスポンスを送信するかについてのプロパティがあります。したがって、4 つのミュール フロー (2 つの異なるミュール アプリ内) はすべて「一方向」として設定されます。

したがって、実際のフローは、フロー 1 からフロー 3、外部パーティへと進み、フロー 4 で応答を取得してから、フロー 2 から発信者に戻ります。

つまり、Flow1->Flow3->Flow4->Flow2

Mule-app1:

Flow1: 発信者 -> キュー -> MuleFlow (一方向) -> キュー

Flow2: トピック -> MuleFlow (一方向) -> 一時キューへの応答

Mule-App2

フロー 3: キュー -> Muleflow (一方向) -> 変換 -> キュー -> 外部パーツ

Flow4: 外部パーツ -> キュー -> MuleFlow(一方向) -> 変換 -> トピック

これについてフォローしていただければ幸いです。

Mule Studio がそれらの「プロセッサ チェーン」を配置したと思います。そして、ロギングは単なる「ロギング」です。Flow1の退会時期などを知りたい。ログ/デバッグ専用。

この度はご検討いただきありがとうございます。

/Z

4

1 に答える 1

0

私はあなたがここで何をしているのか完全には理解していません。

ロガーはメッセージから何も記録していません。すべてを使用する必要はないと思います。次のようにできます。

<jms:outbound-endpoint queue="${queue.mule.levinforequest}" disableTemporaryReplyToDestinations="true" connector-ref="Active_MQ_Staging" doc:name="JMS"/>
<logger message="Leaving AppFacade" level="INFO" doc:name="Logger"/>

バグを引き起こしている可能性があるプロセッサチェーンの必要性もわかりません。それらを使用しないようにしてください。

私がそれを間違っていないと理解したとしても、Ricston モジュールのignore-reply-allが役に立ちます。

于 2013-02-05T12:27:38.100 に答える