登録の段階で、ブローカーはどの資源 (この場合はノード) が 使用可能で、どの lil がそれらを供給できるかを発見します。この段階は実行グループが開始する際に 始まります。lil は実行グループの始動にロードされ、ブローカーはそれらに照会してどのリソースを lil が 供給できるかを検出します。
登録段階で、ユーザー定義のノードが cniCreateNodeFactory を呼び出すときに、CciFactory 構造が 作成されます。
ユーザー定義の入力ノードのインスタンスは、mqsistart コマンドが実行グループ処理を開始 または再開する場合、またはノードに関連するメッセージ・フローがデプロイされる場合に作成されます。
この段階中に CciTerminal 構造が作成されます。この作成は cniCreateTerminal が呼び出されるときに 作成されます。
処理段階は、cniRun 関数がブローカーによって呼び出される際に開始します。 ブローカーは cniRun 関数を使用して、メッセージが定義される ドメインの決定、およびそのドメインへの関連パーサーの呼び出しを含む、メッセージの処理方法を 決定します。
スレッドが、メッセージ・フローのスレッド・プールから要求され、入力ノードの run メソッドで開始されます。 スレッドはブローカーのキュー・マネージャーに接続し、その存続期間中この接続を維持します。 スレッドが割り振られると、ノードがメッセージ処理ループに入り、メッセージの受信を待ちます。 これはメッセージが受信されるまで再試行されます。 メッセージ・フローが複数のスレッドを使用するように構成されている場合、 スレッド・ディスパッチングが活動化されます。
これで、メッセージ・データのダウンストリームへの伝搬が可能になります。
ユーザー定義の入力ノードは、メッセージ・フローの再デプロイ時、 または mqsistop が実行グループ処理の停止に使用される場合に破棄されます。 cniDeleteNodeContext 関数をインプリメントすることによって、 ノードを破棄できます。
ユーザー定義の入力ノードがこれらの方法のいずれかで破棄される場合、 ノードが使用するメモリーを解放し、ソケットなど保留されていたリソースをリリースする 必要があります。
登録の段階で、 Java で作成されたユーザー定義の Input ノードはブローカーに自分の存在を知らせます。 ノードは静的 getNodeName メソッドによってブローカーに登録されます。 ブローカーが開始するたびに、関連するすべての java クラスがロードされます。 この時点で静的メソッド getNodeName が呼び出され、 ブローカーは入力ノードを getNodeName で指定したノード名で登録します。 ノード名を指定しない場合、 ブローカーはそれが含まれているパッケージに基づいてノードに対して自動的に名前を作成します。
ここで静的メソッドを使うということは、 ノード自体がインスタンス化される前にブローカーでメソッドを呼び出せるということを意味します。
Java のユーザー定義入力ノードは、 ブローカーがユーザー定義の入力ノードを含むメッセージ・フローをデプロイするときにインスタンス化されます。 ノードがインスタンス化されるときは、 入力ノードのクラスのコンストラクターが呼び出されます。
ノードがインスタンス化されると、 関連メソッドを使って指定したすべてのターミナルが作成されます。 Input ノードに入力ターミナルを関連付けることはできませんが、 出力ノードはいくつでも持つことができます。 出力ターミナルには、out ターミナル、failure ターミナル、 および catch ターミナルが含まれます。 ノード・クラス・コンストラクター内の createOutputTerminal メソッドを使用して、 必要数の出力ターミナルを作成できます。
入力ノードに再び渡された例外を処理する場合は、 createOutputTerminal を使用して入力ノードの catch ターミナルを作成します。 入力ノードがエラーをキャッチすると、 catch ターミナルは通常の MQInput ノードが行うのと同じ方法でそのエラーを処理します。 デプロイメントの問題が原因である例外など、ほとんどの例外がブローカーに戻される のを許可できますが、ブローカーは可能な構成エラーがあればユーザーに警告します。
最小限として、コンストラクター・クラスは、これらの出力ターミナルを入力ノードに作成する必要があります。 ただし、たとえば入力ノードから渡されるメッセージを最初に構文解析するパーサーの定義など、 属性値を初期化する必要がある場合、そのコードをこの時点で入力ノードに組み込む必要もあります。
入力ノードのメッセージの処理は、 ブローカーが run メソッドを呼び出したときに開始します。 run メソッドが入力メッセージを作成し、メソッドは入力ノードの処理関数を含むはずです。
run メソッドは MbInputNodeInterface で定義されます。 これは、ユーザー定義入力ノードで使用され、それを入力ノードとして定義するインターフェースです。 ノードには run メソッドを含めなければなりません。run メソッドをユーザー定義の入力ノード に含めないと、ノード・ソース・コードはコンパイルしません。
ユーザー定義入力ノードが含まれたメッセージ・フローが正常にデプロイされていれば、 ブローカーはこのノードの run インプリメンテーション・メソッドを呼び出し、 メッセージの処理を待つ間、このメソッドを呼び出し続けます。
メッセージ・フローが開始する際には、ブローカーによって単一スレッドがディスパッチされ、 入力ノードの run メソッドに呼び出されます。dispatchThread メソッドが呼び出されると、 同じ run メソッドでさらにスレッドを作成することができます。これらの新規のスレッドは、 即時に入力ノードの run メソッドへ呼び出され、元のスレッドと同様に扱うことができます。 作成できる新規のスレッドの数は、additionalInstances 属性で 定義されています。メッセージが作成された後、それが伝搬される前に、スレッドがディスパッチ されるようにしてください。これにより、一度に 1 つのスレッドのみが新規のメッセージを待つことが確実になります。
ユーザー定義入力ノードを使ってメッセージ・フローをデプロイするユーザーは、 複数のスレッドを使うことによりメッセージ・フローにサービスを提供するよう指定することができます。 入力ノードには選択されたスレッド化モデルのインプリメントを行うという責任がありますが、 コードでこの機能に制限を設けることはできません。 その代わり、コードを完全に再入可能とし、 コードが呼び出す機能もまた完全に再入可能としなければなりません。
ユーザー定義の入力ノードのスレッド化モデルについて詳細は、スレッド化を参照してください。
Java ユーザー定義入力ノードは、 ノードが削除されるか、またはブローカーがシャットダウンされると破棄されます。 ガーベッジ・コレクターによって処理できるので、 ノードの物理的な削除の指定をコードに組み込む必要はありません。
ただし、ノードの削除に関して通知が必要な場合は、onDelete メソッドを使用できます。 削除したい、ガーベッジ・コレクションが実行されるこれ以外のリソースがある場合にも、 これを使用することができます。 たとえば、ソケットをオープンした場合、 ノードが自動的に削除されるとこのソケットは正しくクローズされません。 この指示を onDelete メソッドに組み込んで、 ソケットを正しくクローズすることができます。
注意 |
商標 |
ダウンロード |
ライブラリー |
技術サポート |
フィードバック
![]() ![]() |
as01391_ |