ユーザー定義の入力ノードのライフ・サイクル

このトピックは、C プログラム言語か Java プログラム言語のいずれかを使って作成されるユーザー定義の入力ノードの存続期間におけるさまざまな段階を説明します。 入力ノードのライフ・サイクルにおける以下の段階について説明します。

C 入力ノードのライフ・サイクル

登録

登録の段階で、ブローカーはどの資源 (この場合はノード) が 使用可能で、どの lil がそれらを供給できるかを発見します。この段階は実行グループが開始する際に 始まります。lil は実行グループの始動にロードされ、ブローカーはそれらに照会してどのリソースを lil が 供給できるかを検出します。

登録段階で、ユーザー定義のノードが cniCreateNodeFactory を呼び出すときに、CciFactory 構造が 作成されます。

この段階中にブローカーが呼び出す API:
  • biGetMessageflowNodeFactory
  • bipGetParserFactory
この段階中にユーザー定義のノードが呼び出す API:
  • cniCreateNodeFactory

インスタンス化

ユーザー定義の入力ノードのインスタンスは、mqsistart コマンドが実行グループ処理を開始 または再開する場合、またはノードに関連するメッセージ・フローがデプロイされる場合に作成されます。

次の API がこの段階中に呼び出されます。
  • cniCreateNodeContext。この API は、ユーザー定義のノードの インスタンス化用にメモリーを割り振り、構成された属性の値を保留します。 この API はユーザー定義の入力ノードを使用している各メッセージ・フローごとに一度呼び出されます。
  • cniCreateInputTerminal。この API は cniCreateNodeContext API 内で呼び出され、ユーザー定義の入力ノードが持つ入力ターミナルがあればそれを ブローカーに通知するために使用されます。
    注: ユーザー定義の入力ノードは、 メッセージ処理ノードとしても使用されている場合にのみ、入力ターミナルを持ちます。そうである場合、 両方の操作を 1 つのより複雑なノードに結合するよりも、 別のユーザー定義のメッセージ処理ノードを使用してメッセージ処理を行う方が通常は望ましい方法です。
  • cniCreateOutputTerminal。この API は cniCreateNodeContext API 内で呼び出され、ユーザー定義の入力ノードが持つ出力ターミナルを ブローカーに通知するために使用されます。
  • cniSetAttribute。この API は、ユーザー定義のノードの 構成済み属性に値を確立するためにブローカーによって呼び出されます。

この段階中に CciTerminal 構造が作成されます。この作成は cniCreateTerminal が呼び出されるときに 作成されます。

処理

処理段階は、cniRun 関数がブローカーによって呼び出される際に開始します。 ブローカーは cniRun 関数を使用して、メッセージが定義される ドメインの決定、およびそのドメインへの関連パーサーの呼び出しを含む、メッセージの処理方法を 決定します。

スレッドが、メッセージ・フローのスレッド・プールから要求され、入力ノードの run メソッドで開始されます。 スレッドはブローカーのキュー・マネージャーに接続し、その存続期間中この接続を維持します。 スレッドが割り振られると、ノードがメッセージ処理ループに入り、メッセージの受信を待ちます。 これはメッセージが受信されるまで再試行されます。 メッセージ・フローが複数のスレッドを使用するように構成されている場合、 スレッド・ディスパッチングが活動化されます。

これで、メッセージ・データのダウンストリームへの伝搬が可能になります。

次の API が、ブローカーによってこの段階中に呼び出されます。
  • cniRun。この関数は、 メッセージを処理する方法を判別するためブローカーによって呼び出されます。
  • cniSetInputBuffer。この関数は入力バッファーを提供するか、入力バッファーの位置をブローカーに通知し、 そのバッファーをメッセージ・オブジェクトに関連付けます。

破棄

ユーザー定義の入力ノードは、メッセージ・フローの再デプロイ時、 または mqsistop が実行グループ処理の停止に使用される場合に破棄されます。 cniDeleteNodeContext 関数をインプリメントすることによって、 ノードを破棄できます。

ユーザー定義の入力ノードがこれらの方法のいずれかで破棄される場合、 ノードが使用するメモリーを解放し、ソケットなど保留されていたリソースをリリースする 必要があります。

次の API が、ブローカーによってこの段階中に呼び出されます。
  • cniDeleteNodeContext。この関数は、 入力ノードのインスタンスを破棄するためにブローカーによって呼び出されます。

Java 入力ノードのライフ・サイクル

登録

登録の段階で、 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 メソッドに組み込んで、 ソケットを正しくクローズすることができます。

関連概念
ユーザー定義のパーサー
ユーザー定義拡張機能

関連タスク
Java での入力ノードの作成
C での入力ノードの作成

関連資料
cniCreateInputTerminal
cniCreateNodeContext
cniCreateNodeFactory
cniRun
cniSetInputBuffer