Composer での ThingWorx モデルの定義 > システム > サブシステム > 順序付けされたイベント処理サブシステム
順序付けされたイベント処理サブシステム
順序付けされたイベント処理サブシステムは、バインドやアンバインドなどのイベントを処理する際に適切な順序が維持されるために存在します。このサブシステムはスレッドプールへのファサードを提供し、イベント処理サブシステムなどと同様のチューニングパラメータを持ちます。現時点では、このプールはバインド/アンバインドイベントによってトリガーされる存在評価のみをサービスとして提供します。
システムに高い負荷がかかる場合、以下の表で説明する設定を使用してメモリフットプリントを制限します。これらの制限を超えた場合、デバイスの状態にかかわらず、Thing の isReportingfalse に変わります (詳細については以下の表を参照)。
設定
説明
イベントの処理プールに割り当てられた最小スレッド数
割り当てられるスレッドの最小数。この設定はスレッドプールの初期サイズでもあります。スレッドは、アイドル状態になると、リソースを維持するためにこの数まで減らされます。
イベントの処理プールに割り当てられた最大スレッド数
割り当てられるスレッドの最大数。負荷がかかるとプールは動的にこの数にサイズ変更されます。
新しい作業スレッドの追加前におけるキューの最大エントリ数
プールのサイズが変わる前にただちに処理可能なタスク (存在評価) の最大数。
適切な実行が保証される最大ブロックタスク数
キューに入って同じデバイスでの前の評価を待つことができるタスク (存在評価) の最大数。
最初の 3 つの設定はイベント処理サブシステムと完全に共有されることに注意してください。
このサブシステムでは、タスクがブロックされる可能性がある 2 つの異なる理由が区別されます。
すべての評価を発生と同時にリアルタイムで処理できる十分な Worker スレッドがない。"キューの最大エントリ数" の設定を使用して、この状況が発生する可能性を抑えることができます。
あるいは、同じデバイスが頻繁にオン/オフを繰り返し、評価を何度も行う必要がある。次のバインド/アンバインドイベントが発生する前に評価が終了しない場合、1 つ目の評価が終了するまで 2 つ目の評価が待つ必要があります。"最大ブロックタスク数" の設定を使用して、この方法で中止可能な評価の数を制御できます。
"キューの最大エントリ数" の上限を超えた場合、スレッドプールはサイズ変更を試みます。これに成功した場合、新しい Worker スレッドによって評価のキューが消費されます。
"最大スレッド" の上限が原因でサイズ変更できない場合や、"最大ブロックタスク数" の上限を超えた場合、スレッドプールは評価を却下します。却下された評価はただちに省略されて "レポートなし" になり、以降の処理は行われません。
高可用性コンテキストでは AlwaysON リクエストは接続サーバーによってラウンドロビン方式でルーティングされるので、高可用性環境では isReporting プロパティは予想どおりに動作しない可能性があります。したがって、その結果、BIND/UNBIND イベントは別のノードまたはキューによって実行されます。
これは役に立ちましたか?