| Oracle® Fusion Middleware Oracle Coherenceでのアプリケーションの開発 12c (12.1.3) E56206-04 |
|
 前 |
 次 |
この章では、デッドロックされたサービス・スレッドを検出および解決するためのサービス・ガーディアンの使用方法および構成方法、さらにカスタムの失敗ポリシーの実装方法について説明します。
この章には次の項が含まれます:
サービス・ガーディアンは、Coherenceのスレッドでデッドロックを検出して解決しようとするメカニズムです。あるメンバー上のデッドロックされたスレッドは、クラスタに新しいノードを追加できない、クラスタに現在含まれるノードからのリクエストに対応できないなど、クラスタの他の部分に明らかな望ましくない多くの動作を引き起こす可能性があります。
サービス・ガーディアンは、Coherenceで所有され、作成されたスレッドが発行する定期的なハートビートを受け取ります。構成されているタイムアウトより前にスレッドからハートビートを発行できなくなると、サービス・ガーディアンによって修正処置が実行されます。タイムアウトと修正処置(リカバリ)は両方とも必要に応じて構成できます。
|
注意: デッドロックという用語が必ずしも意味どおりのデッドロックを表すわけではありません。適時にハートビートを発行しないスレッドが、長い実行プロセスを実行していたり、遅いリソースを待機していたりする可能性があります。サービス・ガーディアンでは、デッドロックされたスレッドと遅いスレッドを区別することはできません。 |
Coherenceによって実行されるインタフェース
次のインタフェースの実装が、Coherence所有のスレッドによって実行されます。実装のプロセスが、構成されているガーディアン・タイムアウトを超えると、サービス・ガーディアンはスレッドをリカバリしようとします。リストは包括的ではなく、エンド・ユーザーによって実装される最も一般的なインタフェースのみを示しています。
com.tangosol.net.Invocablecom.tangosol.net.cache.CacheStorecom.tangosol.util.Filtercom.tangosol.util.InvocableMap.EntryAggregatorcom.tangosol.util.InvocableMap.EntryProcessorcom.tangosol.util.MapListenercom.tangosol.util.MapTrigger
リカバリの理解
サービス・ガーディアンのリカバリ・メカニズムでは、スレッドがデッドロックされているかどうかを判断するために一連の手順が使用されます。修正処置は、スレッドがデッドロックされているとサービス・ガーディアンが結論付けた場合に実行されます。実行する修正処置は構成可能であり、必要に応じてカスタムの処置を作成できます。次に、リカバリ・メカニズムの概要を示します。
ソフト・タイムアウト - このリカバリ・メカニズムではまず、構成されているタイムアウトに達する直前にスレッドを中断しようとします。次のログ・メッセージの例は、ソフト・タイムアウト・メッセージを示しています。
<Error> (thread=DistributedCache, member=1): Attempting recovery (due to soft
timeout) of Daemon{Thread="Thread[WriteBehindThread:CacheStoreWrapper(com.
tangosol.examples.rwbm.TimeoutTest),5,WriteBehindThread:CacheStoreWrapper(com.
tangosol.examples.rwbm.TimeoutTest)]", State=Running}
スレッドを中断でき、その結果ハートビートが発行されると、通常の処理が再開します。
ハード・タイムアウト - このリカバリ・メカニズムでは、構成されているタイムアウトに達するとスレッドを停止しようとします。次のログ・メッセージの例は、ハード・タイムアウト・メッセージを示しています。
<Error> (thread=DistributedCache, member=1): Terminating guarded execution (due
to hard timeout) of Daemon{Thread="Thread[WriteBehindThread:CacheStoreWrapper
(com.tangosol.examples.rwbm.TimeoutTest),5,WriteBehindThread:CacheStoreWrapper
(com.tangosol.examples.rwbm.TimeoutTest)]", State=Running}
最後に、スレッドを停止できない場合、リカバリ・メカニズムでは、構成されている失敗ポリシーに基づいて処理が実行されます。実行可能な処理には、クラスタ・サービスの停止、JVMの停止、カスタム処理の実行などがあります。次のログ・メッセージの例は、リカバリ・メカニズムで実行される処理を示しています。
<Error> (thread=Termination Thread, member=1): Write-behind thread timed out; stopping the cache service
サービス・ガーディアンは、初期状態で有効になっており、タイムアウト値と失敗ポリシーの2つの項目が構成されています。タイムアウト値は、サービス・ガーディアンがリカバリを開始する前にスレッドからのハートビートの受取りを待機する時間です。失敗ポリシーは、スレッドがデッドロックされているとサービス・ガーディアンが結論付けた後に実行される修正処置です。
サービス・ガーディアン・タイムアウトは、必要な粒度レベルに基づいて3種類の方法で設定できます。
すべてのスレッド - このオプションでは、1つのタイムアウト値をクラスタ・ノード上のCoherence所有のスレッドすべてに適用できます。これはデフォルトの構成で、デフォルトで305000ミリ秒に設定されています。
サービス・タイプごとのスレッド - このオプションでは、サービス・タイプごとに異なるタイムアウト値を設定できます。タイムアウト値は、すべてのサービス・インスタンスのスレッドに適用されます。特定のサービス・タイプにタイムアウトが指定されていないと、そのタイムアウトはすべてのスレッドに設定されているデフォルトのタイムアウトに設定されます。
サービス・インスタンスごとのスレッド - このオプションでは、サービス・インスタンスごとに異なるタイムアウト値を設定できます。特定のサービス・インスタンスにタイムアウトが設定されていないと、そのサービスのタイムアウト値が指定されている場合はそれが使用され、指定されていない場合はすべてのスレッドに設定されているタイムアウトが使用されます。
タイムアウト値を0に設定すると、スレッドの保護が停止します。一般的に、サービス・ガーディアン・タイムアウト値は、パケット配信のタイムアウト値と同じか、それより長く設定する必要があります。
|
注意: ガーディアン・タイムアウトは、read-write-backing-mapスキームで構成するキャッシュ・ストアの実装に使用することもできます。この場合、<cachestore-timeout>要素を0に設定します。これによって、このタイムアウトがデフォルトのガーディアン・タイムアウトに設定されます。「read-write-backing-map-scheme」を参照してください。 |
あるクラスタ・ノード内のすべてのスレッドにガーディアン・タイムアウトを設定するには、オペレーション・オーバーライド・ファイルの<service-guardian>要素内に<timeout-milliseconds>要素を追加します。次の例では、タイムアウト値が120000ミリ秒に設定されます。
<?xml version='1.0'?>
<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<service-guardian>
<timeout-milliseconds>120000</timeout-milliseconds>
</service-guardian>
</cluster-config>
</coherence>
<timeout-milliseconds>の値は、tangosol.coherence.guard.timeoutシステム・プロパティを使用して設定することもできます。
サービス・タイプごとにガーディアン・タイムアウトを設定するには、オペレーション・オーバーライド・ファイルにあるサービスのguardian-timeout初期化パラメータをオーバーライドします。次の例では、DistributedCacheサービスのガーディアン・タイムアウトが120000ミリ秒に設定されます。
<?xml version='1.0'?>
<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<services>
<service id="3">
<init-params>
<init-param id="17">
<param-name>guardian-timeout</param-name>
<param-value>120000</param-value>
</init-param>
</init-params>
</service>
</services>
</cluster-config>
</coherence>
guardian-timeout初期化パラメータは、DistributedCache、ReplicatedCache、OptimisticCache、InvocationおよびProxyの各サービスに設定できます。特定のサービスのguardian-timeoutパラメータのオーバーライドに使用する適切なサービスIDおよび初期化パラメータIDについては、coherence.jarファイルにあるtangosol-coherence.xmlファイルを参照してください。
ガーディアン・タイムアウトを設定する、各サービスのシステム・プロパティは、それぞれ次のとおりです。
tangosol.coherence.distributed.guard.timeouttangosol.coherence.replicated.guard.timeouttangosol.coherence.optimistic.guard.timeouttangosol.coherence.invocation.guard.timeouttangosol.coherence.proxy.guard.timeoutサービス・インスタンスごとにガーディアン・タイムアウトを設定するには、キャッシュ構成ファイルのキャッシュ・スキーム定義に<guardian-timeout>要素を追加します。次の例では、分散キャッシュ・スキームのガーディアン・タイムアウトが120000ミリ秒に設定されます。
<distributed-scheme>
<scheme-name>example-distributed</scheme-name>
<service-name>DistributedCache</service-name>
<guardian-timeout>120000</guardian-timeout>
<backing-map-scheme>
<local-scheme>
<scheme-ref>example-binary-backing-map</scheme-ref>
</local-scheme>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>
<guardian-timeout>要素は、<distributed-scheme>、<replicated-scheme>、<optimistic-scheme>、<transaction-scheme>、<invocation-scheme>および<proxy-scheme>の各スキームで使用できます。
Invocable、EntryProcessorおよびEntryAggregatorインタフェースのカスタム実装によって、com.tangosol.net.PriorityTaskインタフェースを実装できます。この場合、サービス・ガーディアンでは、getExecutionTimeoutMillis()から返される値より長い間タスクが実行されている場合にリカバリが試行されます。APIの使用方法の詳細は、第31章「スレッド実行の管理」を参照してください。
実行タイムアウトは、キャッシュ構成ファイルで定義されている<invocation-scheme>要素内の<task-timeout>要素を使用して設定できます。Invocationサービスの場合、<task-timeout>要素によって、PriorityTaskインタフェースを実装するInvocableタスクのタイムアウト値が指定されますが、この実行タイムアウト値が明示的に指定されるわけではありません。つまり、getExecutionTimeoutMillis()メソッドは0を返します。
<task-timeout>要素を0に設定すると、デフォルトのガーディアン・タイムアウトが使用されます。<task-timeout>要素の使用をサポートする様々なキャッシュ・スキームの詳細は、付録B「キャッシュ構成の要素」を参照してください。
サービス失敗ポリシーでは、スレッドがデッドロックされているとサービス・ガーディアンが結論付けた場合に実行される修正処置が指定されます。適用可能なポリシーは次のとおりです。
exit-cluster - このポリシーでは、応答しないように見えるスレッドをリカバリしようとします。試行に失敗した場合は、関連付けられたサービスの停止が試行されます。関連付けられたサービスを停止できない場合、このポリシーによって、ローカル・ノードでクラスタ・サービスが停止します。指定のポリシーがない場合、これがデフォルトのポリシーです。
exit-process - このポリシーでは、応答しないように見えるスレッドをリカバリしようとします。試行に失敗した場合は、関連付けられたサービスの停止が試行されます。関連付けられたサービスを停止できない場合、このポリシーによって、ローカル・ノードでJVMが途中で終了します。
logging - このポリシーでは、検出された問題がログに記録されますが、修正処置は実行されません。
カスタム - com.tangosol.net.ServiceFailurePolicyインタフェースを実装するJavaクラスの名前。「カスタムのガーディアン失敗ポリシーの有効化」を参照してください。
サービス・ガーディアン失敗ポリシーは、必要な粒度レベルに基づいて3種類の方法で設定できます。
すべてのスレッド - このオプションでは、1つの失敗ポリシーをクラスタ・ノード上のCoherence所有のスレッドすべてに適用できます。これが初期状態の構成です。
サービス・タイプごとのスレッド - このオプションでは、サービス・タイプごとに異なる失敗ポリシーを設定できます。ポリシー値は、すべてのサービス・インスタンスのスレッドに適用されます。特定のサービス・タイプにポリシーが指定されていないと、そのポリシーはすべてのスレッドに設定されているデフォルトのポリシーに設定されます。
サービス・インスタンスごとのスレッド - このオプションでは、サービス・インスタンスごとに異なる失敗ポリシーを設定できます。特定のサービス・インスタンスにポリシーが設定されていないと、そのサービスのポリシーが指定されている場合はそれが使用され、指定されていない場合はすべてのスレッドに設定されているポリシーが使用されます。
ガーディアン失敗ポリシーを設定するには、オペレーション・オーバーライド・ファイルの<service-guardian>要素内に<service-failure-policy>要素を追加します。次の例では、失敗ポリシーがexit-processに設定されます。
<?xml version='1.0'?>
<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<service-guardian>
<service-failure-policy>exit-process</service-failure-policy>
</service-guardian>
</cluster-config>
</coherence>
サービス・タイプごとに失敗ポリシーを設定するには、オペレーション・オーバーライド・ファイルにあるサービスのservice-failure-policy初期化パラメータをオーバーライドします。次の例では、DistributedCacheサービスの失敗ポリシーがloggingポリシーに設定されます。
<?xml version='1.0'?>
<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<services>
<service id="3">
<init-params>
<init-param id="18">
<param-name>service-failure-policy</param-name>
<param-value>logging</param-value>
</init-param>
</init-params>
</service>
</services>
</cluster-config>
</coherence>
service-failure-policy初期化パラメータは、DistributedCache、ReplicatedCache、OptimisticCache、InvocationおよびProxyの各サービスに設定できます。特定のサービスのservice-failure-policyパラメータのオーバーライドに使用する適切なサービスIDおよび初期化パラメータIDについては、coherence.jarファイルにあるtangosol-coherence.xmlファイルを参照してください。
サービス・インスタンスごとに失敗ポリシーを設定するには、キャッシュ構成ファイルのキャッシュ・スキーム定義に<service-failure-policy>要素を追加します。次の例では、分散キャッシュ・スキームの失敗ポリシーがloggingに設定されます。
<distributed-scheme>
<scheme-name>example-distributed</scheme-name>
<service-name>DistributedCache</service-name>
<guardian-timeout>120000</guardian-timeout>
<service-failure-policy>logging</service-failure-policy>
<backing-map-scheme>
<local-scheme>
<scheme-ref>example-binary-backing-map</scheme-ref>
</local-scheme>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>
<service-failure-policy>要素は、<distributed-scheme>、<replicated-scheme>、<optimistic-scheme>、<transaction-scheme>、<invocation-scheme>および<proxy-scheme>の各スキームで使用できます。
カスタムの失敗ポリシーを使用するには、<instance>のサブ要素を追加し、ServiceFailurePolicyインタフェースを実装する完全修飾クラス名を指定します。<instance>要素の使用の詳細は、「instance」を参照してください。次の例では、MyFailurePolicyクラスに実装されているカスタムの失敗ポリシーが有効になります。カスタムの失敗ポリシーは、(次に示しているように)すべてのスレッドに対して有効にすることも、キャッシュ・スキーム定義内でサービス・インスタンスごとに有効にすることもできます。
<?xml version='1.0'?>
<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<service-guardian>
<service-failure-policy>
<instance>
<class-name>package.MyFailurePolicy</class-name>
</instance>
</service-failure-policy>
</service-guardian>
</cluster-config>
</coherence>
代替案として、<instance>要素では、ServiceFailurePolicyインスタンスを作成するためのファクトリ・クラスを使用する<class-factory-name>要素、およびオブジェクトのインスタンス化を実行するファクトリ・クラス上で静的なファクトリ・メソッドを指定する<method-name>要素の使用がサポートされています。次の例では、MyPolicyFactoryクラスでgetPolicyメソッドを使用してカスタムの失敗ポリシーのインスタンスが取得されます。
<?xml version='1.0'?>
<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<service-guardian>
<service-failure-policy>
<instance>
<class-factory-name>package.MyPolicyFactory</class-factory-name>
<method-name>getPolicy</method-name>
</instance>
</service-failure-policy>
</service-guardian>
</cluster-config>
</coherence>
実装に必要な初期化パラメータはすべて、<init-params>要素を使用して指定できます。次の例では、iMaxTimeパラメータが2000に設定されます。
<?xml version='1.0'?>
<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<service-guardian>
<service-failure-policy>
<instance>
<class-name>package.MyFailurePolicy</class-name>
<init-params>
<init-param>
<param-name>iMaxTime</param-name>
<param-value>2000</param-value>
</init-param>
</init-params>
</instance>
</service-failure-policy>
</service-guardian>
</cluster-config>
</coherence>
com.tangosol.net.GuardSupportクラスでは、アプリケーションでガーディアンにハートビートを手動で発行する際に使用できるハートビート・メソッドが用意されています。
GuardSupport.heartbeat();
既知の実行時間の長い操作の場合、操作がスタック状態にあると見なすまでの経過時間(ミリ秒数)を指定してハートビートを発行できます。
GuardSupport.heartbeat(long cMillis);
